How does reactiveweb's `getPromiseState` compare with `@warpdrive/ember`'s `getPromiseState`?

[abeforgit]

In reactiveweb's docs on getPromiseState, we see this sentence:

NOTE: This getPromiseState is not a replacement for WarpDrive's getRequestState namely, the getPromiseState in this library (reactiveweb) does not support futures, cancellation, or anything else specific to warp-drive.

That makes sense of course, they're two different functions. But more confusing is the fact that warpdrive also provides a getPromiseState function:
https://www.npmjs.com/package/@warp-drive/ember#getpromisestate

Now, having the same function implemented by two libraries is not normally an issue, they're just 2 different functions. But given both your and @runspired 's status as ember household names, and with the RFC proposal, perhaps a little extra clarification is in order?

E.g.: if I already have one of the libraries, are there still reasons to install the other? If I already have both, which implementation should I prefer, or are there particular reasons to prefer one over the other?

[NullVoxPopuli]

yea, these are good questions -- a comparison table is in order:

.	reactiveweb	@warpdrive/ember
use in module state1	✅	✅
use in a getter2	✅	✅
usable in template	✅	✅
immediate has resolved value for resolved promise	✅	✅
invokes a passed function automatically	✅	❌
avoids addons using private APIs	✅	❌3
test waiter integration	✅	✅
no dependencies4	✅5	❌
simple state return6	✅	❌7

so all in all, they are very similar. The primary use case I had for creating my own is that I wanted dynamic module loading (with import) to be one line:

import { getPromiseState } from 'reactiveweb/get-promise-state';

let state = getPromiseState(() => import('./some-module/component'));

<template>
  {{#if state.isLoading}}
    ... pending ...
  {{else if state.error}}
    oh no!
    {{state.error}}
  {{else if state.resolved}}
    <state.resolved />
  {{/if}}
</template>

reactiveweb's getPromiseState is made primarily for my needs in my own projects, and I don't intend to say anything negative about @warp-drives getPromiseState -- I actually took a lot of code from it! it's a good tool.

Footnotes

1. getPromiseState(promise); ↩

2. requires a stable reference to a promise. getter itself does not need to be cached. ↩

3. @warp-drive/ember declares an optional peer dependency on ember-provide-consume-context, which uses private apis, and I want nothing to do with those. ↩

4. this is important for me, because I don't want @warp-drive/core in my projects, as it requires a goofy macros config that isn't compatible with my non-API using projects (it's mostly how they generate macros to not gracefully have some behavior if you don't set up their required babel config -- which I also can't do in a REPL environment (easily -- as in -- without pushing the responsibility to configure babel to the REPLer)). ↩

5. reactiveweb does depend on on ember-resources, but ember-resources itself has no dependencies (for real), and is a suuuuuuuuuuper tiny use of a helper manager. ↩

6. in reactiveweb: State, and then in @warp-drive/*: the PromiseState is made of 3 sub types: PendingPromise, ResolvedPromise, and RejectedPromise ↩

7. warp-drive provides many aliases for states, as well as support some extended promise behavior which is not built in to the platform (Futures, etc). ↩

[runspired]

lol at bogus comparison charts?

[NullVoxPopuli]

you mean how I omitted all the parts where warp-drive's getPromiseState does extra stuff? :D

extra stuff:

• futures
• cancellation
• reason
• etc, probably

these are all things that native promises don't have, so I didn't compare them

[runspired]

@NullVoxPopuli it does none of those things

[NullVoxPopuli]

can you provide a comparison chart as well? and then we'll need a comparison chart of the two comparison charts haha

[runspired]

.	reactiveweb	@warpdrive/core
use in module state[^module-state]	✅	✅
use in a getter[^cached-getter]	✅	✅
usable in template	✅	✅
immediate has resolved value for resolved promise	✅	✅
has a simple API surface	❌ [^invokes functions]	✅
avoids addons using private APIs	✅	✅
test waiter integration	✅	✅
no dependencies	❌ [^ember-resources]	⚠️[^no, but the easiest way to integrate reactivity is to install a pre-existing config for your framework]
simple state return	❌[^not able to discriminate states]	✅
uses spec'd state shape ({ status, reason, value })	❌	✅
allows prepopulation of result cache by 3rd party	❌	✅
can be used without build	✅	❌[^currently requires a simple babel transform most unpkg setups can auto apply]

[NullVoxPopuli]

ok, so combining these two:

pure capability

.	reactiveweb	@warpdrive/ember
use in module state[^module-state]	✅	✅
use in a getter[^cached-getter]	✅	✅
usable in template	✅	✅
immediate has resolved value for resolved promise	✅	✅
test waiter integration	✅	✅
can be used without build	✅	❌[^currently requires a simple babel transform most unpkg setups can auto apply]
allows prepopulation of result cache by 3rd party	❌	✅
discriminated states (helpful for TS)	❌[^I can fix this]	✅
spec'd state shape	❌[^I can fix this]	✅

from the perspective of reactiveweb set of goals:

.	reactiveweb	@warpdrive/ember
invokes a passed function automatically	✅	❌
simple state return[^state-compare]	⚠️[^needs work]	⚠️ [^has pending deprecations, otherwise ✅ ]

from the perspective of @warp-drive/core's set of goals

.	reactiveweb	@warpdrive/core
has a simple API surface	❌ [^invokes functions]	✅
no dependencies	❌ [^ember-resources]	⚠️[^no, but the easiest way to integrate reactivity is to install a pre-existing config for your framework]

some questions I have:

allows prepopulation of result cache by 3rd party

why have this?

[runspired]

why have this?

Two reasons:

1. One of my goals with getPromiseState was to unify the many (many) implementations of reactive Async that had sprung up in Ember.

If WarpDrive was going to also provide a utility, I felt it needed to also solve the common (albeit simple) problem. By allowing outside implementations to make use of the cache directly, we can have interop between various libraries for the state of a given promise without ending up with extra renders.

2. Well known promises are a thing. Some examples are

• the promise representing an async relationship
• any promise returned from an EmberData/WarpDrive public API
• the promise returned by some ember-concurrency tasks
• the promise returned by the model hook
• the promise returned by transitionTo

In many scenarios, the creation of the promise almost definitionally supposes immediate consumption of the promise state. When that state is backed by something that can know the outcome/final-state but must still provide the result via async, this early population allows you to avoid extra renders that would occur due to the initial promise transition from pending to resolved/rejected by pre-populating the result.

This is a problem space that shrinks but does not vanish in Ember if we implement something like the Render Aware Scheduler RFC, but which React will forever have due to its microtask render flush and multi-task approach to completing render.