DEV Community: valentin

May I humbly submit you my front-end framework ?

valentin — Fri, 08 Mar 2024 07:31:12 +0000

Hi everyone, I'll present you what I consider my best personal achievement so far: a framework purely based on Reactive Programming (ak: Observables and Signals) to create great web applications.

I did it because I was seeing the advantages and limits in React, Angular, and Svelte.

So I wanted to create something taking the best of all: a performant framework, built with optimizations in mind, constrained component structure, and based on reactive programing.

Maybe it's a genius idea, maybe it's not, but in any case, if it may inspire people, I'll be happy with that.

Introduction: what we really want ?

First let's define what makes a great framework, and what we want as developers and companies.

Developers wants reactivity

In front-end, our interfaces react to changes: an event appends (like a click, a promise resoling, a websocket packet, a timer, etc...), and we have to update our interface (meaning update the DOM) reflecting the new data. So everything in front-end is fundamentally reactive.

If we compare some frameworks:

Angular inclues rxjs but was not built with reactivity in mind. However, we may see a clear requirement from the developers: it has an async pipe, recently signal were introduced, and Stores are common. Sadly, the framework itself is not optimized at all for reactivity. It was not built for it, and checking the source code highlight these limitations.

React has useState and useEffect (with others) which are essentially reactive variables and context. Now, we may consider it as a reactive framework, however it was not initially though for it, and we must use tricks like memoization using useCallback or React.memo for example.

Finally, Svelte is natively based on reactivity, which provides excellent performances.

Developers wants well-structured projects

One of the best argument in favor of Angular is how it enforces a specific structure for the projects. When dealing with very large applications, it becomes very important to have a structured architecture having well organized files, directories and components. Something that the recommandations, best practices and cli offers: an opinionated way to structure the apps, that works very well.

This is in my opinion where React and Svelte struggle: they don't offer an unique way of structuring the projects nor coding the components.

It's up to us to:

create our own structure.
split, the css, html and js.
select what kind of css-or-js we want.
choose the front-end tooling we want (nextjs, gatsby, etc...).

This flexibility is fantastic for small projects, but becomes a nightmare in very large applications: for X developers, it results in X ways of coding the components, X ways to organize them, X different ways to import css, etc. Something that becomes quickly impractical, and very hard to maintain. If you're working in big tech companies, you know the struggle.

With big projects, we'll need to have very strict guidelines and documentation to organize projects, or it will become cumbersome and a horror to works on.

Companies wants stability

A company frequently works with code that will probably last forever. We all have an example of a legacy code that nobody want to touch but is critical for the business (ex: a login page), or very large projects that are build in years. So having something that can resist time is important. This means: no-breaking changes, evolution that keeps retro-compatibility and avoid changing everything in the framework.

This is something that is hard to stick to over time: new ideas often tend to radically change how we use a framework.

React changed to hooks: it was a revolution, but the "old way" kept working which is great for long term projects. Angular reworked entirely its engine, and it was mostly transparent for the developers. In my opinion, this is currently the most stable of all the frameworks, making it a very good choice for large companies.

So stability is a critical point for any giant business.

Sadly, this is something I cannot provide yet, but somewhere in the future, with a bigger community, why not ?

Presentation of my framework

I've named my framework LiRX which is an abbreviation for Light Reactive X. It is build on the following premises, based on the based on the previous observations:

reactivity as first-class citizen: the components are compiled to pure javascript to increase drastically the performances, and the DOM is rendered from Observable changes with very fined grained and optimized pipelines. Only what changes is rendered and the minimal javascript execution is done each time.
the framework follows an MVC structure: each component has an .html, .scss and .ts file. Separating these concerns is very important in large applications, in order to keep a coherent structure.
performance always in mind: everything is optimized in such a way that any change in the application triggers the minimal javascript execution time and path as possible. Moreover, it was build to use the full potential of minifiers (efficient tree-shaking, unroll when possible, pre-compile if possible).

It comes in different modules:

@lirx/core: this is the library used to build Observables, Signals, and pipe them.
@lirx/dom: this is the library used to build web applications using Observables.

More packages are available like a router and material components, but are not complete now. It will be for another tutorial in the future.

