Did you get functional-reactive wrong?
Tags: javascript, webdev, functionalreactiveprogramming, beginners
Published: 2024-05-07 18:43:18

You think you learnt functional-reactive JavaScript on some online tutorial?

You might actually have learnt imperative-reactive stuff claiming to be functional, or functional-reactive, when in fact it's not.

This article will teach you how to tell the difference.

> Myth: If you're doing React functional components, you're doing functional-reactive programming.
> Reality: This term only refers to the way a component is created, which is by means of a function and not a class. It has nothing to do with either functional or functional-reactive programming. React is an imperative library.


Let's continue with the typical pattern of an imperative-reactive piece of code:

```javascript
// One imperative approach
let value = 1;
value = 2;
```


```javascript
// Another imperative approach
const [value, setValue] = createState(1);
setValue(2);
```

Every time you set a variable as above, you're performing an imperative change. (React hooks, Angular signals, SOLID signals, Svelte scripts anyone?)

The functional approach, though, starts by defining an entity as a function of a source. In other words, assign a function to a target:

```javascript
// The functional approach
const target = someFunctionOf(source);
```

In this case you never directly set the value of `target` in any way.

So what if `source` changes somehow? That's where reactivity steps in.

In JavaScript one if not the best way of making code both functional and reactive is using Observables:

```javascript
// A functional-reactive approach, where state
// is defined as an Observable stream.
const state = new Observable(observer => {
  observer.next(1);
  setTimeout(observer.next(2), 1000);
});

// So this is how you make use of it
state.subscribe(console.log);
```

Here `state` is defined as an Observable, so you will need a sink to display changes somewhere, like the DOM, the console, the network, or something.

These examples are obviously oversimplified, but should show a way to easily tell imperative-reactive code from functional-reactive.

## Functional JavaScript
So, what is functional JavaScript, then?

It's functional, but not necessarily reactive. With the use of functions, some composition, such as map/reduce, but only executed once on a source stream. If the source updates, the result does not.

```javascript
  const source = [1, 2, 3, 4, 5];
  const result = source
    map(x => x*2)
    reduce((a, b) => a+b, 0)
  ;
```

The above is a simple example of functional, non-reactive JavaScript code, where `result` is calculated once, but immutable, since it's a constant value.

Essentially, all this is, is the use of some principles from the functional programming paradigm. JavaScript is multi-paradigm, so it allows you to combine concepts and structures from object-oriented, procedural, functional paradigms and use them at your discretion.

Functional JavaScript in particular is what you can do with map/reduce, (meh, callbacks) promises, observables. The last of these is what really brings you reactivity.

Additionally, there are certain principles, like function purity, that are not reflected in any language construct, but are more like a design pattern that you may choose to follow in order to make code more testable, robust, and free from bugs.

## Conclusion
The easiest way to compare an imperative vs a functional approach is `target=value` (which is the same as doing `setTarget(value)`), vs `target=fn(source)`.