Q&A

Q&A

Q: If my state model is isomorphic with my component tree, do I have to handle cleaning state model when elements unmount and I don't want to persist the data?

Q: Say I have user data coming from API and I'm using the data in multiple places of my (large) application. How do I get the user data to my components? Do I store the user data in the global state object or in a separate model and then decompose it for the components to use? I want the shared user data to update if a component updates the data.

Q: I have a component which owns some data and I want to share that data with another component, but want to make sure the other component cannot write to the data, only read it. What is the preferred way to handle this?

Assuming the data is stored in an atom, you can, for example, say U.template(atom) and the result is a read-only property through which the atom can no longer be mutated. If you also want to prevent imperative mutation of the JavaScript objects representing the contained data, you could also keep all the objects in your state as frozen.

This sort of prevention should usually be unnecessary, however. Just don't write to the atom or mutate the data. My preferred default approach is to treat all data as immutable.

Note that, in development mode, the Partial Lenses library calls Object.freeze on objects (and arrays) created by the optics combinators themselves. This should help to catch bugs where one tries to imperatively mutate data structures.

Q: How do I share data between components which don't have any immediate common parent? I don't want to pass slices of state through unrelated components and end up with implicit intermediate components which need to pass state through them for my app to work.

(I don't understand what is meant by "implicit intermediate components".)

I would recommend to pass majority of state explicitly as props through the component hierarchy.

In my experience, with proper factoring, the explicit passing of state to components is much less of problem than one might assume that it is. For example, you can combine separate slices of state as a bundle so that intermediate components don't necessarily need to be changed when the bundle is changed (e.g. when a new leaf component is added).

Passing state as props explicitly carries the major benefit that any programmer immediately knows how to reason about them: they are just arguments to functions. You can easily follow the chain of argument passing in the source code and don't have to e.g. inspect every component in the tree to see whether they mess with the context.

It is also possible to use React's context feature to pass state, but I would recommend to limit the use of context to minimum. For example, passing the current location (URL) to components seems like a good use of the context. On client side the location is window global state, but on server side there is no such thing and it needs to be passed to components.