Forem: Jin

Memory Models of Distributed Systems

Jin — Wed, 23 Apr 2025 07:57:48 +0000

Hello, my name is Dmitriy Karlovskiy and I am.. I try to tell complicated things in simple language, and simple things in aesopian language. And it often turns out that in the process of simplification and structuring, skeletons of ancient dinosaurs are found in the most prominent place, sprinkled with murky formulations so that for many years no one notices them. Well, if you want to finally understand the levels of transaction isolation and guarantees of the order of operations, let's dig together.

This classification is a consistent reinterpretation of the well-known classification from Jepsen in a more concise and clear form.

How to read a chart:

It presents memory models and phenomena that they do not allow.
All models are divided into 2 orthogonal groups: one determines the order of operations, and the other determines the level of transaction isolation.
All models are classified by availability level when dividing the network in a distributed system:
- Total Available — guarantees are provided on any node.
- Sticky Available — guarantees are provided if you do not switch between nodes.
- Unavailable — some or all nodes will not be able to provide guarantees.

Formal timeline representation

Writing version 5 data to the X state:

5=>X

Writing the value of state X to state Y:

X=>Y

Writing a new value to state X based on its version 5:

5+=>X

Reading the state of X with receiving version 6 data:

X=>6

History of operations where Y came after X:

X | Y

Histories of operations X and Y of two agents occurring in parallel:

X
Y

Histories of operations X and Y of two agents occurring sequentially:

X |
  | Y

Transaction history of X and Y within a single successful transaction:

[ X | Y ]

Transaction history of X and Y within a single cancelled transaction:

{ X | Y }

General definitions

Agent is an active actor executing application logic.
Node is a passive entity providing access to data.

In a client-server architecture, a node is a DBMS instance, and an agent is its client. In a peer-to-peer architecture, each agent is a node of the network.

Guarantees of the order of operations

Operation is an atomic action that cannot be broken down into a sequence of smaller actions.

Monotonic

Monotony is a guarantee that time moves only forward, without any state reversals.

The following phenomena are not allowed:

Chaotic Read

Chaotic reading is the phenomenon of traveling back in time, when another reading of the same state returns an older value than it was read earlier.

A=>1 | A=>0

Chaotic Write

Chaotic writing is the phenomenon of rearranging records of different states when the order of their appearance does not coincide with the order of their execution.

1=>A | 1=>B |
            | B=>1 | A=>0 | A=>1

Causal

Causality is a guarantee that the effects observed by operations follow strictly after the operations that caused them.

The following phenomena are not allowed, apart from those that prohibit monotony:

Invisible Write

Invisible writing is the phenomenon of an unobservable change made by the same agent on the same node.

1=>A | A=>0

Causeless Write

Causeless writing is the phenomenon of an unobservable change on which another change is based.

A=>1 | A=>B |
            | B=>1 | A=>0

Since coordination with other nodes is not required to maintain causality, these and weaker guarantees are preserved even when the network is divided, but only if the agent does not switch between nodes.

Sequential

Sequencing is a guarantee of a uniform order of all changes, observed by all agents.

The following phenomena are not allowed apart from those prohibited by causality:

Variable Order

Variable ordering is the phenomenon of observing changes in different order by different agents.

A=>1 | B=>0 | B=>1
B=>1 | A=>0 | A=>1

Since coordination between nodes is required to ensure uniform order, these and stronger guarantees cannot be provided when the network is divided.

Linearizable

Linearizability is a guarantee that the order in which changes are observed corresponds to the order in which they are made in real time.

The following phenomena are not allowed, apart from those that forbid sequencing:

Stale Read

Stae reading is the phenomenon of reading an outdated version of a value when reading after making a more recent change by another agent.

1=>A | 2=>A |
            | A=>1

Guarantees of transaction isolation

Transaction is a sequential group of operations with a common lifecycle. Either all or none of the operations from the transaction are applied.

Read Uncommitted

The visibility of the uncommitted is a guarantee of the atomicity of transaction writes. Write operations of different transactions do not mix with each other, but already made changes to sepatate states are visible between transactions.

The following phenomena are not allowed:

Dirty Write

Dirty write is the phenomenon of mashing a state change by another transaction before the current one is completed, which leads to a partial loss of changes.

[ 1=>A |      | A=>2 ]
       [ 2=>A ]

Read Committed

Visibility of commited is a guarantee of invisibility of changes in running transactions.

The following phenomena are not allowed, apart from those that prohibit read uncommited:

Dirty Read

Dirty reading is the phenomenon of visibility of a change made by another transaction before it is completed. Thus, rolling back a transaction may not roll back the side effects it provoked.

{ 1=>A |      } | [ A=>0 ]
       [ A=>1 ]

Repeatable Read

Repeatable reading is a guarantee of the immutability of visible states within a transaction that did not change these states itself.

The following phenomena are not allowed, apart from those that prohibit read commited:

Phantom / Fuzzy Read

Fuzzy reading is the phenomenon of obtaining different values when reading the same state sequentially.
Phantom reading is a special case of fuzzy reading, concerning the reading of an index by one transaction, while another changes the indexed records themselves.

[ A=>0 |      | A=>1 ]
       [ 1=>A ]

The SQL standard recklessly does not exclude the phenomenon of phantom reading from repeatable reading, which is incorrect, since phantom reading is a manifestation of fuzzy reading of a whole table or an index based on it.

...

So as to maintain repeatability coordination with other nodes is not required, then these and weaker guarantees can be achieved even when the network is divided. A degenerate case is isolated client-side transactions.

Serializable

Serializability — guarantees the visibility of transactions on any node, equivalent to executing them sequentially on one node without mixing any operations between transactions.

The following phenomena are not allowed in addition to those prohibited by repeatable reading:

Lost Update

Lost update is the phenomenon of mashing the changes of one transaction with the changes of another, which does not take into account the changes of the first one.

[ A=>0 | 0+=>A ]       | [ A=>1 ]
[ A=>0 |       | 0+=>A ]

With such a guarantee, transactions can themselves be considered as atomic operations that satisfy the guarantees of sequential, that is, having a global order, which means that these and stronger guarantees cannot be provided when the network is divided.

Strict Serializable

Strict serializability — guarantees the visibility of serializable transactions in accordance with their execution in real time, that is, transactions behave like linearizable atomic operations.

High availability

To ensure high availability, we have to abandon the total sequence of transactions. This means that you need to be prepared for some phenomena.

Some of them can be leveled by using CRDT structures, which give the same result even when swapping operations. But even they cannot protect against stale reading. So you still have to choose between availability and linearizability — this dilemma is also known as the CAP theorem.

If we allow agent switching between nodes, then although it is possible to provide some level of transaction isolation, temporary anomalies are still inevitable, which negates all the benefits of transactions. Therefore, one or another form of binding agent to node and refusal of availability in case of failure of this node seems reasonable.

A social phenomenon

Help to improve this classification and support my researches.

Name Format in Code

Jin — Wed, 03 Apr 2024 16:09:50 +0000

Hello, my name is Dmitry Karlovsky and I... invented $mol just to make your eyes bleed looking at its code. In any case, this feeling can be formed if you read various kinds of around JS chats, but do not turn to the primary sources, where all technical solutions follow from purely pragmatic reasoning. Let me present one of these analyzes to your attention...

Formatting Methods

camelCase

Traditionally used in variable and field names in many modern languages.

❌ It takes a lot of Shift presses in time.
❌ stuckTogetherWordsAreDifficultToRead.
❌ Problems with abbreviations: sdpFmtpLine, encodeURICoponent.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

PascalCase

Traditionally used for class names and global namespaces.

❌ It takes a lot of Shift presses in time.
❌ StuckTogetherWordsAreDifficultToRead.
❌ Problems with abbreviations: XMLHttpRequest, HTMLBRElement, IDBOpenDBRequest, RTCDTMFSender.
❌ Same file names can cause problems on case-insensitive file systems.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

lowercase

Traditionally used for naming native browser events.

❌ stucktogetherwordsaredifficulttoread.
❌ Problems with abbreviations: onicegatheringstatechange.

UPPERCASE

Traditionally used for standard elements in some DOM-APIs (tagName, for example)..

❌ STUCKTOGETHERWORDSAREDIFFICULTTOREAD.
❌ Requires caps lock to be temporarily turned on when typing or holding down Shift.
❌ Problems with abbreviations: BGSOUND.
❌ Text with a small number of callout elements is difficult to perceive: FIGCAPTION.
❌ Same file names can cause problems on case-insensitive file systems.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

kebab-case

Traditionally used for names in HTML, CSS, Lisp, and also in file names.

❌ Editors do not consider these names to be a single name (double-click selection, ctrl+arrow, etc.).
❌ Not allowed in most programming languages.
❌ The name turns out to be several characters longer.
❌ Extra characters break Fuzzy Search in IDE/DevTools, as they are not found in the path.

SHAWERMA-CASE

Traditionally used for names of non-standard elements in some DOM-APIs (tagName, for example).

❌ Editors do not consider these names to be a single name (double-click highlighting, ctrl+arrow, etc.).
❌ Not allowed in most programming languages.
❌ Requires caps lock to be temporarily enabled when typing.
❌ The name turns out to be several characters longer.
❌ Text with a small number of callout elements is difficult to perceive: ACME-TOOLBAR-DROPDOWN.
❌ Extra characters break Fuzzy Search in IDE/DevTools, as they are not found in the path.
❌ Same file names can cause problems on case-insensitive file systems.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

snake_case

Traditionally used in "old school" languages (C, C++, Rust, Erlang, OCaml) and readability-focused languages (Ruby, Python) for local names and field names.

