Fully typed flow idea

[kubk]

Mobx flow is great because it allows to write async flows without wrapping observable modifications with action/runInAction. But for TypeScript users it doesn't work well, because TS looses generator types:

const a = yield 1; // type 'any' instead of 'number'

There is an open TS issue: microsoft/TypeScript#32523

In MST repo I've found a trick to get type inference working:

export function* result<T>(promise: Promise<T>) {
  return (yield promise) as T;
}

or if we want to avoid type casts:

export function* result<T>(promise: Promise<T>): Generator<Promise<T>, T, T> {
  return yield promise;
}

It works with no issue:

But to make it working you should enable downlevelIteration in your tsconfig.json

So here is my question - should we add this utility function to Mobx codebase too and describe it's usage in documentation? I believe that Mobx flow is useless for TS users without this function. Ready to make a PR.

We already have flowResult function for TS users. So it's better to come up with a better name rather than result :)

[kubk]

Hi @urugator @mweststrate Sorry for bothering you. I'd like to hear your opinion on that. Mobx already have flowResult, why not add one more zero-runtime helper? Even in the documentation example there is an issue:

The variable projects has type any in this case

[urugator]

I am sorry, but I am unable to provide qualified feedback on most TS related issues :) In this particular case I have zero experience with using flow (or generators in general) with TS.

[jtwigg]

@kubk Found my way here too because I can't get the TS version of Flow's to the compile. I've been staring at the example for awhile now.

I was keen to utilize the "cancel" method of flows, but its lot looking achievable.

[harunou]

A bit improved solution with a handy type alias, which I've been using in my projects.

export type FlowGenerator<TReturn = void> = Generator<Promise<void>, TReturn, void>;

export function toFlowGeneratorFunction<TArgs extends unknown[], TReturn = void>(
    fn: (...args: TArgs) => Promise<TReturn> | TReturn
): (...args: TArgs) => FlowGenerator<TReturn> {
    return function* flowGeneratorFunction(...args: TArgs): FlowGenerator<TReturn> {
        let value: TReturn = undefined as TReturn;
        yield Promise.resolve(fn(...args)).then(result => {
            value = result;
        });

        return value;
    };
}

I don't know when we could have something like this in Mobx or Mobx-utils, so I have published it as a package
https://www.npmjs.com/package/to-flow-generator-function

[tiengtinh]

Your solution worked perfectly, and I can now have fully typed React Mobx stack while using Flow. Thank a lot for putting this together!

[husky-ya]

I'm share my solution, or pattern.

I'm using "experimentalDecorators": true.
Use "Async Generator" syntax with decorator. Call async functions and other flow methods as usually. Call yield after each await:

@flow.bound
private async *loadFAQList() {
    try {
        this.isLoading = true;

        const faqList = await this.store.api.faq.fetchAll();
        yield;

        this.faqList = faqList;
    } catch (e) {
        yield;

        console.error(e);
    } finally {
        this.isLoading = false;
    }
}

And some hacks. I can call async mobx flow actions, and await typed result.

declare global {
    // we can extend built-in AsyncGenerator 👀
    // now, all async generators are promises also. No flowResult needs.
    interface AsyncGenerator<T = unknown, TReturn = any, TNext = unknown> extends Promise<TReturn> {}
}

Then we can do this:

class Store {
    // return type should be omitted
    // return type infer as `AsyncGenerator<never, number[], unknown>` (and `Promise<number[]>` 😁)
    @flow.bound async *method() {
        return [1,2,3]
    }
}

const example = async () => {
    const store = new Store();

    // return number[] (works!)
    const result1 = await store.method()

    // explicit type (works!)
    const result2: number[] = await store.method()

    // @ts-expect-error: Type number[] is not assignable to type string[]
    const result3: string[] = await store.method();
}

This is not perfect solution, types can still broken, in rare cases. But it works, as long as you follow the pattern.

[Tejas-H5]

I've found my way to this thread while trying to find a good way to use MobX via async patterns. The main issue of everything after an await no longer being wrapped in a MobX action seemed like something that flow would solve, but as stated above, typescript loses generator types.

There does seem to already be a flow-based solution here, but I'd like to share an alternative to using generators, which is to decorate the Promise class such that all continuations are wrapped in an action. I'm currently using something like this:

EDIT: doesn't wok 😞 - I'll keep the example+yapping for context though

