Motivation

The main motivation of creating observable-hooks is that we want a simple, flexible, testable and performant solution to reuse complex async logic (e.g. intricate animation and user interaction sequence) with the Component.

Why RxJS in Hooks

Nowadays developing stateful React Components is greatly simplified with hooks. We can boldly put complex logic in hooks and reuse it with the Component.

But hooks is just a mechanism to connect stateful logic to React Components. For complex logic itself, async specifically, we still need other libraries to reduce the complexity.

There are libraries that focus only on a few specific aysnc scenarios, like swr (opens new window) for remote data fetching(See how to achieve the same stale-while-revalidate pattern in observable-hooks with Suspense). This is like comparing Redux Saga with Redux Observable. The knowledge you gain from learning how to use these libraries is not as transferable as RxJS(or Reactive Programming, a language-independent programming paradigm) which is an all-round solution for async logic. You can use RxJS for almost any async scenario and still maintain good readability and testability.

Yes there is a learning curve on RxJS but that is mostly a one-time conceptual thing. Don't be scared by the number of RxJS opertators. You most likely only need a few of them. Also see the Operator Decision Tree (opens new window).

Why Another Library

We first tried rxjs-hooks (opens new window) but quickly encountered some tricky TypeScript issues (opens new window). We also think the useEventCallback is taking too much responsibilities (opens new window) which is a performance issue that is hard to fix due to rules of hooks (opens new window).

Unfortunately the project is not actively developed as the team has shifted focus to the redux-observable-like ayanami (opens new window) project.

Ultimately we rethought the whole integration, redesigned API from the ground up and created observable-hooks for connecting RxJS Observable to React Components.

What It Is Not

This library is not for replacing state management tools like Redux but to reduce the need of dumping everything into global state.

Using this library does not mean you have to turn everything observable which is not encouraged. It plays well side by side with other hooks. Use it only on places where it's needed.