Problem
Client-side navigation to the search page logs:
Warning: Failed prop type: Invalid prop `children` supplied to `Segment`, expected a ReactNode.
at Segment
at SolrSearch (SolrSearch.jsx)
Cause
SolrSearch renders the Toolbar portal inside the top-level <Segment>:
{this.state.isClient &&
createPortal(<Toolbar ... />, document.getElementById('toolbar'))}createPortal returns a ReactPortal, which is a valid renderable ReactNode — but the prop-types node checker does not recognize portal objects (a known prop-types limitation), so semantic-ui's Segment propTypes reports invalid children. False positive, harmless at runtime; only appears on client-side navigation because isClient is false during SSR first render.
Objective
Silence the warning without behavioral side effects: move the portal out of the Segment children to a sibling position (fragment around the return). A portal renders into its DOM target regardless of tree position; Segment provides no context or event handlers that the portal subtree would lose.
Note: kitconcept.intranet carries a copy of this pattern in its SolrSearch override — needs the same fix there.
Problem
Client-side navigation to the search page logs:
Cause
SolrSearchrenders the Toolbar portal inside the top-level<Segment>:createPortalreturns aReactPortal, which is a valid renderable ReactNode — but theprop-typesnodechecker does not recognize portal objects (a known prop-types limitation), so semantic-ui'sSegmentpropTypes reports invalid children. False positive, harmless at runtime; only appears on client-side navigation becauseisClientis false during SSR first render.Objective
Silence the warning without behavioral side effects: move the portal out of the
Segmentchildren to a sibling position (fragment around the return). A portal renders into its DOM target regardless of tree position;Segmentprovides no context or event handlers that the portal subtree would lose.Note: kitconcept.intranet carries a copy of this pattern in its SolrSearch override — needs the same fix there.