Suggestion: useProvider for replacing context.Provider

function App(props) {
  const [theme] = useState({color: 'white'})
  const [user] = useState({name: 'rabbit'})
  useProvider(themeContext, theme)
  useProvider(userContext, user)

  /* ... */
}

is equivalent to

class App extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      theme: {color: 'white'},
      user: {name: 'rabbit'}
    }
  }
  render() {
    return (
      <themeContext.Provider value={this.state.theme}>
        <userContext.Provider value={this.state.user}>

        </userContext.Provider>
      </themeContext.Provider>
    )
  }
}

[gaearon]

Providers intentionally don’t work this way because the notion of tree structure actually has a meaning (unlike Hooks like useState). Your proposal makes it more difficult to move code between components because any Hook could contain a useProvider call inside, invisibly affecting everything below.

[TotooriaHyperion]

Providers intentionally don’t work this way because the notion of tree structure actually has a meaning (unlike Hooks like useState). Your proposal makes it more difficult to move code between components because any Hook could contain a useProvider call inside, invisibly affecting everything below.

Yes it’s not a good pattern to make provider a hook, but why not attach all the Contexts to the root element of the Component? It don’t break the tree structure.

Or make a multiple provider(don’t use contexts.reduce inside, instead, use only one layer in the tree):

<Providers contexts={[
  [Context1, value1],
  [Context2, value2],
]}>
  {children}
</Provide>

similar to

@Module({ Providers: [Context1, Context2]})
class Component {}

we need tree structure between context and component, but don’t need that between contexts.

It doesn’t make a significant difference unless one use many contexts, but just looks more make sense.