Reactive programming

First, for people not familiar with Reactive Programming, I'll resume quickly:

Reactive Programming is about data streams and dynamic values (values changing over time).

Reactive Programming frameworks (like @lirx/core or RxJS) gives you tools to create such streams or dynamic values (ak: Observables/Signals), and combine them in complex pipelines. As opposed to imperative programming, values keep track of their changes, and automatically update any dependent.

Here's a quick example:

const b = signal(1);
const c = signal(2);
const a = computed(() => a() + b());
b.set(10);
console.log(a()); // 12

If any of b or c change, then a will change too.

What's great is that you can listen to these changes:

effect(() => {
  console.log(a());
});
// asuming `b = 1` and `c = 2`, then `3` is displayed
b.set(10); // by setting `b = 10`, `a` is updated, and `12` is displayed

Thus, me may build a framework around such a concept, and only update the absolutely necessary DOM nodes when a change occurs in the app. All of this without the necessity to run a differ algorithm or generating a new Virtual DOM.

@lirx/dom

Alright, to keep everything as short as possible (not an easy task for a framework), I'll give you a sneak peek and partial examples demonstrating the potential of @lirx/dom.

The framework is based around components: a component is an HTMLElement with its own template (html), style (css or scss), and javascript (actually typescript). When repeating (creating many components), they'll form a complete application. They are like the bricks forming a house.

Templates

Templates are really similar to Angular. They are based on HTML with a special syntax:

<!-- app-main.component.html -->
<button
  (click)="$.onClickButton"
  [disabled]="$.disabled"
  [class.loading]="$.loading"
></button>

<div *if="$.disabled">
  {{ $.disabledMessage }}
</div>

<app-child-component
  $[message]="$.message"
>
  <rx-slot name="title">
    {{ $.title }}
  </rx-slot>
  <rx-slot name="date">
    {{ $.date }}
  </rx-slot>
</app-child-component>

It's possible to:

bind: properties, attributes, classes, styles, events, etc.
mutate the DOM nodes with prebuild helpers like: *if, *for, {{ text }}, etc.
provide templates to child components (ak: slots)

In a few words: it simply does what we expect from any front-end framework.

Styling

Styling is done using the same css as the one used for web components. It uses :host and :host-context:

// app-main.component.scss
:host {
  display: block;

  & > button {
    border: 1px solid #666; 
  }
  // ...
}

However, the style is not purely scoped to the component itself, allowing us to style child components from a parent if necessary. If we prefer to limit the scope of our css, we may use @scope.

Component

The core of the Component is located inside its .ts file:

// app-main.component.ts
// @ts-ignore
import html from './app-main.component.html?raw';
// @ts-ignore
import style from './app-main.component.scss?inline';

/**
 * COMPONENT: 'app-main'
 */

interface ITemplateData {
  readonly onClickButton: (event: Event) => void;
  readonly disabled: ISignal<boolean>;
  readonly loading: ISignal<boolean>;
  readonly date: IObservabe<string>;
  // ...
}

export const AppMainComponent = new Component({
  name: 'app-main',
  template: compileReactiveHTMLAsComponentTemplate({ html }),
  styles: [compileStyleAsComponentStyle(style)],
  templateData: (): ITemplateData => {
    const disabled = signal<boolean>(false);
    const loading = signal<boolean>(false);

    const onClickButton = (event: Event): void => {
      loading.set(true);
    };

    const date = map$$(interval(1000), () => new Date().toLocaleDateString());
    // ...

    return {
      disabled,
      loading,
      onClickButton,
      date,
      // ...
    };
  },
});

As you may notice all the data given to the template are reactive (Signal, Observable or Observer):

interface ITemplateData {
  readonly onClickButton: (event: Event) => void;
  readonly disabled: ISignal<boolean>;
  readonly loading: ISignal<boolean>;
  readonly date: IObservabe<string>;
  // ...
}

The framework subscribes to them to update only the relevant nodes of the DOM: if disabled changes for example, then @lirx/dom just sets the attribute disabled on the button and does nothing more, so calling disabled.set(true), is as fast and direct as calling button.disabled = true. Moreover, the engine takes care to properly unsubscribe of these "reactive values" when the DOM nodes leave the DOM, thus, avoiding memory leaks and side effects.

