-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add mstRunInAction #1240
add mstRunInAction #1240
Conversation
I'm not a fan of |
The example mentioned in the docs would benefit from either using flow, or splitting in separate actions imho |
To be honest if flows were to be properly typed in TS (or if async/await were to work ok) I'd not have much of a use case. I usually skip flows in the original mobx and use runInAction after awaits exclusively for this reason (yield always returning any). Another alternative is using anonymous actions, with private actions that are not exposed, but that's not possible unless there's some way in models to create those (which mstRunInAction would allow). Maybe a better way to do this is to rename it to mstAction and make an example like this? actions(self => {
const privateAction = mstAction(self, (x: number) => { self.x = x })
return {
async asyncAction() {
const x = await something()
privateAction(x)
}
}
}) |
@xaviergonz Any update on this? I'm taking over MST as primary maintainer, just checking to see if you still want to pursue this. |
Sorry, feel free to close it |
mstRunInAction
, similar to mobx'srunInAction
but for MST node instances.castFlowReturn
since when a flow returns a promise what is actually returned from the flow is the resolved value. (this makes mobx and mst flow defs similar)mstRunInAction(node, name?, thunk)
Usually used to do async/await actions without the need for superfluous actions. Not as good as flow, but has better type inference.
That being said I'm really looking forward Strongly typed iterators and generators in the roadmap for TS 3.5 to finally fix the typings for flow