Migrating Async/Await to Promise

[byteab]

WIP

middleware.ts is completely migrated from Async/Await to Promise.
and also sync apis will be called in a sync manner.

• a general API created to handle both sync/async peacefully
• async tests passed
• sync tests added
• sync test passed
• types added

fixing #346

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 473c16a:

Sandbox	Source
React	Configuration
React Typescript	Configuration

[barbogast]

@dai-shi https://gist.github.com/barbogast/5679eabc25b761da0f500f53ca3ea0c2 contains an idea for a fix of the remaining issue with the rehydration. Is this approach correct, or do you think it should be fixed in an entirely different way?

[barbogast]

Just updated both gists. The tests should be finished, and are passing against the updated middleware.ts gist. How do you want me to submit the code? A PR against https://github.com/TheEhsanSarshar/zustand/tree/async-await-fix? Or do you just want to grab the gists and add them to PR directly, @TheEhsanSarshar?

[barbogast]

I'm wondering... is it possible to correctly type makeThenable()? I had a quick try and didn't manage, especially since the returned object needs to be compatible with real Promises for TS (I guess?).

That together with the subtle but important differences between sync mode and async mode within the same code block make me wonder if it's worth it to handle both cases with the same code. Maybe it would be better to duplicate the code and handle both cases separately. Not sure, though, just sharing the thought.

[byteab]

Just updated both gists. The tests should be finished, and are passing against the updated middleware.ts gist. How do you want me to submit the code? A PR against https://github.com/TheEhsanSarshar/zustand/tree/async-await-fix? Or do you just want to grab the gists and add them to PR directly, @TheEhsanSarshar?

I am going to make some changes to add support for sync error handling. then you can make a PR on the repo

[byteab]

Hi dear @dai-shi.
in this gist, I just implemented a new toThenable that is able to handle errors in both syn/async. it also handles thrown exception inside then and catch
can you please have a look at that?
https://gist.github.com/TheEhsanSarshar/d9852a7cc102dae0f07186e1dc4fe700

[byteab]

the async tests are failing. dear @barbogast would you mind please check that.

[dai-shi]

https://gist.github.com/TheEhsanSarshar/d9852a7cc102dae0f07186e1dc4fe700#gistcomment-3761417
The conversations are scattered.
We could just paste the code here.

[barbogast]

FWIW, I created a PR with my results agains @TheEhsanSarshar 's branch: byteab#1. The changes are separated by commit, so you can cherry-pick. It contains the tests for the sync storage and code adjustments to middleware.ts so that all the tests are passing.

[barbogast]

in this gist, I just implemented a new toThenable that is able to handle errors in both syn/async. it also handles thrown exception inside then and catch
can you please have a look at that?
https://gist.github.com/TheEhsanSarshar/d9852a7cc102dae0f07186e1dc4fe700

Hmm... just realised, that it might be worth it to have separate tests toThenable, then. There are a lot of ways in which this function can be used, and without tests it might be tricky to guarantee that all of them are handled correctly. Especially thinking about all the different ways in which errors could occur.

[dai-shi]

Thanks guys for working on this.
I thought too that tests for toThenable would be nice.
But, we haven't agreed on the api yet.
Let me put my proposal here:

const toThenable = (fn) => (input) => {
  try {
    const result = fn(input)
    if (result instanceof Promise) {
      return result
    }
    return {
      then(onFulfilled) { return toThenable(onFulfilled)(result) },
      catch(onRejected) { return this },
    }
  } catch (e) {
    return {
      then(onFulfilled) { return this },
      catch(onRejected) { return toThenable(onRejected)(e) },
    }
  }
}

[byteab]

thanks @dai-shi I am going to playaround with your proposal

[byteab]

in this gist, I just implemented a new toThenable that is able to handle errors in both syn/async. it also handles thrown exception inside then and catch
can you please have a look at that?
https://gist.github.com/TheEhsanSarshar/d9852a7cc102dae0f07186e1dc4fe700

Hmm... just realised, that it might be worth it to have separate tests toThenable, then. There are a lot of ways in which this function can be used, and without tests it might be tricky to guarantee that all of them are handled correctly. Especially thinking about all the different ways in which errors could occur.

@barbogast are agree to finalize the api first and then write tests ?

[barbogast]

Right now the code doesn't behave correctly if the version in localStorage doesn't match the version in the code and there is no migrate function. There is also no test covering this.

Is this case supposed to be handled correctly? Thinking about it, a console.error warning might also be helpful in this case.

--- edit
PR: byteab#4. Also, the code handling the migration can be simplified. Would do that later.

[byteab]

Right now the code doesn't behave correctly if the version in localStorage doesn't match the version in the code and there is no migrate function. There is also no test covering this.

Is this case supposed to be handled correctly? Thinking about it, a console.error warning might also be helpful in this case.

--- edit
PR: TheEhsanSarshar#4. Also, the code handling the migration can be simplified. Would do that later.

Yeah, as you said a single console.warn would be enough.

[dai-shi]

Looks great, and getting close. There're a few things to fix for edge cases.
So sorry about the messy comments. If ambiguous, feel free to ask.

[dai-shi]

Suggested change

	})
	}).catch((e) => { throw e })

I'm pretty sure we want this, no?

[byteab]

I am not sure if it's working in a sync manner. let me check that

[dai-shi]

I think this magically works.

[byteab]

👍

[dai-shi]

I meant it would work with my fix, which was wrong.
473c16a should be the fix.

[byteab]

Here I have updated the gist.
https://gist.github.com/TheEhsanSarshar/d9852a7cc102dae0f07186e1dc4fe700
@dai-shi @AnatoleLucet @barbogast please have a look at this.

there are still typescript issues in line:287.
I think we should change toThenable types a little bit.

[dai-shi]

Here you go: playground

[AnatoleLucet]

Suggested change

	if (deserializedStorageValue.version !== version) {
	if ((deserializedStorageValue.version ?? false) && deserializedStorageValue.version !== version) {

see #409

[dai-shi]

removing ?? false just works?

[AnatoleLucet]

not if the version is 0

[AnatoleLucet]

No, my bad. This doesn't even work if the version is 0. So maybe something like: typeof deserializedStorageValue.version === "number" && deserializedStorageValue.version !== version?

[dai-shi]

StorageValue<S> requires version to be number so we can even throw an error if typeof ... !== "number".

[AnatoleLucet]

Well, that wouldn't permit to store a primitive value as in #409
But maybe there is a reason not to allow that?

[dai-shi]

well, if we want to allow non-version store, we should also change the StorageValue<S> type. I'm fine with either way.

[dai-shi]

Should we tackle it as a separate PR?

[AnatoleLucet]

Yes, let's merge this first

[dai-shi]

Looks great to me. Nice work!

[byteab]

Good job everybody.
Thank you @dai-shi @barbogast @AnatoleLucet for working on this.
It is an honor for me to work with such talented developers.

[barbogast]

Like-wise, after years working with open-source software I'm still amazed getting such high-quality software for free. And in addition to that it feels like there's 24/7 support with direct access to the core-developers, no premium-support-subscription needed.
But it's not one-sided since, as seen here, users are happy to contribute and collaborate, and so it's a common effort, rather than provider-consumer. I feel that the open source development is one of the best and highest value-generating way of collaboration that humans have.

Hehe, got all philosophical here 🙈 Anyway, thanks all 😍

[AnatoleLucet]

Lgtm. Many thanks to everyone for your hard work! 🚀