Proposal: Add AsyncComputed #77

justinfagnani · 2024-07-06T02:49:46Z

Sorry for not opening an issue first, but I had this implementation of an AsyncComputed that I thought could be discussed either for inclusion or as a direction for signalFunction() or a future Relay implementation.

Conceptually AsyncComputed is very similar to signalFunction() or Relays, so there's a ton of overlap. I wrote this while trying to wrap my head around tc39/proposal-signals#30 and the signalFunction(). It's partly based on the shape of the Task utility that we have in Lit.

As I wrote in tc39/proposal-signals#30 (comment), AsyncComputed has these features:

It takes a Promise-returning computation function with an AbortSignal argument: (signal: AbortSignal) => Promise<T>
The function is called within an internal Signal.Computed, so all synchronous signal access is tracked
When the internal computed runs, it re-runs the compute function, pre-empting any pending run and aborting their abort signals.
It has signal-backed getters for its state:
- state: one of 'initial', 'pending', 'complete', or 'error'. state will synchronously change to 'pending' when dependency signals are dirtied.
- value: the last completion value if the last completion type was 'complete', otherwise undefined
- error: the last error if the last completion type was 'error', otherwise undefined
It has a complete getter that returns a Promise that settles when the AsyncComputed does. If a new run is triggered before the previous completes, the same Promise instance is kept. If a new run is started after a completion, a new Promise is created.
It has a get() method that returns the latest completion value or throws if the last completion was an error.
It has a run() method to manually read from the internal computed and trigger a run. Otherwise the computed is read from the various getters.

I found this API shape and implementation to be relatively simple, and I'm starting to use it throughout my code base.

Compared to signalFunction() I think this mainly has a slightly smaller public API, doesn't use SignalAsyncData, and has AbortSignal support. The completion promise behavior is different - AsyncComputed's complete promise will be shared among concurrent/preempted runs and only settled by the most recent run.

Compared to Relays I think the differences are that there are no consumer APIs for altering the state, and instead of passing get and set functions to the compute function, it relies on the return value of the compute function, and there's no update/destroy concept inside the compute function.

I think it's worth noting that utilities like this are also similar in some ways to libraries like TanStack Query, which are very feature-rich with things like caching, debouncing, etc. I think most of those feature can be implemented as part of the compute function. It may be helpful to pass the AsyncComputed instance back to the compute function to use as a key for caches or WeakMaps that store last invocation time for debouncing. Implementing debouncing inside the compute function would also require some kind of conditional gate on a run - either a shouldRun function in the options, or supporting an AbortError being thrown synchronously from the compute function as a way to cancel preemption.

NullVoxPopuli · 2024-07-06T16:21:51Z

.github/workflows/ci.yml

@@ -38,6 +38,7 @@ jobs:
 steps:
 - uses: actions/checkout@v4
 - uses: wyvox/action-setup-pnpm@v3
+ with: { node-version: 22 }


why specify this? 🤔

we could add an .nvmrc or .node-version, perhaps?

To get Promise.withResolvers().

It's of course only a few lines to do what withResolvers() does, but withResolvers() is so nice and I figured this library is pretty cutting edge, so...

oh yes, I mean, setting node 22 is great!

Will also need to update:

https://github.com/proposal-signals/signal-utils/blob/main/package.json#L83

NullVoxPopuli · 2024-07-06T16:22:08Z

src/async-computed.ts

The inline docs here are wonderful!

src/async-computed.ts

sorvell · 2024-07-11T16:20:46Z

src/async-computed.ts

+ return this.#error.get();
+ }
+
+ #deferred = new Signal.State<PromiseWithResolvers<T> | undefined>(undefined);


Why is this a signal? Explain in comment?

Only because the value can change and theoretically someone could use the value of the promise inside a computed/effect in a way that requires tracking.

This is debatable though. I didn't have this as a signal in the first versions, and only changed it to make all mutable state observable. I'm really not sure that it's necessary.

sorvell · 2024-07-11T16:30:41Z

src/async-computed.ts

+ * @param options.initialValue The initial value of the AsyncComputed.
+ */
+ constructor(
+ fn: (signal: AbortSignal) => Promise<T>,


Suggest calling this argument abort to avoid overloading the term signal.

sorvell · 2024-07-11T16:37:12Z

src/async-computed.ts

+ /**
+ * Creates a new AsyncComputed signal.
+ *
+ * @param fn The function that performs the asynchronous computation. Any


While there can't be fully automatic tracking for any async signal reads in the computation, it could be supported via an API. Consider:

fn: (abort: AbortSignal, track<K>: (() => K) => K) => Promise<T>.

The track function would simply pass through the returned value but internally it would do so via a computed which could then be watched by the watcher to trigger a re-run.

Yes, I definitely considered that - it's something we could add later.

It's also debatable whether the current behavior is better than a separately tracked sync function, similar to how reaction() works. The argument for the current behavior is that there are some nice ergonomic benefits from writing just one function, and not having to fashion all the state you care about into a single return value.

justinfagnani · 2024-07-12T00:59:27Z

src/async-computed.ts

+ * This value is read from a signal, so any signals that read it will be
+ * tracked as dependents of it.
+ */
+ #error = new Signal.State<unknown | undefined>(undefined);


Oops, this comment is on the wrong line.

justinfagnani · 2024-07-12T01:04:43Z

src/async-computed.ts

+ /**
+ * Creates a new AsyncComputed signal.
+ *
+ * @param fn The function that performs the asynchronous computation. Any


Yes, I definitely considered that - it's something we could add later.

It's also debatable whether the current behavior is better than a separately tracked sync function, similar to how reaction() works. The argument for the current behavior is that there are some nice ergonomic benefits from writing just one function, and not having to fashion all the state you care about into a single return value.

justinfagnani added 4 commits July 5, 2024 19:40

Add AsyncComputed

10a584e

Use Node 22 in tests

d0d40bd

Format

3f3d290

Re-watch the computed after a change

590a616

NullVoxPopuli reviewed Jul 6, 2024

View reviewed changes

src/async-computed.ts

Copy link

Collaborator

NullVoxPopuli Jul 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The inline docs here are wonderful!

justinfagnani reacted with heart emoji

justinfagnani commented Jul 6, 2024

View reviewed changes

src/async-computed.ts Outdated Show resolved Hide resolved

justinfagnani added 3 commits July 6, 2024 11:27

Rename .state to .status

09aed79

Add non-null assertions

4a00ab9

Update volta.node in package.json

fad1689

sorvell reviewed Jul 11, 2024

View reviewed changes

justinfagnani commented Jul 30, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal: Add AsyncComputed #77

Proposal: Add AsyncComputed #77

justinfagnani commented Jul 6, 2024 •

edited

Loading

NullVoxPopuli Jul 6, 2024

justinfagnani Jul 6, 2024

NullVoxPopuli Jul 6, 2024

NullVoxPopuli Jul 6, 2024

sorvell Jul 11, 2024

justinfagnani Jul 12, 2024

sorvell Jul 11, 2024

sorvell Jul 11, 2024

justinfagnani Jul 12, 2024

justinfagnani Jul 12, 2024

justinfagnani Jul 12, 2024

Proposal: Add AsyncComputed #77

Are you sure you want to change the base?

Proposal: Add AsyncComputed #77

Conversation

justinfagnani commented Jul 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

justinfagnani commented Jul 6, 2024 •

edited

Loading