For more examples, I have created a dedicated repository, and it is as simple as:

git clone https://github.com/lirx-js/dom-examples
cd dom-examples
yarn # or npm i
yarn dev # or npm run dev

This was just a quick peek, the tip of the iceberg.
If you're already interested you may start from here. Else, let's jump to a comparison with the other frameworks.

How it differs from the others frameworks ?

First of all @lirx/dom was build for reactivity: it's deeply integrated in its core and in the manner we build the components. Thus, it's fast and efficient, where other frameworks added reactivity later, accepting compromises on performances.

If we do a quick and dirty comparison between Angular (left) and @lirx/dom (right), on an autogenerated app having 3900 components (73K lines):

We may see how @lirx/dom only updates what's relevant and nothing more, out-of-the-box, where such optimizations are only possible with other frameworks, if we follow specific (and sometimes painful) constraints. You may find a full dedicated benchmark comparison here. The goal is not to demean Angular, but to offer the best performances, by comparing and optimizing continuously as much as possible. Thus delivering the best possible user experience.

What's next ?

The next step is to get feedback from developers to improve the framework.

Are you interested in such project ? Does a Reactive Programming framework feel appealing and simple enough for everyone ? Have you any idea of improvement, or suggestion ?

If you want to help, test the framework, comment, etc., your opinion matters ! I consider that evey feedback may only be benefit and improve what I think is already a great concept.

Thanks for reading me. I hoped, I've created some interest in the community.

Get ready ! Signals for everyone.

valentin — Mon, 04 Mar 2024 07:04:29 +0000

Heard about Angular's signals, and want to play with them in any projet ?

Well, you're at the right place !

Introduction

If you've followed the recent javascript trends, you've probably heard about Signals.

Else, don't worry I'll recap quickly:

A Signal is a wrapper around a value that can notify interested consumers when that value changes. Signals can contain any value, from simple primitives to complex data structures.

Adopting Signals, will usually greatly simplify the design of your applications: if you have variables depending on other variables (computed), variables that mutates other time (updated) or large state management (ak: Store).

In addition, using Signals to hold dynamic values is easier that managing them yourself: updating manually your computed variables requires more code and quickly becomes error-prone, where Signals handle it automatically, with a short and elegant syntax.

Other front-end frameworks provide something similar:

Angular recently introduced Signals.
React uses useState which is similar.
Vue or Svelte have their own internal implementation of such Signals.

So it's something truly essential in the front-end framework ecosystem.

Thus, I've created my own implementation of Signals specially optimized for Reactive Programming and working in any javascript runtime: @lirx/core. This library follows the Angular Signals' API for compatibility, with little differences, but uses a totally different implementation. Is not tied to any specific framework, and can be used in any project.

This project aims to give to everyone the opportunity to use Signals and learn Reactive Programming,
by giving to developers universal tools to build complex applications.

It's not restricted to Angular, but it has a close API, in consequence the following part comes directly
from the Angular Signals' tutorial page. If you're already familiar with Signals, you may jump to the differences.

Signal

A Signal is created using the signal function:

import { signal } from '@lirx/core';

const count = signal(0);

// signals are getter functions - calling them reads their value.
console.log('The count is: ' + count());

To change the value of a writable signal, you can either .set() it directly:

count.set(3);

or use the .update() operation to compute a new value from the previous one:

// increment the count by 1.
count.update(value => value + 1);

Computed

A computed signal derives its value from other signals. Define one using computed and specifying a derivation function:

import { signal, computed } from '@lirx/core';

const count = signal(0);
const doubleCount = computed(() => count() * 2);

This library provides the sames functionalities and optimizations as the Angular's one: computed signals are both lazily evaluated and memoized.

As a result, it's safe to perform computationally expensive derivations in computed signals, such as filtering arrays.

Effects

Signals are useful because they can notify interested consumers when they change. An effect is an operation that runs whenever one or more signal values change. You can create an effect with the effect function:

effect(() => {
  console.log(`The current count is: ${count()}`);
});

