Why Observables suck and what can you...
Tags: javascript, angular, rxjs, showdev
Published: 2024-06-25 09:20:00

If you landed here, I bet it's because of one of the following:

- You're watching what's happening with Signals and still wondering if you like them
- You've used Observables but you found using them confusing, problematic and boilerplated
- You feel something's not right using them for some weird reason (we'll get to that)

So, what is using Observables like, for instance, in React?
Let's start with the simple, boring, click-counter component:

```typescript
import React, { useEffect, useRef, useState } from 'react';
import { fromEvent, Subscription } from 'rxjs';
import { map, scan } from 'rxjs/operators';

const ClickCounter: React.FC = () => {
  const [count, setCount] = useState(0);
  const buttonRef = useRef(null);

  useEffect(() => {
    const button = buttonRef.current;
    if (!button) return;

    const clickStream = fromEvent(button, 'click').pipe(
      map(() => 1),
      scan((acc, value) => acc + value, 0)
    );

    const subscription = clickStream.subscribe(setCount);

    return () => {
      subscription.unsubscribe();
    };
  }, []);

  return (
    <div>
      <button ref={buttonRef}>Click me</button>
      <p>Clicked {count} times</p>
    </div>
  );
};

export default ClickCounter;
```

- If you feel it's too much code just for a click counter, you're not alone.
- If you're not happy with having to call `.subscribe()`, `unsubscribe()`, you may have your good reasons.
- If you're sick of having to type `fromEvent(button, 'click')` for each of your event handlers, it's not just you.
- If you feel it's total nonsense to have an Observable (which can do reactivity on its own) bridged through other idiosyncratic constructs like `useEffect`, you're clearly onto something.
- If you're questioning whether Observables are the problem or React, or [other framework name here], you're really touching the essence of the problem.

### Observable "bridge" libraries
You may be aware of some of those "bridge" libraries for Observables (react-rxjs, react-rx), which are most often third-party creations to remedy a certain framework's inability to handle streams.


Let's examine in another example whether we can see any improvement at all using them:


```javascript
import {useState} from 'react'
import {useObservableEvent} from 'react-rx'
import {filter, map, tap} from 'rxjs/operators'
 
const ShowSliderValue = () => {
  const [value, setValue] = useState(0)
  const handleChange = useObservableEvent((value$) =>
    value$.pipe(
      filter(nonNullable),
      map((value) => Number(value)),
      tap(setValue),
    ),
  )
 
  return (<>
    <input value={value} onChange={(event) => handleChange(event.target.value)}
    />
    <div>Value is: {value}</div>
  </>)
}
```

If you use RxJS because you understand functional-reactive principles, that `tap(setValue)` operation above is certainly the part you will hate the most. Side effects are everywhere that just defeat one of the greatest benefits of FP: clean code.

### What if...
Turns out several people had got enough. Some, like Angular, went to kind of drop Observables, while someone else came up with a new UI library supporting them in a way never done before.


```javascript
import { BehaviorSubject, scan } from 'rxjs'
import { rml } from 'rimmel';

export const ClickCounterComponent = (initial = 0) => {
  const counter = new BehaviorSubject( initial ).pipe(
      scan( x => x+1 )
  );

  return  rml`
    <button onclick="${counter}">click me</button>
    You clicked <span>${counter}</span> times.
  `;
}

document.getElementById('root').innerHTML = ClickCounterComponent()
```

### Intentionally tacit
This may be the first time you see an Observable stream referenced in different parts of the same template, as it's the new thing.

In Rimmel, the way an Observable is bound depends on where you put it in a template.
If it's in an event handler, like `onclick="${stream}"`, it becomes an event source and every click will feed your stream.
If you put it anywhere else, like `<div>${stream}</div>` it becomes a sink, and its output will feed the `div`.
Many other bindings exist, so you can set class names with observables, `<div class="class1 class2 ${stream}">`, data elements or other attributes.


Your code can become drastically shorter and Observables will now start to be a real pleasure to work with.


## Conclusion: do Observables suck?
Actually, I think Observables are one of the greatest inventions in JavaScript since the `if` statement.

The problem is not actually with Observables but with the lack of adequate frameworks supporting them... until now.

[Rimmel.js](https://github.com/reactivehtml/rimmel) is a UI library (dedicated to Observables that we can use today to make components, pages and webapps of any size and scale.

Most "state managers", Signals and `useThings`, become quickly redundant when you have a powerful UI library that makes the best use of Observables and the FP paradigm, so you no longer have to compromise on code quality, testability, developer experience and least but not last, performance.