❌ it_takes_a_lot_of_shift_presses.
❌ The name turns out to be several characters longer.
❌ Extra characters break Fuzzy Search in IDE/DevTools, as they are not found in the path.

Cobra_case

❌ It_takes_a_lot_shift_presses.
❌ The name turns out to be several characters longer.
❌ Extra characters break Fuzzy Search in IDE/DevTools, as they are not found in the path.
❌ Same file names can cause problems on case-insensitive file systems.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

SCREAM_CASE

Traditionally used for constants.

❌ Requires holding down Shift when entering.
❌ The name turns out to be several characters longer.
❌ Text with a small number of callout elements is difficult to perceive: SVG_MORPHOLOGY_OPERATOR_UNKNOWN.
❌ Extra characters break Fuzzy Search in IDE/DevTools, as they are not found in the path.
❌ Same file names can cause problems on case-insensitive file systems.
❌ Has problems with styling in CSS (depending on the element type and selector type, the style may not be applied).

Native APIs

Web APIs have evolved spontaneously, so don't be surprised by the unreasonable variety of name formats in different places:

JS:
- PascalCase - classes
- camelCase - fields, functions
- lowercase - events
- SCREAM_CASE - constants
CSS: kebab-case everywhere
HTML:
- lowercase - standard elements and attributes
- kebab-case - non-standard elements and attributes

Separately, it is worth noting the mixture of styles, because the same entity can be called differently in different languages:

Standard element names:
- JS: lowercase, UPPERCASE, PascalCase
- HTML: lowercase
- CSS: lowercase
Names of non-standard elements:
- JS: kebab-case, SHAWERMA-CASE, PascalCase
- HTML: kebab-case
- CSS: kebab-case
Attribute names:
- JS: camelCase, lowercase
- HTML: kebab-case, lowercase
- CSS: kebab-case, lowercase
CSS class names:
- JS: camelCase
- HTML: kebab-case
- CSS: kebab-case

The chimeric naming of constants like SVG_MARKERUNITS_USERSPACEONUSE stands out. The sleep of reason gives birth to monsters.

Recommendations

✅ The optimal choice is snake_case, as it is the most readable and least problematic.

$mol convention

snake_case - any names in XHTML and CSS, local names in JS, and file names
Cobra_case - names of local factories in JS
$nake_case - global names in JS corresponding to FQN.

Afterwords

I hope this analysis will be useful for you, even if the conclusions turn out to be completely different.

Decomposition of Software Components

Jin — Mon, 01 Apr 2024 07:10:00 +0000

Hello, my name is Dmitriy Karlovskiy and I... love power. When I take hold of the keyboard, every bit begins to dance to my tune. But when there are really a lot of these bits, it becomes difficult to keep track of them all. So let's compare popular design patterns that allow you to divide a large application into components so you can control them as efficiently and independently as possible.

Since the same application entity occurs in an application in many places, in different contexts, and must have different representations, the basic decomposition consists of selecting a model of the subject area, which is the source of truth for all places where it is viewed. And here the nuances begin...

💡 Please note that further arrows do not show the movement of data, as they are often drawn, but the presence of knowledge of one component of the system how to work with another. In the limit, this knowledge is expressed in complete control of the life cycle: from creation to destruction. The lack of knowledge gives independence from a specific implementation, and therefore the ability to work with different implementations.

Model-View

The model knows how to present herself in different ways.

Example

class User { // Model

    _id: bigint
    _nickname: string

    toString() { // View
        return 'user=' + this._id
    }

    toJSON() { // View
        return {
            id: String( this._id ),
            name: this._nickname,
        }
    }

}

Features

✅ It is convenient to receive any displays from the model.
❌ Adding a new display requires changing the model.
❌ The display is completely determined by one main model.
❌ Loading the model pulls out all its displays according to dependencies.
❌ Two layers are too few on a large scale.

View-Model

The code for working with models is written directly in the display.

Example

// View
function Task_list() {
    return <ul>{
        Task.list.map( task =>
            <li><Task_row {task} /></li>
        )
    }</ul>
}

// Model
class Task {
    static list = [] as Task[]
}

Features

✅ Display can use arbitrary models.
✅ Easily add new displays without changing models.
❌ To display different models, you need to duplicate the display code.
❌ Changing the model interface requires updating all displays that use it.
❌ Two layers are too few on a large scale.

Model-View-ViewModel

Mappings work with models through intermediaries that transform domain abstractions into mapping abstractions and back. The ViewModel also acts as a store of non-domain view state.

Example

// View
<li class="User_card" model="User_card_model">
    <img src={ image } />
    <p>{ message }</p>
</li>

// ViewModel
class User_card_model {
    user = User.current
    get image() {
        return this.user.avatar
    }
    get message() {
        return this.user.nickname
    }
}

// Model
class User {
    avatar: string
    nickname: string
    static current = new User
}

Features

✅ Display can use arbitrary ViewModels.
✅ Easily add new displays without changing either the model or the ViewModel.
✅ Changing the model interface or display requires changing only the ViewModel.
✅ The same ViewModel can be shared between several displays.
❌ To display different models, you need to duplicate the display code and ViewModel.
❌ Three layers are too few on a large scale.

Model-View-Controller

The controller creates the display and tells it which model to work with. He also processes all commands from the user and manages his charges.

Example

// Controller
class Users_resource {
    GET() {
        return User.all.map( user_brief )
    }
}

// View
function user_brief( user: User ) {
    return {
        id: user.guid,
        name: user.passport.name_full,
    }
}

// Model
class User {

    static all = [] as User[]

    guid: GUID
    passports: Passport[]
    resumes: Resume[]

    get passport() {
        return this.passports[0]
    }

}

Features

✅ Display can use arbitrary models with the same interface.
✅ Easily add new displays without changing models. And vice versa.
❌ To display different types of models, you need to duplicate the display code.
❌ Changing the model interface requires updating all views and controllers that use it.
❌ Three layers are too few on a large scale.

Model-View-Presenter

Models and views are passive and do not know about each other - they are controlled by the presenter, which also acts as an intermediary between them.

Example

// Presenter
class User_preview {
    user: User
    card = new Card({
        image: this.user.avatar,
        message: this.user.nickname,
        color: this.user.skin.color,
        click: ()=> this.skin_change(),
    })
    skin_change() {
        this.user.skin = Skin.random()
    }
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
    <img src={ image } />
    <p>{ message }</p>
</div>

// Model
class User extends Model {
    avatar: string
    nickname: string
    skin: Skin
}

Features

✅ Easily add new displays without changing models. And vice versa.
✅ Changing the interfaces of the model or display requires changing only the presenters.
❌ Three layers are too few on a large scale.
❌ To use the state of one presenter from another, it is necessary to artificially transfer it into the model.

ModelView Fractal

Each ModelView acts as a model/controller for slave ModelViews and as a view for the owning ModelView. Part of the logic can be transferred to both pure Model and pure View, which are only degenerate cases of ModelView.

Example

$my_user_list $my_view
    - \Owner ModelView
    users? /$my_user
    kids /
        <= Row*0 $my_user_row
            user <= user*

$my_user_row $my_card
    - \Having ModevView
    user $my_user
        avatar => image
        nickname => message

$my_card $my_view
    - \View not Model
    kids /
        <= Image $my_image
            uri <= image \about:blank
        <= Message $my_text
            text <= message \

$my_user $my_model
    - \Model not View
    avatar? \
    nickname? \

Features

✅ Each ModelView fully controls internal ModelViews and knows nothing about external ones.
✅ Any ModelView can navigate between different other ModelViews at any composition level.
✅ Changing the ModelView interface requires changing only its owners.
✅ Fractal structure easily scales to applications of any size.

Conclusions

$mol_view is built on the ideas of MVF, since this is the simplest decomposition pattern that easily scales as needed and well separates different levels of abstraction.

Reactive Tech from the Future

Jin — Tue, 05 Mar 2024 10:56:12 +0000

Just look how framework, built on $mol_wire, just destroys both low-level competitors and even VanillaJS (code):

And the point here is not that it renders the DOM so quickly, but quite the opposite, that it does not render the DOM when it is outside the visible area, even if it is a complex layout and not a flat list with a fixed row height.

Imagine how the web would speed up if the browsers themselves learned to do this - request from the application code exactly what is needed for display, and monitor dependencies by itself.

When I show such pictures, I am often accused of dishonesty, because virtual-scroll can also be attached to other frameworks and it will be fast. Or they suggest disabling virtual rendering in order to equalize implementations at the lowest level. It's like lobotomizing Kasparov to even out the odds because he plays chess too well.

However, it is important to understand the difference between the default behavior and behavior that requires a long and careful implementation, and even with a bunch of restrictions:

This is why you almost never see virtual rendering in applications on other frameworks. And that is why you will hardly find applications without virtualization on $mol.

Proper implementation of virtual rendering is not the easiest task, especially considering the architecture of most frameworks that is not optimized for this. I talked about this in detail in the speech:

Automatic virtualization of complex layout

In my opinion, only LazyDOM can provide us with responsive interfaces in the increasingly bloated volumes of data and in the ever-decreasing level of training of application developers. Therefore, we need to push for its implementation in browsers.

But, as my experience shows, it is useless to write proposals - they are simply ignored. We need to adopt the tactic of promises: first, many libraries began to use them, and then browsers pulled them into themselves and standardized them.

This is where we, developers, need to start implementing support for this reactive glue, so that different libraries can work well with each other, integrating into a single reactive system, and not require application programmers to constantly manually transfer data between disparate storages.

If you are developing a library or framework and I have been able to convince you to support a common reactive API, then contact me so we can discuss the details. Integration is possible both at the interface level by fully implementing your subscribers and publishers, or you can take ready-made parts of $mol_wire so as not to worry about bicycles.

$mol_wire Powered Framework

Finally, let me show you how the same advanced counter is implemented on $mol, which I've been teasing throughout this series...

There is a standard module for loading data ($mol_fetch). Moreover, there is a standard module for working with GitHub ($mol_github). Let’s also take standard buttons ($mol_button), standard links ($mol_link), standard text input fields ($mol_string) and numbers ($mol_number), wrap everything up into a vertical list ($mol_list) and voila:

$my_counter $mol_list
    Issue $mol_github_issue
        title => title
        web_uri => link
        json? => data?
    sub /
        <= Numb $mol_number
            value? <=> numb? 48
        <= Title $mol_link
            title <= title
            uri <= link
        <= Reload $mol_button_minor
            title @ \Reload
            click? <=> reload?

export class $my_counter extends $.$my_counter {