Effects always run at least once. When an effect runs, it tracks any signal value reads. Whenever any of these signal values change, the effect runs again. Similar to computed signals, effects keep track of their dependencies dynamically, and only track signals which were read in the most recent execution.

Differences between this library and the Angular's Signals

Close but not identical

The Angular Signals' API reflects the constraints of the framework. In another hand, @lirx/core is not limited to any framework, so any part related to Angular is removed, meaning that the API is not totally identical, but extremely close. In 99% cases, you won't have to change anything, and it will work right out of the box.

Faster in some cases

The library is focused on performances, and we have done benchmarks to compare both frameworks. We believe that effects are the most important part of Signals, and, in this specific aspect, @lirx/core outperforms Angular by a factor of 8. Combined with a framework like @lirx/dom (alpha), this promises amazing applications.

@lirx/core includes Observables

@lirx/core includes all the tools for Reactive Programming in a single package.
It's designed to create complex and consistent Reactive Applications (mostly front-end), like a breeze.

Conclusion

If you've searched for the perfect Reactive Programming library, don't look further: @lirx/core is probably the right candidate. You won't have anymore to update manually your computed/derived variables, you'll be able to reflect their changes immediately, and you will be able to create complex and optimized data pipelines in just a few lines of code.

All of this working independently of any framework !

It's perfect for front-end application where updating the DOM must be done in a simple and elegant manner, while keeping the application consistent.

Coding in Reactive Programming opens you a whole new world of possibilities. I hope I have piqued your interest with this presentation.

About @lirx/core

@lirx/core is a Reactive Programming framework with a lot of prebuild functions, clear documentations and many examples to teach you how to become a master of RP. It allows you to develop complex applications and pipelines that scale easily. Moreover, it is the fastest and smallest javascript library for Reactive Programming. So it's a good candidate to start your journey with Observables and Signals.

Feel free to test this library, share it and give your feedbacks.

Reactive Programming: a gentle introduction

valentin — Mon, 20 Feb 2023 09:54:15 +0000

In this post I want to introduce you to Reactive Programming, it's benefits, and why should you care.

Even developers already using Reactive Programming Frameworks (ex: Angular) struggle with this concept.
It is something mysterious, and complex, often limiting its usage. However, coding in RP gives very powerful powers, that are clearly underestimated. So today, I will try to clear up this mystery.

Reactive programming

Let's begin with a simple definition:

Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

In Reactive Programming, we will focus on the data flow, and if something changes, then the flow updates itself.

I'll illustrate this with a switch and a light bulb:

Credit: Dan Lew¹

In imperative programming (this is probably your main way of coding), the switch modifies the state of the bulb. In this case, the switch is proactive, pushing new states to the bulb; whereas the bulb is passive, simply receiving commands to change its state.

However, in reactive programming it's the opposite: the bulb listen to the state of the switch, and then modify itself accordingly. In this model, the bulb is reactive, changing its state based on the switch's state; whereas the switch is observable, in that others can observe its state changes.

Credit: Dan Lew¹

This approach makes more sense when working with streams and flows, because you won't have to update the source (the switch) to add more sinks (more light bulbs). Each light bulb is self-managed, and doesn't rely on a modification of the code of the switch to update itself.

Maybe you've seen it, but you're already familiar with this concept: everytime you use the method addEventListener, you're subscribing to Events and update other variables, elements, etc... So, you're actually doing reactive programming. Here, we'll push this concept further, to create amazing possibilities of interactions between data, objects, sources, etc...

Imperative programming

Now, we will compare imperative vs reactive programming ².

Let's explain it with a simple assignment: a = b + c. a is being assigned the result of b + c. This is done in the instant in imperative programming: the expression is evaluated, and later, the values of b and c can be changed with no effect on the value of a. This is how we code most of the time.

On the other hand, in reactive programming, the value of a is automatically updated whenever the values of b or c change, without the program having to explicitly re-execute the statement a = b + c to determine the presently assigned value of a.

Imperative programming

let b = 1;
let c = 2;
let a = b + c;
b = 10;
console.log(a) // 3 (not 12 because "=" is not a reactive assignment operator)

Reactive programming

