5. async-states: Advanced concepts

4 min readFeb 20, 2023

In this post, you will learn these advanced concepts: forks, lanes, pools and contexts

This post is a part of the following blog post series:

Plan

Introduction
forks
lanes
Pools
Contexts

Introduction

Util now from the previous posts in this series we’ve seen basic state manipulation and subscription. But for a library that came this far, this won’t be the only things it allows, we’ll still talk about other amazing features:

Forks

Forks are state instances with the same configuration ProducerConfig and the same producer.

You can use forks via useAsyncState by setting the fork configuration property to true . Try it here.

The limitation of forks is that they are isolated non referenced states, if you don’t provide a key, it may be lost forever (unless you keep the key or source) and that forked instances won’t share the cache, it can be copied when forked but it is not shared.

Lanes

Lanes are state instances with the same key, producer and cache. And they are attached via a parent/child relation (doesn’t really matter). They completely solve the fork limitations.

So basically you can use lanes to have several instances grouped to a single parent, with the same producer and cache (be careful with keys!):

Here is full picture example:

Open the sandbox and add some sections, then try to search for user IDs in each section while paying attention to the network tab, you will see that all requests for previous IDs are retrieved from the shared cache between all lanes and no requests are made.

Pools

Up until now, whenever you request a state by key , if it exists it is retrieved, even if you do new AsyncState. To address isolation in the same engine scope, there is the Pool concept: You can see it as an area where state keys are unique (Like an in memory react context), here how instances are related to pools:

Pools are isolated and cannot see each other.

To use a pool, just pass the string pool configuration property to either createSource or useAsyncState (if it may change, don’t forget to add it to dependency array’s for useAsyncState).

Like this, you can simulate several isolated providers or applications. If you omit the pool property, a default one is used (with name default ).

Contexts

Contexts are another level on top of pools:

Contexts are a like clusters of pools, a context is an object reference in the memory, it was created to achieve a great level of isolation related to objects: such as window, http request object and so on. For example, you can create a context per request in the server, and only hydrate instances in that context for the given user.

This grants the ability to use top level stuff while having the ability group and isolate them separately.

This feature mainly exists to address server side rendering and isolation by objects rather than strings.

Their fingerprint in memory is minimal and allow large set of features, to use it, it is similar to the usage of pool , just add a configuartion property called context (it should be a valid WeakSet key).

Conclusion

By now you now how to replicate the behavior of state either by totally separating it or by sharing the same cache, and also to create and perform isolation using pools and contexts.

Like stated above, the library won’t stop here, it is going to the server with that context power! In the next blog, we will see how to use the library in the server properly.