class MobXPromise<T> extends Promise<T> {
    then<TResult1 = T, TResult2 = never>(
        onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | null | undefined, 
        onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | null | undefined
    ): Promise<TResult1 | TResult2> {
        return super.then(
           onfulfilled ? ((value) => runInAction(() => onfulfilled(value))) : undefined,
           onrejected ? ((reason) => runInAction(() => onrejected(reason))) : undefined,
        );
    }

    catch<TResult = never>(
        onrejected?: ((reason: any) => TResult | PromiseLike<TResult>) | null | undefined
    ): Promise<T | TResult> {
        return super.catch(
           onrejected ? ((reason) => runInAction(() => onrejected(reason))) : undefined,
        );
    }

    finally(onfinally?: (() => void) | null | undefined): Promise<T> {
        return super.finally(
           onfinally ? (() => runInAction(() => onfinally())) : undefined,
        );
    }
}

/** 
 * Wraps all continuations in a MobX action. 
 * This works, because `await` is just syntax sugar over thenables.
 */
function newMobXPromise<T>(promise: Promise<T>): MobXPromise<T> {
    return new MobXPromise((resolve, reject) => promise.then(resolve).catch(reject));
}

This is almost identical to the await + runInAction example in the MobX documentation, except that each continuation won't indent the code deeper and deeper:

class MobXStore {
    async fetchTheStuff() {
        const a = await mobXPromise(api.fetchA());

        this.state.a = a;

        const b = await mobXPromise(api.fetchB(a));

        this.state.b = b;

        const c = await mobXPromise(api.fetchA(b));

        this.sate.c = c;
    }
}

Types and functionality seem to work on my end, but do let me know if there are some pitfalls to be aware of

[Tejas-H5]

I've poked around at your example for an hour and honestly I've got no clue 😭😭😭

So far I haven't been able to figure out why it works in my codebase but not in that example.

[kubk]

Thank you so much for looking into this anyway! I'm gonna mess around with the code too and see what's causing the issue

[nihil-pro]

In can't work.

async incrementAsync() {
    // Sync phase
    this.count++; 
    
    // async phase
    // incrementAsync is marked as "resumable"
    // incrementAsync is poped from execution stack
    // mobXPromise is created
    await mobXPromise(new Promise((res) => setTimeout(res, 1000))); 
    // after 1000ms  incrementAsync is resumed
    // count is incremented out of autoAction
    this.count++;
  }

This will work:

async incrementAsync() {
    this.count++;
    mobXPromise(new Promise((res) => setTimeout(res, 1000))).then(() => {
      this.count++;
    });
  }

but compared to this:

async incrementAsync() {
    this.count++;
    new Promise((res) => setTimeout(res, 1000)).then(() => {
      runInAction(() => this.count++)
    });
  }

I don't see any advantages.

[Tejas-H5]

After some more testing on my end, it looks like this idea doesn't actually work in the browser, apologies.
I thought it was working due to some jest tests that I wrote passing, but they actually don't pass when I create a brand new project from scratch with just mobx and jest. I'll try to work out what it is about my existing test environment that is making it pass, but this idea is probably a dead end 😞 - thanks for the comments, much appreciated.

If I had to make a minor change to this idea, it would be something like this:

	class MobXPromise {
		constructor(promise) {
			this.promise = promise;
		}

		then(onfulfilled, onrejected) {
			return new MobXPromise(this.promise.then(
				onfulfilled ? (val) => runInAction(() => onfulfilled(val)) : undefined,
				onrejected ? (err) => runInAction(() => onrejected(err)) : undefined
			));
		}

		catch(onrejected) {
			return new MobXPromise(this.promise.catch(
				onrejected ? (err) => runInAction(() => onrejected(err)) : undefined
			));
		}

		finally(onfinally) {
			return new MobXPromise(this.promise.finally(
				onfinally ? () => runInAction(() => onfinally()) : undefined
			));
		}
	}

Do note that await still won't magically wrap everything after it in an action (sad), but everything inside the then, catch and finally will, and you can repeatedly chain the callbacks and those callbacks will be wrapped in an action as well. But thenables are a pain to use when you have branching codepaths that do different async actions. Maybe flow is the way after all ...

[nihil-pro]

If I had to make a minor change to this idea, it would be something like this:

I'm also experimenting with promises, and since makeAutoObservable converts methods to actions, my results may help. There are still some troubles, like with floating promises, but with await works nice.