Now imagine you have a special operator $= that changes the value of a variable (executes code on the right side of the operator and assigns result to left side variable) not only when explicitly initialized, but also when referenced variables (on the right side of the operator) are changed.

let b = 1;
let c = 2;
let a $= b + c; // 3
b = 10;
console.log(a); // 12

Such an operator would be extremely useful: a would be always up-to-date. We may start to imagine new langues and frameworks using this paradigm, and having quite powerful features.

This is especially true for MVC architectures, where reactive programming can facilitate changes in an underlying model that are reflected automatically in an associated view (typically an UI framework like Angular of React for a web application).

@lirx/core as a framework

The most popular reactive framework is ReactiveX, and it's javascript implementation RxJS. However, this library has the following issues:

it lacks of clear documentation (you need a master in reactive programming, to understand even the simplest functions), and some parts of the documentation are outdated, or simply don't exist.
it is based on states ('next', 'error' and 'complete') instead of pure data flow, which restrains many operators, and confuse users when building complex interactions.
its design limits its performance as well as the resulting bundle size.

Instead, I'll use @lirx/core, and show you how simple is it to implement the previous example:

const [$b, b$] = let$$(1);
const [$c, c$] = let$$(2);
const a$ = add$$(b$, c$); 

a$(a => console.log(a)); // 3

$b(10); // a$ => 12

I will break down the code, to explain each part in detail:

const [$b, b$] = let$$(1);

The let$$ function allows us to create a mutable reactive variable. We usually split the result in two constants:

$b, an Observer, to set the value
b$, an Observable, to read it

Moreover, as you probably guess, we've initialed b with the value 1.

We repeat the process for c, and have now two reactive variables.

Then we have to perform the sum:

const a$ = add$$(b$, c$);

Here we declare a$ as the addition of b$ and c$, using the function add$$. All of these variables are Observables. In consequence, if any of b$ or c$ changes, then a$ changes too.

Since a$ is an Observable, we have to subscribe to it in order to read its value (because this one changes over time):

a$(a => console.log(a));

b and c already have a value, as a result, we'll immediately see 3 logged.

Finally, if we update b writing:

$b(10);

a$ will instantly change to 12, and this value will be logged.

Conclusion

This is just the tip of the iceberg. As you probably guess, adopting a reactive programming approach gives you very powerful tools to design clear and organized data flows.

A stream can be used as an input to another one. Even multiple streams can be used as inputs to another stream. You can merge two streams. You can filter a stream to get another one that has only those events you are interested in. You can map data values from one stream to another new one. Etc.

This way you'll be able to create well-defined and robust streams of events and data, and you'll have the tools to create flow that match perfectly and instinctively the requirements of stable and large applications perfectly fitting your needs.

I highly recommend you to stop thinking purely in imperative programming and start practicing reactive programming to discover an amazing world of new possibilities.

I guarantee you won't regret it 🦸

About @lirx/core

@lirx/core is a Reactive Programming framework with a lot of prebuild functions,
clear documentations and many examples to teach you how to become a master of RP.
It allows you to develop complex applications and pipelines that scale easily.
Moreover, it is the fastest and smallest
javascript library for Reactive Programming.
So it's a good candidate to start your journey with Observables.

Feel free to test this library, share it and give your feedbacks.

Why Reactive Programming is so awesome ?

valentin — Tue, 20 Dec 2022 06:56:59 +0000

In this post I want to share my personal experience with Reactive Programming and why you should consider using it.

This article was originally published on https://core.lirx.org/blog/reactive-programming/. Take a look to get a better reader experience.

The problematic

Let's imagine this simple use case:

Two <input> in which the user may enter two numbers to perform an addition.
The result is displayed right below everytime the user type a new value.

We may: implement it from scratch

Listening to changes in the two <input>, compute the addition, and update the result. This solution is performant. However, increasing the number of inputs tends to exponentially scale the complexity of the code.
Its usually ends up in bugs and nightmares to maintain.

Or we may: use a front-end framework

Like React with useState or Angular with its ChangeDetector. We'll win in code readability, at the cost of performance lost (when running the change detection algorithm). Moreover, the app will have a bigger size.

