PerhapsgetState instead ofgetCurrent?

Ya, that is reasonable. I wanted it to be clear that this was a single snapshot/immutable point-in-time of the state, and not a reference to it that would update, but I don’t feel that strongly.

That’s the kind of thing that would be best described by documentation IMO.

This is actually how state used to managed, but I changed it in#43. Tracking stateoutside of React can make things complicated when it comes to async/concurrent rendering. With this implementation we could run the risk ofcurrentState being out of sync with the actual state React is rendering with.

Can you describe your use case in a little more detail? I usually recommend reading state via React, and then syncing with external services in the commit phase (componentDidMount,componentDidUpdate). It's a bit convoluted because of how you can access Context, but it would look something like:

classSubscriptionextendsReact.Component{componentDidMount(){this.updateExternalState();}componentDidUpdate(){this.updateExternalState();}// Updates some external (non-React) code with the// new value(s) read from state in Connected.syncWithExternalState=()=>{const{ value}=this.props;updateExternalState(value);};render(){returnnull;}}constConnected=()=>(<Consumerselect={[selectName]}>{name=><Subscriptionvalue={name}/>}</Consumer>);

It's verbose, but I suspect this will get easier in the future as the React team works on this class of problems.

The key distinction here i believe is in the use of the wordtracking. My needs (and this change) are to get a point-in-timesnapshot of the current state, and specifically not to track the state's change. I am using this for code that is well outside the React rendering process, such as with callbacks that are part of external side-effects: "i just got an event from an external system and i need to take action in-part based on the current-state". This is not about knowing when the state changes, it is just about getting the current value and making a point-in-time decision.

I understand the concern with exposing this value externally, which is why i thought calling itgetCurrent could help with the distinction. Maybe it could even be calledgetStateSnapshot or something more obvious. If feels like, in any case, knowing the current state easily without having to be in a callback from React is important for some reasonable use-cases.

Love this library. It works amazingly well with typescript & makes doing simple fluxy apps so quick and straight-forward.

fwiw I ran into this very recently. When the app starts up I run afetch request to get the user info & and put it into state:

example:

// actions.jsasyncfunctionloadUser(){constres=awaitfetch('/current-user')constuser=awaitres.json()mutate(state=>(state.user=user))}

Later I want to do another fetch somewhere else using the stored user information. I would have to pass the user into the action, but what I want is another action like this:

// actions.js...asyncfunctiondoSomethingCoolWithCurrentUser(){const{ user}=getState()awaitfetch(`/users/${user.id}/something-cool')}

but you can't do that...

you can do this:

asyncfunctiondoSomethingCoolWithCurrentUser(){letuserId;mutate(state=>(userId=state.user.id))awaitfetch(`/users/${userId}/something-cool')}

but that is kinda gross. Also IIRC if you were to do something like:

asyncfunctiondoSomethingCoolWithCurrentUser(){letuser;mutate(state=>(user=state.user))awaitfetch(`/users/${user.id}/something-cool')}

it gets weird becauseuser is actually a reference to the proxy and not the original object.

It's vaguely similar to redux-thunk'sgetState() thing it injects into your action creators.

I was thinking of forking & adding it to try it out but then see this PR is already open so I just wanted to throw on a little cheer for it. 👏