Expose state outside of Consumer & mutate

One thing I’ve often found myself wanting to do is access the store’s state outside of React, or at least outside the scope of a consumer.

One option is mutate, however that places you into callback hell. My current preferred workaround is something like this:

const getState = () => new Promise((res) => {
  mutate((_, state) => {
    res(state);
  });
});

// ... inside an async function

const { myStoreProperty } = await getState();

However this isn’t perfect either as it needlessly forces you into Promise-land.

Would it be possible to expose a function which just returns the current state - non-reactively of course - similar to the second argument of the mutate callback?

Alternatively, if I’m pursuing an anti-pattern with viable alternatives, I’d love to hear about that! 😄

There does appear to be precedent for this in Redux.

Thanks!

[aweary]

mutate is synchronous, so you could avoid the Promise all together

const getState = () =>  {
  let _state = null;
  mutate((_, state) => {
    _state = state;
  });
  return _state;
}

but this is pretty messy and I wouldn’t recommend it either 😄 I’m not so sure this is an anti-pattern yet, but my intuition is that it might be. I want react-copy-write to be a pretty small abstraction on top of React context. Since this is a problem that affects all context data (accessing outside of render) I’d prefer to stay consistent and then wait for the React team to come up with a generic solution that we can apply.

Passing the state down via props is my recommendation. I know it might require adding an additional wrapper component, but that’s really not a huge cost in most cases.

[apolzon]

I was also looking for a way to access the provider’s state outside of render. In my case, I needed it in a function that was defined in the same component that was defining the Provider wrapper.

To access the state, I stored a ref to the Provider component and accessed the state directly via this.providerRef.state. Is there anything wrong with accessing it this way, assuming I am not changing any values? Or is this a big code smell/anti-pattern? (i.e., is the best practice that my provider be defined up another level in a container component?)

Probably worth mentioning this is not a full react app (using react-rails and only parts of the app are currently rendered via jsx) so I don’t have a full app wrapper where I can place a global Provider.