More generally, this problematic is applicable to every evolving values, which are nothing more than streams of data.

Some examples:

the current date and time updated every seconds
a translated text, that changes with the user locale (and maybe some <select>)
the state of a submit button (enabled/disabled), if a form is valid/invalid
a data stream coming from the backend (ex: live stats)
and many more...

Handling the refresh, the combination, the transformation, etc. of such streams, is generally complex. It creates code with low readability, frequent uncovered cases, and inconsistent states.

What if we could have all benefits: performance, code readability, and consistent states ?

The answer

Reactive Programming is the perfect answer to manage streams of data, async flows, and evolving values.

With RP, we build streams of values called Observables. And, we will have an amazing toolbox of functions to combine, create and filter any of those streams. That's where the "functional" magic kicks in. A stream can be used as an input to another one. Even multiple streams can be used as inputs to another stream. We can merge two streams. We can filter a stream to get another one that has only those events we are interested in. We can map data values from one stream to another new one. Etc.

Actually, you're probably already familiar with async data streams: Promises, EventListeners, setInterval, etc.
Reactive programming is all about this but on steroids.

You'll be able to create Observables of anything, not just from click and hover events: variables, user inputs, properties, tasks, data structures,...

Reactive Programming by example

You've probably heard of RxJS which is the most commonly used RP library in javascript. However, I will promote here @lirx/core, a library strongly outperforming RxJS in performances, having a better documentation and trying to be simpler.

Ok, let's start:

const onInput$ = fromEventTarget(input, 'input');

It creates an Observable for an <input>, listening and emitting Events of type input. It triggers, when the user types something in this input.

An Observable is simply a source emitting values.

An Observable is not started until we subscribe to it:

const unsubscribe = onInput$((event) => {
  console.log(event);
});

The provided function is called an Observer, and it receives the values from our Observable.

An Observer is a sink receiving values from an Observable

When the user types in the <input>, its value is simply logged in the console.

Subscribing to an Observable returns an unsubscribe function. When called, it notifies the Observable to stop sending more values, and usually free the Observable's resources.

document.onkeydown = (event) => {
  if (event.key === 'Escape') {
    unsubscribe();
  }
};

Here, when pressing the Escape key, we terminate our Observable, and stop listening to the input's Events.

At this point, you may notice than subscribing/unsubscribing from streams of data is extremely simple with Observables. We don't have to keep a reference to the callback function of .addEventListener for example. It's handled by the Observable itself.

So, we have now an Observable sending input's Events, but what if we want the input's value ? It would be more convenient:

const inputValue$ = map$$(onInput$, () => input.value);

The map$$ function transforms the incoming Events into the input's value. Such a function is called an ObservablePipe.

An ObservablePipe is a function which transform an Observable to another one

So now, when the user types in the <input>, inputValue$ emits this input's value instead of an Event.

And this is where Observables shine: we can combine them, transform their values, create complex data flows, etc. Keeping the complex transformations to @lirx/core and focusing only on the interdependence of our data.

Let's assemble everything to create a custom function building an Observable from an input's value:

function fromInput(input: HTMLInputElement): IObservable<string> {
  return merge([
    reference(() => input.value),
    map$$(fromEventTarget(input, 'input'), () => input.value),
  ]);
}

Here I have extended a little our first Observable with:

reference(() => input.value): this creates an Observable which emits the input's value when subscribed.
merge: subscribes to the list of Observables and re-emits all their values.

Here, we will combine merge and reference because the input event is not immediately triggered when we subscribe to our Observable, so we need another way to retrieve the initial input's value.

In short, subscribing to this Observable sends the initial input's value and next values typed by the user.

And if we want to consume our Observable, we simply write:

const inputValue$ = fromInput(input);

inputValue$((value) => {
  console.log(value);
});

Alright, let's finish by solving the initial example:

Two <input> in which the user may enter two numbers to perform an addition.
The result is displayed right below everytime the user type a new value.

First we have to convert the input's values to numbers:

function fromNumberInput(input: HTMLInputElement): IObservable<number> {
  return pipe$$(fromInput(input), [
    map$$$(Number),
    filter$$$(_ => !Number.isNaN(_)),
  ]);
}

The pipe$$ function applies many ObservablePipes to an Observable.

We start by applying the map$$$ ObservablePipe to convert the input's values to numbers.

Then, through the ObservablePipe filter$$$, we filter these numbers to keep only the valid ones. We have to do it to handle the cases where the user types nothing or strings which are not numbers.

Finally, to perform an addition from two Observables, we may use add$$:

const result$ = add$$(
  fromNumberInput(inputA),
  fromNumberInput(inputB),
);

And Voilà ! We have created an Observable performing the addition of two <input>.

Let's recap:

function fromInput(input: HTMLInputElement): IObservable<string> {
  return merge([
    reference(() => input.value),
    map$$(fromEventTarget(input, 'input'), () => input.value),
  ]);
}

function fromNumberInput(input: HTMLInputElement): IObservable<number> {
  return pipe$$(fromInput(input), [
    map$$$(Number),
    filter$$$(_ => !Number.isNaN(_)),
  ]);
}

const result$ = add$$(
  fromNumberInput(inputA),
  fromNumberInput(inputB),
);

result$((result) => {
  console.log(result);
});

You can find a demo here

Thinking in Reactive Programming gives us the opportunity to focus on our data flow, and not the complex implementation. Doing the same thing from scratch, requires more code and easily conducts to bugs and poor maintainability.

This example is just the tip of the iceberg: we can apply the same operations on different kinds of streams, for instance, on a stream of API responses, a stream of bytes to compress, a string to translate dynamically, etc.

Why you should consider adopting RP ?

Reactive Programming raises the level of abstraction of our code, so we can focus on the interdependence of events that define the business logic, rather than having to constantly fiddle with a large amount of implementation details. Code in RP will likely be more concise.

Dynamic values are managed in a different way: instead of using some kind of refresh function (to update for example many DOM nodes, if something changes), the variables (here some Observables) are always fresh and updated. So, we won't have to remember to call a refresh() when a change occurs, meaning less bugs and less code in our application.

The benefits are really important in web applications, where we have to deal with a multitude of UI events, async requests, etc... and react to these changes, like updating the DOM.

Moreover, it handles for us any cancellation: from aborting a fetch, to cancelling an eventListener or a setInterval. This point, is frequently ignored by developers creating memory-leaks, or very difficult bugs to fix (like an async tasks that should have been cancelled, but continues to run until it break something - most of the time updating something unwanted).

Cancelling, any pending tasks (ex: from a destroyed html component) is extremely simple with RP.

The drawbacks and advantages of RP

Reactive Programming feels like it is essentially for purists and advanced programmers: it's difficult for beginners and involves complex and abstract logic (everything is a stream, and we must think async).

But in my opinion, the Observables are just like Promises in their time. Do you remember the first time you learned how Promises worked ? This was a new way of thinking our code, and I've seen many new developers struggling to understand how to use them. However, now, I'm pretty sure, you're using Promise frequently without difficulties.
They became essential for everyone, because they help so much with async coding. They radically changed our way of developing and thinking our applications.

Well Observables, are just like Promises: at first glance, they seem difficult to handle, but they radically solve every problem related to async algorithms or data streams. They are a very good solution for front-end applications, simplifying fetch calls, dynamic variables in templates, user events, and much more...

And the best part of it: it doesn't impact negatively the performances. On the contrary, when tuned properly, you'll see an uge improvement in your application.

Conclusion

Now, you are ready to begin with Reactive Programming, and discover an amazing world of streams, pipes, and dynamic values.

I hope you enjoyed the beauty of this approach, and maybe I converted you to this awesome way of coding. Even if you're not convinced yet, you should do a quick try, as mastering RP will open you a new world of possibilities.

Create a demo, share it with others, and help to build the web of tomorrow.

About @lirx/core

@lirx/core is a Reactive Programming framework with a lot of prebuild functions, clear documentations and many examples to teach you how to become a master of RP. It allows you to develop complex applications and pipelines that scale easily. Moreover, it is the fastest and smallest
javascript library for Reactive Programming. So it's a good candidate to start your journey with Observables.

Feel free to test this library, share it and give your feedbacks.