Recoil: Should I be using an object atom with multiple properties, or many atoms?

[adrianbw]

Thanks for your patience with my many questions. We're really enjoying working with Recoil and figuring out what our approaches will be.

Is it best practice to do this:

export const MyStore = atom({
  key: "storeState",
  default:{
    foo: "",
    bar: [],
    baz: 0
  },
});

With selectors to access/change the individual properties?

Or this?

export const FooState = atom({
  key: "fooState",
  default: ""
});

export const BarState = atom({
  key: "barState",
  default: []
});

export const BazState = atom({
  key: "bazState",
  default: 0
});

[drarmstr]

Either approach works. From our experience we have found best-practice to use separate atoms with primitive or simpler values:

• Subscriptions are done at an atom/selector granularity, so updates to one part of the state only needs to re-render components that listen to that part of the state.
  
  
  
  • Values stored in state must be immutable. It's more convenient to write setters that just set a new value without always needing to use an updater function that takes the current object and builds a new object spread with the old values patching in the update.
  
  
  • If you persist your atoms and change the format of your state, it can be easier to manage upgrading the state for backward compatibility, though either approach does work.
  
  

But, there are cases where it makes sense for more compound atoms, such as when the properties are related and you want to enforce atomicity of multiple updates.

[adrianbw]

Thanks. Our pattern has been to only use selectors to get at atom properties. Is that as performant as using atoms, or does it cause re-renders we don't need?

[drarmstr]

It can currently lead to extra renders, as updating an atom will cause all dependent selectors and components to re-render, even if they only look at a part of the atom. We may optimize that (#314) in the future.