-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
async/await simplification with flow and babel in strictMode #1410
Comments
That's genious! |
Wow, I didn't know of this babel feature! |
Yes, it would. This is the downside of this method. Do you see any problem with this approach? |
So it would wrap in mobx actions every async function, even the ones unrelated to mobx observable's mutations. Shouldn't introduce unexpected things, but I think you may incur in performance penalties! If there could be a way to "tag" that async function as action and make the transform act only on it, it would be very cool. What do you think? Are you currently using this trick? |
Yes, i am currently using this approach, but because all my async code essentially modifing mobx observables i would use About tagging, i think it should not be very hard to create custom plugin, which will be using |
Yes, I mean penalties from action wrap! I'm curious on what @mattiamanzati thinks about this :) |
Wow, didn't check this issue exists. Just released my plugin, which can handle typescript's emitted decorator too: https://github.com/Strate/babel-plugin-mobx-async-action |
FYI, We did a TS transformer plugin for transforming async functions into generators wrapped into mobx flow https://github.com/AurorNZ/ts-transform-async-to-mobx-flow |
Can this solution also be implemented by checking |
@mweststrate, etc. can you provide some guidance on whether or not you think this Babel approach will pan out? @joecan and I have a large, existing codebase we're porting. We're currently on MobX 3, but we can upgrade as necessary. We're not fans of the flow approach because it's a little too confusing to explain when it's necessary and because we think our guys understand async/await syntax better than generator syntax. The runInAction approach is easy to understand, but it's a bit verbose (it'll add 2 lines per instance X 800 instances). We're on Babel 7, so if the Babel approach takes off, that is probably best, but we don't know how long to wait for it. We already switched our spec files to use async/await. It's really the MobX files that are holding us back. |
Hi, @jjinux. @PDarkTemplar has provided a workable solution |
Thanks, @harvey-woo :) |
thanks |
wouldn't this be a good candidate for the new flow api? It implements generators without having to configure babel. |
@codemerc It is using new flow api under the hood. This plugin allows default async await, without generators, very usefull with typings. |
@PDarkTemplar I was unable to make your code work, but the proposed solution in the first post worked well enough |
I forked AurorNZ/ts-transform-async-to-mobx-flow, and made https://github.com/DarkCow/ts-transform-async-to-mobx-flow/tree/feature/action-decorators It works on Input class Test {
value: string = '';
@action
async func(input: string) {
this.value = await Promise.resolve(input);
}
} Output class Test {
func(input) {
return flow_1(function* func() {
this.value = yield Promise.resolve(input);
}).call(this);
}
} edit: should note I only just forked it, haven't published it, and since it is so divergent from AurorNZ code, not sure if an MR is warranted... |
I'm super excited to try this out! 🥇 |
@DarkCow the reason import {action as action2} from 'mobx';
action2(async function(){}) // that wouldn't be transformed because the code only checks for keyword `action` |
Btw, there seem to be another issue with name conflicts:
This code will run fine without |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
For example you have store code like this:
if you use
@babel/plugin-transform-async-to-generator
with this configuration in your babelrc:
you can simplify your code to this:
And all will be working like a charm :)
The text was updated successfully, but these errors were encountered: