Recoil: What situations would it be more preferrable to use useContext over Recoil?

[cybervaldez]

[acutmore]

Hi @cybervaldez

This part of the Recoil announcement video talks about one situation where Recoil would be preferable over useContext:

https://youtu.be/_ISAA_Jt9kI?t=318 at 5:18

[drarmstr]

I'm very biased ;) , but I personally have found Recoil to be sufficient compared to using React context. Stylistic arguments could always be made, of course. Perhaps it might help in some cases where you want to share state without importing from a shared module.. Recoil doesn't require an all-or-nothing choice. The two systems can definitely co-exist; you don't need to choose and can use the one you prefer for a given situation, and we support some tools which do use both. One tool has a plug-in architecture and we have a mixture from that. Though, if you want to use Recoil for state persistence, then it helps to have all state you want to persist in that system.

If anyone has examples of situations where useContext enables something that doesn't work in Recoil it would be very interesting to see so that we can evaluate requirements.

[acutmore]

@drarmstr There was this issue: #140 which came up that was quite interesting, about sharing context values across multiple instances of React.

[jaredpalmer]

Context remains useful for "infrastructure" components with parent-child relationships that are close together but not strictly direct descendants, especially as you get close to leaf nodes.

Examples that come to mind would be custom <Menu>, <Tabs>, <CheckboxGroup>, <RadioGroup> components, etc. I would 1000% use context for something like this

<Tabs>
  <TabList>
    <Tab>One</Tab>
    <Tab>Two</Tab>
    <Tab>Three</Tab>
  </TabList>
  <TabPanels>
    <TabPanel>
      <p>one!</p>
    </TabPanel>
    <TabPanel>
      <p>two!</p>
    </TabPanel>
    <TabPanel>
      <p>three!</p>
    </TabPanel>
  </TabPanels>
</Tabs>

Note: the reason to use context instead of cloneElement in these components is so that your consumers can inject or escape the structure.

<Menu>
  <MenuButton>Open</MenuButton>
  <MenuList>
    <div className="random div stuff">
      <MenuItem>One</MenuItem>
      <MenuItem>Two</MenuItem>
    </div>
  </MenuList>
</Menu>

[cybervaldez]

Context remains useful for "infrastructure" components with parent-child relationships that are close together but not strictly direct descendants, especially as you get close to leaf nodes.

Examples that come to mind would be custom <Menu>, <Tabs>, <CheckboxGroup>, <RadioGroup> components, etc. I would 1000% use context for something like this

<Tabs>
  <TabList>
    <Tab>One</Tab>
    <Tab>Two</Tab>
    <Tab>Three</Tab>
  </TabList>
  <TabPanels>
    <TabPanel>
      <p>one!</p>
    </TabPanel>
    <TabPanel>
      <p>two!</p>
    </TabPanel>
    <TabPanel>
      <p>three!</p>
    </TabPanel>
  </TabPanels>
</Tabs>

Note: the reason to use context instead of cloneElement in these components is so that your consumers can inject or escape the structure.

<Menu>
  <MenuButton>Open</MenuButton>
  <MenuList>
  <div className="random div stuff">
    <MenuItem>One</MenuItem>
    <MenuItem>Two</MenuItem>
    </div>
  </MenuList>
</Menu>

Thanks! This makes a lot of sense. Especially context being helpful when injecting into properties.