    Issue() {
        const endpoint = `https://api.github.com/repos`
        const uri = `${ endpoint }/nin-jin/HabHub/issues/${ this.numb() }`
        return this.$.$mol_github_issue.item( uri )
    }

    reload() {
        this.data( null )
    }

}

Even with a little more functionality (for example, support for color themes, localization, etc.), the code per $mol turned out to be 2 times less than in the version with JSX. And most importantly, cognitive complexity has decreased. But that's a completely different story..

In the meantime, I invite you to try $mol_wire in your projects. And if you have any difficulties, do not hesitate to ask questions in the topic about $mol on the Hyper Dev forum.

$mol_wire Conclusion

In total, by introducing a simple but flexible abstraction of channels, we have worked out many patterns for using them to achieve a variety of goals. Once we understand this, we can create applications of any complexity, and have fun integrating with a wide variety of APIs.

Adding reactive memoization channels with automatic revalidation, resource release and asynchrony support gave us both a radical simplification of the application code and an increase in its efficiency in consuming processor and memory resources.

And for those who, for some reason, are not yet ready to completely switch to the $mol framework, we have prepared several independent micro-libraries:

$mol_key (1 KB) - unique key for structures
$mol_compare_deep (1 KB) - fast deep comparison of objects
$mol_wire_pub (1.5 KB) - minimal publisher for integration into reactive runtime
$mol_wire_lib (7 KB) - a complete set of tools for reactive programming
$mol_wire_dom (7.5 KB) - the magic of turning a regular DOM into a ReactiveDOM.
$mol_jsx_view (8 KB) - truly reactive React.

Grab them in your hands and let's rock together!

Growth

Still not ready to rewrite your frontend again? Okay, let’s finally talk about the prospects.

I wrote this series for half a year, while simultaneously fighting a battle for two lives. One of them, unfortunately, has already been lost, but the second has not yet, so there is still time to bring our projects to independent viability. And there are quite a few of them...

First of all, this is the $mol framework, which has recently improved a lot:

He is already almost 7 years old, but he is still technologically ahead of even the most modern frameworks (hello, AngularJS, which a month did not live up to 6 years). He has all prospects increase the efficiency of domestic development. The company that decides to be the first will greatly outperform its competitors. Here are just a few real cases:

Well, while everyone is marking time, reinventing the next UI-Kit on ReactJS, we are already cutting open source web platform of the new generation:

Offline-first with real-time background synchronization.
A unique algorithm for conflict-free merging of changes without decryption and loss of digital signatures.
Resistance to server blocking, even working without servers at all.
An ecosystem of ultra-fast applications that are synergistically integrated with each other.
Fair, but not stressful donations with rewards for content, not just a subscription.

There are already the beginnings of a dozen applications:

An alternative to Google Workspace (there is already an MVP implementation of document editor, spreadsheet editor, and presentation viewer.
An alternative to GitHub, but for no-code and with a marketplace (there are prototypes of no-code constructor and conflict-free version control system.
A set of tools for online collaboration (there are prototypes of the messenger, whiteboard, knowledge base, interface prototyping.

In the meantime, we have already released four dozen innovative articles and dozen hardcore speeches.

And we've just begun! In the near future we plan to analyze in detail both the existing CRDT algorithms and our know-how, which will form the basis of a distributed reactive database. So stay tuned for news.

I am against paywalls, advertising, surveillance and other inhumane techniques. So you will still receive all our materials and developments completely free of charge. But if you like what we do, find it useful, and want to bring a brighter future closer as quickly as possible, then support with rubles.. no, not me, but the $hyoo guild, where the income received is distributed in proportion to the contribution of each participant to the development of the ecosystem.

Or grab your keyboard and start this $mol revolution together!

Reactive DOM

Jin — Mon, 04 Mar 2024 09:32:54 +0000

Previously, the DOM was slow and inconvenient. To cope with this, various template engines and techniques were invented: VirtualDOM, IncrementalDOM, ShadowDOM. However, the fundamental problems of RealDOM remain:

Greed. The browser cannot at any time ask the application code “I want to render this part of the page, generate me elements from the middle of the fifth to the end of the seventh.” We have to first generate a huge DOM so that the browser only shows a small part of it. And this is extremely resource-intensive.
Indifference. The state of the DOM logically depends on both application states and the states of the DOM itself. But the browser doesn't understand these dependencies, can't guarantee them, and can't optimize DOM updates.
Thorny. In fact, we don't need the DOM. We need a way to tell the browser how and when to render our components.

Well, okay, let's imagine what would happen if the DOM and the rest of the runtime were reactive. We could, without any libraries, connect any states through simple invariants and the browser would guarantee their execution in the most optimal way!

I sketched out a small sketch of what it might look like. For example, let's take and bind the paragraph text to the value of the input field:

<input id="input" />
<p id="output"></p>
<script>

    const input = document.getElementById('input')
    const output = document.getElementById('output')

    Object.defineProperty( output, 'innerText', {
        get: ()=> 'Hello ' + input.value
    } )

</script>

And that's it, no libraries, no event handlers, no DOM manipulation. Only our desires in their purest form.

Do you want to try ReactiveDOM in action right now? I published a prototype of the polyfill $mol_wire_dom.

It is not very efficient, it does not support many things, but for demonstration it will do:

<div id="root">

    <div id="form">
        <input id="nickname" value="Jin" />
        <button id="clear">Clear</button>
        <label>
            <input id="greet" type="checkbox" /> Greet
        </label>
    </div>

    <p id="greeting">...</p>

</div>

import { $mol_wire_dom, $mol_wire_patch } from "mol_wire_dom";

// Make DOM reactive
$mol_wire_dom(document.body);

// Make globals reactive
$mol_wire_patch(globalThis);

// Take references to elements
const root = document.getElementById("root") as HTMLDivElement;
const form = document.getElementById("form") as HTMLDivElement;
const nickname = document.getElementById("nickname") as HTMLInputElement;
const greet = document.getElementById("greet") as HTMLInputElement;
const greeting = document.getElementById("greeting") as HTMLParagraphElement;
const clear = document.getElementById("clear") as HTMLButtonElement;

// Setup invariants

Object.assign(root, {
    childNodes: () => (greet.checked ? [form, greeting] : [form]),
    style: () => ({
        zoom: 1 / devicePixelRatio
    })
});

Object.assign(greeting, {
    textContent: () => `Hello ${nickname.value}!`
});

// Set up handlers
clear.onclick = () => (nickname.value = "");

Here we also applied $mol_wire_patch to make global properties reactive. Therefore, when the browser zoom changes, the interface size will change to compensate. When you click the button, the name entered in the field will be cleared. And the current name will be displayed in the greeting, which is shown only when the checkbox is checked.

Now answer me a simple question: why don’t we still have something like this in browsers?!?

Reactive JSX

Jin — Sun, 03 Mar 2024 07:04:22 +0000

It’s not hard to see that by taking away state control from ReactJS, we’re actually dethroning it from the framework’s pedestal to the level of the DOM rendering library that it originally was. But this turns out to be a very heavy rendering library, doing too much unnecessary work and wasting a lot of memory.

Let's take bare, strongly typed JSX and make it reactive using $mol_wire, creating a complete ReactJS replacement, but without the VirtualDOM, but with spot updates to the real DOM and other nice goodies.

To do this, we will first take $mol_jsx, which is the same as E4X creates real DOM nodes, not virtual ones:

const title = <h1 class="title" dataset={{ slug: 'hello' }}>{ this.title() }</h1>
const text = title.innerText // Hello, World!
const html = title.outerHTML // <h1 class="title" data-slug="hello">Hello, World!</h1>

Wow! We no longer need ref to get the DOM-node from JSX, because we immediately get a DOM tree from it.

If you execute JSX for a reason, but in the context of a document, then instead of creating new elements, existing ones will be used, based on their identifiers:

<body>
    <h1 id="title">...</h1>
</body>

$mol_jsx_attach( document, ()=> (
    <h1 id="title" class="header">Wow!</h1>
) )

<body>
    <h1 id="title" class="header">Wow!</h1>
</body>

Wow! We also got hydration, but without the division into primary and secondary rendering. We simply render and existing elements are reused if they exist.

Wow! We also got correct moves components, instead of recreating them in a new place. And no longer within the framework of one parent, but within the entire document:

<body>
    <article id="todo">
        <h1 id="task/1">Complete article about $mol_wire</h1>
    <article>
    <article id="done"></article>
</body>

$mol_jsx_attach( document, ()=> (
    <article id="done">
        <h1 id="task/1">Complete article about $mol_wire</h1>
    <article>
) )

<body>
    <article id="todo"></article>
    <article id="done">
        <h1 id="task/1">Complete article about $mol_wire</h1>
    <article>
</body>

Pay attention to the use of natural HTML attributes id and class instead of ephemeral key and className.

Of course, you can use both templates (stateless functions) and components (stateful classes) as tags. The first ones are simply called with the correct context, which means they unconditionally render their content. And the latter create an instance of the object, delegate rendering control to it, and save a reference to it in the resulting DOM node in order to use it again during the next rendering. In runtime it looks something like this:

Here we see two components that returned the same DOM element as a result of rendering. Getting instances of components from a DOM element is not difficult:

const input = InputString.of( element )

So, let's create the simplest component - a text input field:

export class InputString extends View {

    // statefull!
    @mem value( next = "" ) {
        return next
    }

    // event handler
    change( event: InputEvent ) {
        this.value( ( event.target as HTMLInputElement ).value )
    }

    // apply state to DOM
    render() {
        return (
            <input
                value={ this.value() }
                oninput={ action(this).change }
            />
        )
    }

}

Almost the same code as with ReactJS, but:

Since reconciliation during rendering occurs with the real DOM, and not with the previous version of the virtual one, there is no need for the crutch of immediately updating the virtual DOM after processing the event, so that the carriage does not fly to the end when entering.
Events come native, not synthetic, which eliminates a lot of surprises.
Classes for styling are generated automatically based on component identifiers and names.
There is no need to manually collect element identifiers - semantic identifiers are also generated automatically.
For the root element, the identifier does not need to be specified at all - it is set equal to the component identifier.
If there is a conflict between identifiers, an exception is thrown, which guarantees their global uniqueness.

To illustrate the last points, let's look at a more complex component - a number input field:

export class InputNumber extends View {

    // self state
    @mem numb( next = 0 ) {
        return next
    }

    dec() {
        this.numb( this.numb() - 1 )
    }

    inc() {
        this.numb( this.numb() + 1 )
    }

    // lifted string state as delegate to number state!
    @mem str(str?: string) {

        const next = str?.valueOf && Number( str )
        if( Object.is( next, NaN ) ) return str ?? ""

        const res = this.numb(next)
        if( next === res ) return str ?? String( res ?? "" )

        return String( res ?? "" )
    }

    render() {
        return (
            <div>

                <Button
                    id="decrease"
                    action={ () => this.dec() }
                    title={ () => "➖" }
                />

                <InputString
                    id="input"
                    value={ next => this.str( next ) } // hack to lift state up
                />

                <Button
                    id="increase"
                    action={ () => this.inc() }
                    title={ () => "➕" }
                />

            </div>
        )
    }

}

Using the generated classes, it is easy to attach styles to any elements:

/** bem-block */
.InputNumber {
    border-radius: 0.25rem;
    box-shadow: 0 0 0 1px gray;
    display: flex;
    overflow: hidden;
}

/** bem-element */
.InputNumber_input {
    flex: 1 0 auto;
}

/** bem-element of bem-element */
.Counter_numb_input {
    color: red;
}

Unfortunately, it is not possible to implement a full-fledged CSS-in-TS in JSX, but even just auto-generation of classes already significantly simplifies styling.

For all this to work, you only need to implement a base class for reactive JSX components:

/** Reactive JSX component */
abstract class View extends $mol_object2 {

    /** Returns component instance for DOM node. */
    static of< This extends typeof $mol_jsx_view >( this: This, node: Element ) {
        return node[ this as any ] as InstanceType< This >
    }

    // Allow overriding of all fields via attributes
    attributes!: Partial< Pick< this, Exclude< keyof this, 'valueOf' > > >

    /** Document to reuse DOM elements by ID */
    ownerDocument!: typeof $mol_jsx_document

    /** Autogenerated class names */
    className = ''

    /** Children to render inside */
    @field get childNodes() {
        return [] as Array< Node | string >
    }

    /** Memoized render in right context */
    @mem valueOf() {

        const prefix = $mol_jsx_prefix
        const booked = $mol_jsx_booked
        const crumbs = $mol_jsx_crumbs
        const document = $mol_jsx_document

        try {

            $mol_jsx_prefix = this[ Symbol.toStringTag ]
            $mol_jsx_booked = new Set
            $mol_jsx_crumbs = this.className
            $mol_jsx_document = this.ownerDocument

            return this.render()

        } finally {

            $mol_jsx_prefix = prefix
            $mol_jsx_booked = booked
            $mol_jsx_crumbs = crumbs
            $mol_jsx_document = document

        }

    }

    /** Returns actual DOM tree */
    abstract render(): HTMLElement

}

Finally, having finished with the preparations, let’s write our application:

export class Counter extends View {

    @mem numb( value = 48 ) {
        return value
    }

    issue( reload?: "reload" ) {
        return GitHub.issue( this.numb(), reload )
    }

    title() {
        return this.issue().title
    }

    link() {
        return this.issue().html_url
    }

    render() {
        return (
            <div>

                <InputNumber
                    id="numb"
                    numb={ next => this.numb(next) } // hack to lift state up
                />

                <Safe
                    id="titleSafe"
                    task={ ()=> (
                        <a id="title" href={ this.link() }>
                            { this.title() }
                        </a>
                    ) }
                />

                <Button
                    id="reload"
                    action={ ()=> this.issue("reload") }
                    title={ ()=> "Reload" }
                />

            </div>
        )
    }

}

All code for this example can be found in sandbox. So in 1 evening we implemented our ReactJS based on $mol, adding a bunch of unique features, but reducing the volume of the bundle by 5 times. In terms of speed, we are neck and neck with the original:

What about the inverse task - writing an analogue of the $mol framework in ReactJS? You will need at least 3 million dollars, a team of a dozen people and several years of waiting. But we will not wait, but will undock this stage too..

Really Reactive React

Jin — Sat, 02 Mar 2024 10:13:19 +0000

ReactJS is now the most popular framework, despite many architectural blundes. Here are just a few of them:

The component does not track external states on which it depends; it is updated only when the local one changes. This requires careful subscriptions/unsubscriptions and timely notifications of changes.
The only way to change one parameter of a component is to completely re-render the external component, regenerating all the parameters for both it and neighbors. The same applies to adding/removing/moving a component.
When moving a component between containers, it is completely recreated. Conversely, different instances of the same component may be inappropriately reused.
Callbacks created on the fly lead to unnecessary rerenders, so they require careful memoization with a precise indication of the variables used inside them.
To update values in closures, you still have to recreate callbacks, which leads to unnecessary rerenders.
Hooks cannot be used in conditions, loops and other places where the execution flow is dynamic, otherwise everything will break.
Errors and wait indications occur outside the component. The component turns out to be not self-sufficient and fatally affects both the external component and, as a result, its neighbors.
The component cannot be partially updated - only a full rerender. To overcome this, they either coat themselves with memoization or unnecessarily increase the granularity of the components.
Lack of control of a stateful component often leads to the need to split each component into two: a controlled stateless and an uncontrolled stateful wrapper over it. Partial control is associated with difficulties and copy-paste.

Well, let's cure the patient, and at the same time show the ease of integration of the reactive library $mol_wire into a completely foreign architecture.

Let's start from afar - write a synchronous function that loads JSON via a link. To do this, write an asynchronous function and convert it to synchronous:

export const getJSON = sync( async function getJSON( uri: string ){
    const resp = await fetch(uri)
    if( Math.floor( resp.status / 100 ) === 2 ) return resp.json()
    throw new Error( `${resp.status} ${resp.statusText}` )
} )

Now let's implement the API for GitHub, with debounce and caching. We will only support loading issue data by its number:

export class GitHub extends Object {

    // cache
    @mems static issue( value: number, reload?: "reload" ) {

        sleep(500) // debounce

        const uri = `https://api.github.com/repos/nin-jin/HabHub/issues/${value}`
        return getJSON( uri ) as {
            title: string
            html_url: string
        }

    }

}

No matter how many times we access the data, the result will be returned from the cache, but if we still need to reload the data, we can pass an additional parameter to start the task of updating the cache. In any case, the request will not go immediately, but with a delay of half a second.

Now, finally, we move on to creating components. Contrary to the popular trend, we will not emulate objects through dirty functions with hooks, but will use class components. And in order not to repeat the same logic, let's create a base class for our components:

export abstract class Component<
    Props = { id: string },
    State = {},
    SnapShot = any
> extends React.Component<
    Partial<Props> & { id: string },
    State,
    SnapShot
> {

    // every component should have guid
    id!: string;

    // show id in debugger
    [Symbol.toStringTag] = this.props.id

    // override fields by props to configure
    constructor(props: Props & { id: string }) {
        super(props)
        Object.assign(this, props)
    }

    // composes inner components as vdom
    abstract compose(): any

    // memoized render which notify react on recalc
    @mem render() {
        log("render", "#" + this.id)
        Promise.resolve().then(() => this.forceUpdate())
        return this.compose()
    }

}

The main idea here is that each component should be completely self-sufficient, but at the same time controllable - any of its public fields can be overridden through props. All props are optional, except for the identifier, which we require to be set externally so that it is globally unique and semantic.

It is important to note that props are not tracked by the reactive system - this allows you to pass callbacks to them and this will not cause rerenders. The idea here is to separate the initialization (by pushing props) and the actual work (by pulling through callbacks provided in the props).

Initialization occurs when the class is constructed, and dynamic work occurs when the framework calls render. ReactJS is notorious for calling it too often. Here, thanks to memoization, we take over control from the framework over when rerenders will actually occur. When any dependency on which the rendering result depends changes, the reactive system will recalculate it and notify the framework about the need for rerender, then the framework will call render and will receive a fresh VDOM. In other cases, it will receive the VDOM from the cache and do nothing further.

This scheme of work will no longer allow the use of hooks in your logic, but with $mol_wire, hooks are like a dog’s fifth leg.

It's easier to understand how it works with specific examples, so let's create a simple component - a text input field:

export class InputString extends Component<InputString> {

    // statefull!
    @mem value( next = "" ) {
        return next;
    }

    change( event: ChangeEvent<HTMLInputElement> ) {
        this.value( event.target.value )
        this.forceUpdate() // prevent caret jumping
    }

    compose() {
        return (
            <input
                id={ this.id }
                className="inputString"
                value={ this.value() }
                onInput={ action(this).change }
            />
        )
    }

}

Here we have declared a state in which the entered text is stored by default, and the action causes the update of this state to be called upon input. At the end of the action, we force ReactJS to instantly pick up our changes, otherwise the caret will fly away at the end of the input field. In other cases this is not necessary. Well, when passing the action to VDOM, we wrapped it in a wrapper that simply turns a synchronous method into an asynchronous one.

Now let's use this component in the number input field, in which we will raise the text of the status input field:

export class InputNumber extends Component<InputNumber> {

    // self state
    @mem numb( next = 0 ) {
        return next;
    }

    dec() {
        this.numb(this.numb() - 1);
    }

    inc() {
        this.numb(this.numb() + 1);
    }

    // lifted string state as delegate to number state!
    @mem str( str?: string ) {

        const next = str?.valueOf && Number(str)
        if( Object.is( next, NaN ) ) return str ?? ""

        const res = this.numb( next )
        if( next === res ) return str ?? String( res ?? "" )

        return String( res ?? "" )
    }

    compose() {
        return (
            <div
                id={this.id}
                className="inputNumber"
                >

                <Button
                    id={ `${this.id}-decrease` }
                    action={ ()=> this.dec() }
                    title={ ()=> "➖" }
                />

                <InputString
                    id={ `${this.id}-input` }
                    value={ next => this.str( next ) } // hack to lift state up
                />

                <Button
                    id={ `${this.id}-increase` }
                    action={ ()=> this.inc() }
                    title={ ()=> "➕" }
                />

            </div>
        )
    }

}

Please note that we have overridden the value property of the text input field, so now it will store its state not in itself, but in our str property, which is actually a cached delegate to the numb property. Its logic is a little convoluted so that when an invalid number is entered, we do not lose user input due to its replacement with a normalized value.

You can notice that the VDOM we generated does not depend on any reactive states, which means it will be calculated only once during the first render, and will not be updated again. But despite this, the text field will respond correctly to changes in the numb properties. and as a consequence str.

The Button components are also used here. which have overridden methods called to get the name of the button and to perform an action when clicked. But more about buttons later, but for now let’s use all our developments to implement an advanced Counter, which not only switches the number with buttons, but also downloads data from the server:

export class Counter extends Component<Counter> {

    @mem numb( value = 48 ) {
        return value
    }

    issue( reload?: "reload" ) {
        return GitHub.issue( this.numb(), reload )
    }

    title() {
        return this.issue().title;
    }

    link() {
        return this.issue().html_url;
    }

    compose() {
        return (
            <div
                id={ this.id }
                className="counter"
                >

                <InputNumber
                    id={ `${this.id}-numb` }
                    numb={ next => this.numb( next ) } // hack to lift state up
                />

                <Safe
                    id={ `${this.id}-output-safe` }
                    task={ () => (

                        <a
                            id={ `${this.id}-link` }
                            className="counter-link"
                            href={ this.link() }
                            >
                            { this.title() }
                        </a>

                    ) }
                />

                <Button
                    id={ `${this.id}-reload` }
                    action={ () => this.issue("reload") }
                    title={ () => "Reload" }
                />

            </div>
        )
    }

}

As it is not difficult to notice, we have raised the state of the text input field even higher - now it operates with the number issue. Using this number, we load the data via the GitHub API and display it side by side, wrapped in a special component Safe, whose task is to handle exceptions in the code passed to it: when waiting, show the corresponding indicator, and in case of an error, show the error text. It is implemented simply - with the usual try-catch:

export abstract class Safe extends Component<Safe> {

    task() {}

    compose() {

        try {
            return this.task()
        } catch( error ) {

            if( error instanceof Promise ) return (
                <span
                    id={ `${this.id}-wait` }
                    className="safe-wait"
                    >
                    💤
                </span>
            )

            if( error instanceof Error ) return (
                <span
                    id={ `${this.id}-error` }
                    className="safe-error"
                    >
                    {error.message}
                </span>
            )

            throw error
        }

    }
}

Finally, let’s implement a button, but not a simple one, but a smart one that can display the status of the task being performed:

export class Button extends Component<Button> {

    title() {
        return ""
    }

    action( event?: MouseEvent<HTMLButtonElement> ) {}

    @mem click( next?: MouseEvent<HTMLButtonElement> | null ) {
        if( next ) this.forceUpdate()
        return next;
    }

    @mem status() {

        const event = this.click()
        if( !event ) return

        this.action( event )
        this.click( null )

    }

    compose() {
        return (

            <button
                id={this.id}
                className="button"
                onClick={ action(this).click }
                >

                { this.title() } {" "}

                <Safe
                    id={ `${this.id}-safe` }
                    task={ () => this.status() }
                />

            </button>

        )
    }

}

Here, instead of immediately launching the action, we put the event in the reactive property click, on which the status property depends, which is already responsible for launching the event handler. And so that the handler is called immediately, and not in the next animation frame (which is important for some JS APIs like clipboard), forceUpdate is called. Himself status in normal situations it does not return anything, but in case of a wait or an error it shows the corresponding blocks thanks to Safe.

All the code for this example can be found in sandbox:

Logs have also been added there so you can understand what is happening. For example, this is what the primary rendering looks like:

render #counter 
render #counter-numb 
render #counter-numb-decrease 
render #counter-numb-decrease-safe 
render #counter-numb-input 
render #counter-numb-increase 
render #counter-numb-increase-safe 
render #counter-title-safe 
render #counter-reload 
render #counter-reload-safe 

fetch GitHub.issue(48) 
render #counter-title-safe 
render #counter-title-safe

Here #counter-title-safe was rendered 3 times because first it showed 💤 on debounce, then while waiting for the data to actually load, and at the end it showed the loaded data.

When you press Reaload again, nothing unnecessary is rendered - only the wait indicator on the button changes, since the data ultimately did not change:

render #counter-reload-safe

fetch GitHub.issue(48)
render #counter-reload-safe
render #counter-reload-safe

Well, when you quickly change the number, the text input field is updated and the heading that depends on it is displayed:

render #counter-numb-input
render #counter-title-safe

render #counter-numb-input
render #counter-title-safe

fetch GitHub.issue(4)
render #counter-title-safe
render #counter-title-safe

In total, what problems we solved:

✅ The component automatically tracks external states pointwise (not like with Redux).
✅ Component parameters are updated without rerendering the parent.
❌ Component movement is still controlled by ReactJS.
✅ Changing the callback does not lead to rerendering.
✅ Our analogue of hooks can be used anywhere in the code, even in loops and conditions.
❌ Error handling is still managed by ReactJS, so it requires manual work.
✅ For a partial update, you can create a component that accepts a closure.
✅ stateful components are fully controlled.

You can modify this example and design it as a library like remol if you are ready to support it. Or implement similar integration for any other framework. In the meantime, we are undocking the first stage and flying even higher...

Kinds of Reactive Fibers

Jin — Fri, 01 Mar 2024 11:10:34 +0000

If a subscriber not only performs some effect, but changes some state, then it can act as a publisher, which allows it to be not only at the ends of the reactive graph, but also to form its body. And any fiber is just an extended PubSub.

// Meta Size: 64B+
// Edge Cost: 16B
// Allocations: 3
interface Fiber<
    Result = unknown,
    Host = unknown,
    Args = unknown[]
> extends PubSub { // 52B
    host: Host // 4B
    task: ( this: Host, args: Args )=> Result // 4B
    cache: Result // 4B
}

There are two main types of fibers:

Task - one-time reactive calculation
Atom - long-lived reactive state

Reactive Tasks

Task has the same semantics as a regular function call. But if a normal function returns control only after has finished, this problem may be temporarily stopped halfway through and then continue to run in place, in response to some event.

Native JS runtime supports tasks only in the form of abstractions generator and asynchronous function, but:

It would be cool for the Fiber Proposal to be adopted into the standard, but it's been at stage -1 for several years now. So it's not what they don’t implement it, but on the contrary, even the extension for NodeJS node-fibers was recently completely broken.

But there is also work in accordance with convention, known as SuspenseAPI. First it was implemented in the $mol framework, where it is most actively used. So far it has been implemented in ReactJS, but with a bunch of prohibitions:

This only works during rendering.
It is unacceptable to use it in loops, branches, etc.

Later I’ll tell you how to implement this normally, but for now I’m writing about the main idea: the code is written normally, synchronously, but when you need to pause, a promise is thrown as an exception, and when the promise ends, the code is restarted.

This idea is quite fiery, but, like any workround, there are a number of limitations:

The code of the restarted task must be idempotent, otherwise the result will be incorrect.
The code up to the restart point should be either lightweight or memoized, otherwise everything will slow down.

These limitations are easily overcome: heavy or non-idempotent code is used in the project under tasks, which, if completed, are finalized and never restarted. And when the external task is restarted, they immediately return the value from the cache.

In this case, let's load the data by logging the process:

// Auto wrap method call to task
@act main() {

    // Convert async api to sync
    const syncFetch = $mol_wire_sync( fetch )

    this.log( 'Request' ) // 3 calls, 1 log
    const response = syncFetch( 'https://example.org' ) // Sync but non-blocking

    // Synchronize response too
    const syncResponse = $mol_wire_sync( response )

    this.log( 'Parse' ) // 2 calls, 1 log
    const response = syncResponse.json() // Sync but non-blocking

    this.log( 'Done' ) // 1 call, 1 log
}

// Auto wrap method call to sub-task
@act log( ... args: any[] ) {

    console.log( ... args )
    // No restarts because console api isn't idempotent

}

The @act decorator automatically wraps the calling method in a task. But if we are already in some task, then it will try to reuse the same sequence for the task from the external fiber source. And if this succeeds, the last task either continues to run or immediately returns a value from it without a start method.

But what could go wrong?

Call another method.
Calling a method on another object.
Calling methods with other arguments (we check them using $mol_compare_deep).

In these cases, we cannot reuse the past task and also create a new. That is, even if the programmer allowed some non-idempotency, we will not start executing a task that does not correspond to the current call method - that would be simply crazy. Instead, we throw out old tasks and create new ones for a new scenario.

If we were not using object methods:

if( Math.random() > .5 ) {
    return useMemo( ()=> 'foo' )
} else {
    return useMemo( ()=> 'bar' )
}

.. then a new function was created with each call, and we could not compare any function, nor the closure arguments, and therefore try to reuse a random task, which could lead, for example, to the fact that executing line 2 might return "bar" .

Reactive Atoms

An atom has the semantics of a mutable reactive variable encapsulated along with a formula for recalculating its value. Whenever we access the value of an atom, it always returns the current value. Well, either it asks you to wait, but this is also relevant, since it may not have the data yet.

If, when pulling a value from one atom, another is accessed, then they are automatically connected as a subscriber-publisher. If an atom is accessed from a task, then it is no longer possible to directly connect them, since pulling from an atom is not idempotent, because the atom can update its value between task restarts.

As an example, we can give the task of switching a flag:

@act toggle() {
    this.completed( !this.completed() ) // read then write
}

@mem completed( next = false ) {
    $mol_wait_timeout( 1000 ) // 1s debounce
    return next
}

If a task subscribes to an atom that creates @mem under the hood, then every time it is restarted it will receive a new flag value, try to set the opposite value, and go to sleep until the next restart. And so on until the end of time.

Therefore, any access to an atom from a task is automatically wrapped in another task, which memoizes the work performed, and, like any task, upon completion, unsubscribes from all its dependencies. That is, when reading, we get, as it were, a snapshot of the value of the atom, which will never change for the current task. But with multiple reading, you get a lot of snapshots, each of which can have its own value.

Pushing a new value into an atom is similarly memoized via an intermediate task, since pushing is not idempotent. Even if the channel wrapped in an atom is trivial and simply returns the passed value, several tasks can be pushed into the atom competitively, and when restarted there should be no unexpected rollbacks of the states of the atoms.

Perfect Reactive Dependency Tracking

Jin — Wed, 21 Feb 2024 07:52:15 +0000

All states in our application must be interconnected and thus form a connected directed acyclic graph (DAG). Each node in this graph has two types of neighbors:

Pub(lisher) - the source of truth on the basis of which this state is built.
Sub(scriber) - a dependent state for which the given is the source of truth.

The list of publishers is usually updated entirely. If some node did not appear in the new list, then an unsubscribe should occur. The composition of subscribers changes arbitrarily, but connections between publishers and subscribers are always two-way.

We need a list of publishers so that we know who to unsubscribe from. And a list of subscribers to notify them about changes in a timely manner. These links have other useful uses. In particular, when debugging, you can walk through them and see who really depends on whom.

Fibers

Let's combine the state, the formula for calculating it, lists of neighbors and other meta information into one abstraction: fiber is a memoizable task with reactive revalidation. Naively in code it can be represented like this:

// Meta Size: 216B+
// Edge Cost: 16B
// Allocations: 6
interface Fiber<
    State = unknown,
    Host = unknown,
    Args = unknown[]
> extends Object { // 12B
    host: Host // 4B for calculation context
    task: ( this: Host, args: Args )=> State // 4B for calculation function
    args: Args // 4B + 16B + 8B+ for calculation arguments
    state: State // 4B for calculation result
    cursor: number // 4B for current status or publisher tracking position
    pubs: Set< Fiber > // 4B + 16B + 60B+ for publishers
    subs: Set< Fiber > // 4B + 16B + 60B+ for subscribers
}

But there are the following problems:

Consumes a lot of memory.
There is a lot of memory allocation going on.
Data is highly fragmented in memory.
Constant rehashing of internal hash tables occurs.
Basic operations, although they usually occur in O(1), but are heavy in themselves.
To determine publishers requiring unsubscription, several memory allocations are required.

The most optimal thing is to get rid of hash tables and combine all dynamic data in one single array, which will require only 3 memory allocations (for the object itself, for the static part of the array and dynamic):

// Meta Size: 64B+
// Edge Cost: 16B
// Allocations: 3
interface Fiber<
    State = unknown,
    Host = unknown,
    Args = unknown[]
> extends Object { // 12B
    host: Host // 4B for context
    task: ( this: Host, args: Args )=> State // 4B for calculation
    data: Array< Args[number] | Fiber | number > // 28B+ for arguments, publishers, subscribers
    state: State // 4B for result
    cursor: number // 4B for current status or publisher tracking position
    pub_from: number // 4B for offset of publishers in data
    sub_from: number // 4B for offset of subscribers in data
}

As you can see, we moved all parts that vary in size (arguments, publishers, subscribers) into array elements, leaving only indices in the object fields that divide the array into sections. This allowed us to reduce reactivity overhead by several times.

It would be possible to save even more memory, at the same time reducing the number of memory allocations to 2, if you inherit from a native array rather than aggregate it, but this is somewhat slower, clutters the object with array methods, and is not very convenient for debugging.

Graphically, the structure of connections between two neighbors can be represented by the following example, where fiber A depends on B:

Each link occupies two array elements: the first contains a link to its neighbor, and the second contains the index at which the reverse link is located in this neighbor. Thus, all our connections are not just two-way, but we always know the offsets in the array, which makes it easy to add, remove and move them around the array in O(1).

Note that the subscribers always lie in a continuous, unordered heap at the end. But publishers are always ordered, so they may contain holes. These holes appear from temporary publishers, which self-destruct after calculating the subscriber, so these holes do not grow uncontrollably.

It can also be noted that the same fibers can be linked several times. This happens when the same fiber is accessed several times from another of the same fiber. This could have been avoided, but the benefits gained would not outweigh the costs of deduplication. In any case, we can recommend, if possible, to save the value received from the channel into a local variable, so as not to yank the reactive machinery once again:

title_double() {
    const title = this.title()
    return `${title}:${title}`
}

Publishers

Sometimes we don’t need a whole fiber with its formulas, states, etc., but something simpler. For example, we want to make some arbitrary state observable and that’s it. Let's throw out everything unnecessary so that the minimal node of our reactive graph - the publisher remains:

// Meta Size: 44B
// Edge Cost: 16B
// Allocations: 3
interface Pub extends Object { // 12B 
    data: Array< Args[number] | Fiber | number > // 28B
    sub_from: number // 4B
}

To demonstrate how it works, let's make a regular local variable reactive:

const pub = new $mol_wire_pub

let _counter = 0

const counter = ( next?: number )=> {

    if( next === undefined ) {
        pub.promote()
        return _counter
    }

    if( Object.is( next, _counter ) ) return _counter

    pub.emit()

    return _counter = next
}

Now, if we work with this variable through the channel we created, then:

When reading, the current subscriber will automatically subscribe to our publisher.
When recording, all subscribers of the publisher will be notified of the change.

Thus, we can make any state reactive, even one that does not belong to us. For example, the current page address:

const pub = new $mol_wire_pub

window.addEventListener( 'popstate', ()=> pub.emit() )
window.addEventListener( 'hashchange', ()=> pub.emit() )

const href = ( next?: string )=> {

    if( next === undefined ) {
        pub.promote()
    } else if( document.location.href !== next ) {
        document.location.href = next
        pub.emit()
    }

    return document.location.href
}

Let's assemble this module into a separate bundle and post it in NPM: mol_wire_pub. It allows you to make any of your structures observable, adding only 1.5KB to the weight of your library.

So, for example, we have our own implementation of CRDT $hyoo_crowd, which can be used the old fashioned way, without reactivity, but in a reactive environment it is automatically becomes observable without any dancing with a tambourine.

Therefore, if you are the author of a library that works with state, then I encourage you to add integration with mol_wire_pub so that your users do not have a headache about tracking changes. To illustrate, let's make an ordinary set observable. To do this, we will inherit from the native one and overload all methods:

namespace $ {
    export class $mol_wire_set< Value > extends Set< Value > {

        pub = new $mol_wire_pub

        // Some accessors

        has( value: Value ) {
            this.pub.promote()
            return super.has( value )
        }

        get size() {
            this.pub.promote()
            return super.size   
        }

        // Some mutators

        add( value: Value ) {
            if( super.has( value ) ) return this
            super.add( value )
            this.pub.emit()
            return this
        }

        delete( value: Value ) {
            const res = super.delete( value )
            if( res ) this.pub.emit()
            return res
        }

    }

}

As you can see, all methods can be divided into two types: reading and changing. In the reading ones we call .promote(), and in the changing ones - .emit(), if the changes actually happened.

We have omitted some methods here. The complete set can be found in the sources $mol_wire_set.

Subscribers

To keep track of observable states, we may need another lightweight abstraction - a subscriber:

// Meta Size: 52B
// Edge Cost: 16B
// Allocations: 3
interface Sub extends Object { // 12B
    data: Array< Args[number] | Fiber | number > // 28B
    sub_from: number // 4B
    pub_from: number // 4B
    cursor: number // 4B
}

Typically, the subscriber itself can act as a publisher, and the logic of two-way links is common, so it makes sense to combine them:

// Meta Size: 52B
// Edge Cost: 16B
// Allocations: 3
interface PubSub extends Pub { // 44B
    pub_from: number // 4B
    cursor: number // 4B
}

Now, let's look at the dependency tracking loop. The idea here is simple:

The subscriber places itself in the global channel $mol_wire_auto() and sets its cursor to 0.
Then it reaches out to publishers in a roundabout way via .promote().
The publisher looks into that global channel and automatically links to the subscriber at its cursor position and increments it.
If there is already another publisher in this position, it flies to the end of the list of publishers.
If there is already a subscriber in this place, then it is first deported to the end of the array.
At the end, the subscriber cleans up the tails, removing unnecessary publishers, and filling their place with subscribers from the end of the array.

As a result, we receive an organized, up-to-date list of publishers and automatic unsubscribe from publishers who are no longer on this list.

You may have realized that you could immediately unsubscribe from an unnecessary publisher, and not temporarily move it to the end. But if you do this, then if the subscriber’s position changes, it may happen that first there will be an unsubscribe, and only then a subscription. And if we were the only subscriber to this publisher, then it will self-destruct, which can be much more difficult than rearranging several elements in an array.

A simple example of a subscriber working with publishers:

const susi = new $mol_wire_pub_sub
const pepe = new $mol_wire_pub
const lola = new $mol_wire_pub

const backup = susi.track_on() // Begin auto wire
try {
    touch() // Auto subscribe Susi to Pepe and sometimes to Lola
} finally {
    susi.track_cut() // Unsubscribe Susi from unpromoted pubs
    susi.track_off( backup ) // Stop auto wire
}

function touch() {

    // Dynamic subscriber
    if( Math.random() < .5 ) lola.promote()

    // Static subscriber
    pepe.promote()

}

Please note that we first backup the previous value of the global variable, and then restore it from the backup. This is necessary so that auto-tracking can be nested within each other.

It would be possible to wrap the logic for working with backup and try-finally in a wrapper around the closure, but then we would have a lot of intermediate functions on the stack, which would significantly reduce the depth of calls available to the application programmer.

It would be possible to return not a link, but a lightweight object with a rollback method:

const tracker = susi.track()
try {
    touch()
} finally {
    tracker.stop( !!'cut needless pubs' )
}

But then we would get extra memory allocation in very hot code.

We should also talk about the .track_cut() call. When we finish tracking publishers, we have a choice: to unsubscribe from publishers that we previously tracked but have not reached now, or not. So, this method goes through untouched publishers and performs these unsubscribes.

It usually makes sense to call it when a computation has completed normally. If we exited the calculation without completing it ahead of schedule (for example, we returned control because we were waiting for a download from the server), then it is better not to unsubscribe from anyone, since we may soon need those publishers when the download is completed.

Reactive Object Composition

Jin — Thu, 15 Feb 2024 20:17:20 +0000

Controlled Objects Setup

Using delegation, we can create local aliases for third-party channels. But sometimes we need to do the opposite, transfer control of the channel to ourselves, and leave an alias to our channel in the subordinate object. This is not difficult to do by replacing the channel when creating an object. For example, let’s take control of the duration channel from the task:

class Project_limited extends Project {

    @mems task( id: number ) {
        const task = new Task( id )
        task.duration = duration => this.task_duration( id, duration )
        return task
    }

    @mems task_duration( id: number, duration = 1 ) {
        return Math.min( duration, this.duration_max() )
    }

    duration_max() {
        return 10
    }

}

Now the duration of a task from the project, even if desired, cannot exceed the limit we set. And since task durations and limits themselves are channels, their management can just as easily be intercepted by the account that owns the project, lifting the state even upper in the application hierarchy:

class Account_limited extends Account {

    @mems project( id: number ) {
        const project = new Project_limited( id )
        project.duration_max = ()=> this.duration_max()
        return project
    }

    duration_max( max = Number.POSITIVE_INFINITY ) {
        return max
    }

}

Hacking is a powerful technique that allows you to connect objects with each other in a variety of directions. At the same time, without losing either speed or reliability, since:

Multiple objects operate simultaneously on the same state, instead of constantly synchronizing multiple local states with each other.
The owner has full control over the state access rules for each object.
Typescript checks the compatibility of function signatures when replacing, which reduces the risk of making mistakes during hacking.
Dependencies are tracked dynamically, so changing channels does not break reactivity.
The object knows only about the objects it owns, but knows nothing about its owner and neighbors.

In the following diagram you can see an ownership tree of 5 objects that share a shared state located in one of them in the middle of the hierarchy:

Channel Binding Variants

In many frameworks, such a thing as binding is very common - synchronizing several states 1-to-1. Typically there are two types of binding:

One-sided, where one state is the source of truth, and the second cannot be changed directly - it is set automatically equal to the first.
Two-sided, where you can change any state, and the second one is updated automatically.

Two-way binding has a serious problem: if synchronization does not occur immediately when one of the states changes, then it is possible to get a conflict when several states are changed in an incompatible way. Therefore, one often encounters a refusal of two-way binding. However, even one-way binding under these conditions is subject to the problem of observable temporal desynchronization, which can lead to unpredictable consequences.

The approach with delegation and hacking on channels allows us to solve the mentioned problems at the root by eliminating the duplication of state. At the same time, we no longer have two, but four types of binding, through which we can very accurately control information flows between objects:

One-way Hacking
Two-way Hacking
One-way Delegation
Two-way Delegation

A simple example illustrating all these options:

class Project extends Object {

    @mems task( id: number ) {
        const task = new Task( id )

        // Hacking one-way
        // duration <= task_duration*
        task.duration = ()=> this.task_duration( id )

        // Hacking two-way
        // cost <=> task_cost*
        task.cost = next => this.task_cost( id, next )

        return task
    }

    // task's duration source of truth
    @mems task_duration( id: number, next = 0 ) {
        return next
    }

    // task's cost source of truth
    @mems task_cost( id: number, next = 0 ) {
        return next
    }

    // Delegation one-way
    // status => task_status*
    task_status( id: number ) {
        return this.task( id ).status()
    }

    // Delegation two-way
    // title = task_title*
    task_title( id: number, next?: string ) {
        return this.task( id ).title( next )
    }

}

Developer Experience

When all objects are created through local factories that take ownership of them, we get a useful bonus: the factory knows its name, the object creation parameters, has a reference to the owner object, and can get its name. This gives it the ability to assign a unique name to the captured object that reflects its semantics.

A simple example where we get several objects and what names they get:

class App extends Object {

    @mems account( id: number ) {
        return new Account( id )
    }

}

const app = new App

// define name of root object directly
app[ Symbol.toStringTag ] = 'app'

const account = app.account(1) // app.account(1)
const project = account.project(23) // app.account(1).project(23)
const task = project.task(456) // app.account(1).project(23).task(456)

By entering this name into the console, we get the corresponding object:

As you can see, factories store the objects they create in the owner, which allows you to easily and simply navigate through objects using developer tools, and at any time understand what kind of object is in front of us.

The easiest way to explain to the debugger how to display our object is to specify the object name using Symbol.toStringTag. In Chrome, this name will also be displayed in stack traces:

And even in the monitoring service, you just need to take a quick look at the stacktrace to understand: yeah, the user clicked on “complete all tasks” in the header, but when writing to the local storage, he caught an exception.

A more advanced way is to use custom formatters to dynamically draw content in the debugger. With their help, we can make navigation through our dependency tree more visual:

Here we see 6 subscriptions for 4 publishers, one of which has the value true, but it is outdated (red), so it will be automatically updated as soon as someone accesses it, and the rest are current (green), so there will be no recomputing.

Finally, we can monitor changes in a subgraph of the reactive state graph, and, for example, log them:

Here we see that the user followed the link, which led to a targeted update of the application states in the most optimal order.

And this is just a special case of using such identifiers. They still have many different uses in testing, styling, statistics, etc. I wrote more about it in the article:

Element Names Fractal

Reactive Resources Management

Jin — Tue, 13 Feb 2024 06:34:00 +0000

The channel that creates, configures and memoizes an object will be called a factory. The consumer does not care when and how the object is created. Just as it doesn’t matter when this object needs to be destroyed. He just needs to know how to get it at the next recalc. And the factory itself will figure out when to create it and when to destroy it.

For example, let's create a project that will own all our tasks and an account that will own all our projects:

class Project extends Entity {

    @mems task( id: number ) {
        return new Task( id )
    }

}

class Account extends Entity {

    @mems project( id: number ) {
        return new Project( id )
    }

}

Now we can receive an object through one channel, and through it access another channel to receive a third object, and be sure that there will be no Null Pointer Exception or memory leaks:

class App extends Object {

    @mems static account( id: number ) {
        return new Account( id )
    }

    @act static main() {
        console.log( this.account(1) )
        console.log( this.account(1).project(23) )
        console.log( this.account(1).project(23).task(456) )
    }

    static [ Symbol.toStringTag ] = 'App'

}

App.main()
// logs
//      App.account(1)
//      App.account(1).project(23)
//      App.account(1).project(23).task(456)

In this example, 3 objects will be automatically created, which will be kept in memory until the function completes, and then will be automatically destroyed.

For all this to work, objects must implement the destructor method, which signals to the factory that this is not just a structure, but an object whose lifetime can be controlled**. When it is created, constructor is called automatically by JS runtime. And the destructor for destruction is called automatically by the factory when it, through the dependency tracking system, understands that the object is no longer needed by anyone.

Since the reactive system always knows which objects are actually needed, and not just available via links from the runtime root, this makes it theoretically possible to abandon the garbage collector altogether, and at the same time have deterministic release of resources. In JS you cannot disable the garbage collector, but in other languages this is an interesting direction for further research.

In addition to automatically controlling the life cycle of objects, these lazy factories give us one more bonus: the ability to raise only part of the application, and not the whole of it. This is especially true during component testing, where we can take the entire application, call the logic we are interested in, and be sure that only the part of the application necessary for it is raised. This gives extremely short test execution time, even without the use of mocks.

class Test {

    @act data_fields_should_be_independent() {

        // given
        cosnt task = App.account(1).project(23).task(456)
        $mol_assert_unique( task.duration(), 3 )
        $mol_assert_unique( task.title(), 'test title' )

        // when
        task.title( 'test title' )
        task.duration( 3 )

        // then
        $mol_assert_equal( task.duration(), 3 )
        $mol_assert_equal( task.title(), 'test title' )

    }

}

In this test, only 3 objects are created, regardless of how many other channels, factories, dependencies and other abstractions there are in our application.

As you can see, a reactive system can simulate an entire world for you on the fly, and you won't even notice it ~~until it breaks, of course~~.

Сhannel - Universal Reactive Abstraction

Jin — Sat, 10 Feb 2024 21:14:41 +0000

It is good to describe reactive invariants in the semantics of pull, so as not to calculate them again. But to process actions, we need push semantics, so as not to miss a single event, but to deliver it to the right place in the right form, from where further pull will begin.

In native JS there is a special syntax for this - getters and setters:

_title = ''
get title() { return this._title } // pull
set title( text: string ) { this._title = text } // push

But it have a lot of limitations:

We cannot pass any additional parameters.
It require an owner object.
It cannot be asynchronous.
Quite a lot of code, especially when delegating.

In some frameworks, hooks like this are common:

//               push         pull
const [ title, setTitle ] = useState( '' )

But it isn't efficient and it isn't convenient to use, since it don't separate the initialization phase (setting the default, receiving a push callback) from the phase of working with values (pulling and pushing the value). In addition, for two-way binding you have to write a lot of code like:

<Input value={ title } onChange={ setTitle } />

We will introduce the abstraction "channel" - a function that, depending on the number of arguments, can act as both a getter and a getter-setter. You can both pull the current value out of it and push a new one into it, obtaining the current result.

Let's create a simple channel to understand its essence:

let _title = ''
const title = ( text = _title )=> _title = text

title() // ''
title( 'Buy some milk' ) // 'Buy some milk'
title() // 'Buy some milk'

Experience with various abstractions in JS has shown that channels are the most practical of them. It abstract the consumer who wants to read and/or write some value from how that value is actually obtained and stored.

For example, we can easily ignore writing a value, and when reading, generate it on the fly, thus obtaining a read-only channel:

let id = ( dur?: number )=> Math.floor( Math.random() * 100 )

id() // 34
id( 18 ) // 83
id() // 13

We can make it write-only events, using it as an event handler:

let _completed = false
complete( event: Event ) {
  _completed = true
}

Or we can completely delegate one channel to another:

let details = ( text?: string )=> title( text )

details() // ''
details( 'Buy some milk' ) // 'Buy some milk'
details() // 'Buy some milk'

Thus, channels can be arranged in chains, transforming data as it intersects layers of abstractions:

let details_html = ( html?: string )=>
html_encode(
  details(
    html && html_decode( html )
  )
)

details() // ''
details_html( 'Buy milk &amp; bread' ) // 'Buy milk &amp; bread'
details() // 'Buy milk & bread'
details_html() // 'Buy milk &amp; bread'

Channels can be:

stateless - don't storing any data, but only access other channels.
stateful - storing initial data or calculation caches.

Note that singleton channels are not very practical, because they do not allow us to decompose the application. That's why we need OOP...

Object Reactive Programing

Objects allow us to group channels that are related in meaning into a single capsule. Moreover, they allow us to have many such capsules built from the same code (class instances). Simple example:

class Task extends Object {

  // stateful channel
  _title = ''
  title( title = this._title ) {
    return this._title = title
  }

  //stateless channel
  details( details?: string ) {
    return this.title( details )
  }

}

Note that if everything is quite simple with delegates, then with channels that store state, everything is not so rosy: the channel name has to be repeated 4 times. This means that when copy-pasting there will inevitably be problems, because you will have to make the same edits 4 times. And auto-refactoring will not help us here.

Well, notice that we always return the value that we store, and we always store what we want to return. This means that we can write a decorator that will take care of all this:

class Task extends Object {

  @mem title( title = '' ) {
    return title
  }

  details( details?: string ) {
    return this.title( details )
  }

}

Well, or like this, if we are unlucky with the programming language:

class Task extends Object {

  title( title = '' ) {
    return title
  }

  details( details ) {
    return this.title( details )
  }

}
mem( Task.prototype, 'title' )

All we need to know now is that the $mol_wire_solo decorator memoizes the value returned from the method, regardless of whether we passed it an argument or not. However, if the argument was not passed, and there is already something in the cache, then the method call is skipped and the value from the cache is immediately returned. And this will continue until the cache is cleared. And if the cache is empty, the method is still called to get the default value. Well, if the argument is passed, then the method will be called in any case to update the cache.

In addition to code brevity, memoization gives us a couple more important properties: computational savings and idempotency. Let's illustrate this with the following example:

class Task_extended extends Task {

  @mem title_for_mirror() {
    const segmenter = new Intl.Segmenter()
    const segments = [ ... segmenter.segment( this.title() ) ]
    return segments.map( s => s.segment ).reverse().join('')
  }

  @mem Duration() {
    return new $mol_time_duration({ hour: this.duration() })
  }

}

The first method is quite heavy, but thanks to memoization it will be executed only once, and lazily, at the time of the first call, and then the value will be returned from the cache until the value of title changes, of course.

The second method is not so much heavy as it returns a new object each time, which is often unacceptable. Here memoization makes it possible to guarantee that no matter how many times we call a method, the result of its call will be the same. This property is called idempotency.

Experience suggests that when designing an application architecture, it is extremely important that it be as idempotent as possible, because any non-idempotency is a time bomb. We will not substantiate this in detail now. However, idempotency will come in handy later.

For now, let’s remember the famous statement:

There are only two hard things in Computer Science: cache invalidation and naming things.

Two common problems in any field of programming are mentioned here. So, in this series we will solve the first completely, and the second... not completely, but we will make it less problematic.

Recomposition

A channel can produce not only simple types of data, but also complex ones, including those collected from other channels. For example, let's collect all the object data in the form of one DTO:

class Task extends Object {

  @mem title( title = '' ) {
    return title
  }

  @mem duration( dur = 0 ) {
    return dur
  }

  @mem data(
    data?: Readonly< Partial< {
      title: string
      dur: number
    } > >
  ) {
    return {
      title: this.title( data?.title ),
      dur: this.duration( data?.dur ),
    } as const
  }

}

Please note that through a compound channel we can update several simple channels at once:

const task = new Task
task.data() // { title: '', dur: 0 }

const data = task.data({
  title: 'Buy milk',
  dur: 2,
})
task.title() // 'Buy milk'
task.duration() // 2

Conversely, channels can be lenses that allow you to work with part of a large immutable structure, as with an independent mutable entity:

class Task extends Object {

  @mem data( data = {
    title: '',
    dur: 0,
  } ) {
    return data
  }

  @mem title( title?: string ) {
    return this.data(
      //title === undefined ? undefined : { ... this.data(), title }
      title?.valueOf && { ... this.data(), title }
    ).title
  }

  @mem duration( dur?: number ) {
    return this.data(
      dur?.valueOf && { ... this.data(), dur }
    ).dur
  }

}

Please note that these two diametrically opposed approaches lead to the same object interface. This is the main advantage of channels - they allow you to change internal implementation within a fairly wide range without affecting consumers. Moreover, it allow you to customize the internal operation of objects from outside without breaking their operation. But more on that later.

Multiplexing

So far we have named each channel individually. But sometimes we need to write one code for an unlimited set of channels. Here multiplexed channels come to our aid, where the first parameter is the key identifying the channel. For example, let's get rid of the copy-paste of relatively complex logic from the previous section, moving it into a common super class:

class Entity extends Object {

  constructor(
    readonly id: number
  ) { super() }

  destructor() {}

  @mem data( data = {} ) {
    return data
  }

  @mem value<
    Field extends keyof ReturnType< this['data'] >
  >(
    field: Field,
    value?: ReturnType< this['data'] >[ Field ],
  ): ReturnType< this['data'] >[ Field ] {

    return this.data( value === undefined
      ? undefined
      : {
        ... this.data(),
        [ field ]: value,
      }
    )[ field as never ]

  }

}

Now, we can work with the data channel through the multiplexed value channel, without having to do manual (de)structuring:

class Task extends Entity {

  @mem data( data = { title: '', dur: 0 } ) {
    return data
  }

  title( title?: string ) {
    return this.value( 'title', title )
  }

  duration( dur?: number ) {
    return this.value( 'dur', dur )
  }

}

Now let's redirect state storage from memory to local storage:

// At first tab
const task0 = new Task
task0.data = data => $mol_state_local.value( `task=0`, data )
  ?? { title: '', cost: 0, dur: 0 }
task0.title( 'Buy some milk' ) // 'Buy some milk'

// At second tab
const task0 = new Task
task0.data = data => $mol_state_local.value( `task=0`, data )
  ?? { title: '', cost: 0, dur: 0 }
task0.title()                  // 'Buy some milk'

And since our channels are reactive, then applications in different tabs receive instant synchronization automatically: