@atomico/store is Naturally asynchronous.

Objectives

1. Asynchrony management.

2. Finitely predictable asynchrony.

3. Modularity and composition.

Asynchrony management

Application events and service calls are naturally asynchronous, with @atomico/store you can use asynchronous functions or asynchronous generators to define the update cycle.

update cycle? By this I mean the states that occur sequentially when dispatching the action, example:

The previous action will generate 2 states when dispatched:

1. state 1:{loading: true, products:[]}

2. state 2: {loading: false, products:[...product]}

The advantage of this is that the process is clearly observable by the store and by whoever dispatches the action.

Finitely predictable asynchrony

Every action in @atomico/store is wrapped in a promise that defines when it ends its cycle, this will let you execute actions sequentially, example:

Modularity and composition

@atomico/store allows to decouple the actions and the state of the store, for a better modularization , example:

API

Getting Started

Stores in Atomico are web components with behavior similar to the Atomico context API, for example:

Creating the store

Defining the store

Consuming the store

Bidirectional State Management?

If you're familiar with the Atomico context API, you'll know it's unidirectional, meaning the parent dispatches updates to the child. @atomico/store is bidirectional, allowing any store consumer to synchronize. This means the parent can dispatch updates to the child, and the child can dispatch updates to the parent.