From Plain Functions to Reactive Streams: a mindset change with a thousand benefits

Functions have been at the core of computer programming since the dawn of time. From the simplest arguments in -> results out pure functions to async functions that return future values, to reentrant generators that can dynamically produce any number of results over time, sync or async.

There is one thing functions share in common: they lack any sort of event awareness.

Bad news in a world where literally everything revolves around events and a whole chain of reactions to be executed in response: a button click, a file upload, a form submission, a page refresh or a ticking timer.

Streams can handle a multitude of events in input, perform some processing and emit some results. They can take the output of other streams as their own input and compose up new derived streams.

A great analogy can be drawn with water pipelines or electrical circuits. Reactive streams treat data just like pipeline channel water and circuits enable the controlled flow of electricity.

From simple function to simple stream

Let's take a function that returns its argument doubled:

// imperative
function double(n: number) {
  return n * 2;
}

An equivalent reactive stream that takes numbers and emits double the input value looks something like this:

// stream-oriented
const double = new Subject<number>().pipe(
  map(n => n * 2)
);

You may have noticed how streams take a single parameter, which seems a bit of a limitation given that functions can take many. This can be mitigated by passing objects instead of plain values and in practice, given that a stream should represent a single "thing", this won't even feel like a limitation.

The difference is small, subtle, but fundamental. In the former case it's an imperative call that triggers the function and handles the result, in the latter case, the stream is something that can be fed and subscribed to, ideally by the framework.

From async functions to streams

The difference between sync or async streams is not as critical as it is between functions and async functions. At the end of the day, you combine streams the same way with the same operators (such as zip, combineLatest, withLatestFrom, etc) in a seamless way.

Perhaps one little exception is when you use promises inside streams. Say you have one that calls an API and propagates its results. You can't just use the map operator, as it would not wait for any fetch() call to resolve. What you want to use instead is the switchMap operator, which also cancels any in-flight operation before starting the new one.

// imperative
function getData(id: number) {
  return fetch(`/data/${id}`).then(r => r.json());
}

// stream-oriented
const dataStream = new Subject<number>().pipe(
  switchMap(id => fetch(`/data/${id}`).then(r => r.json()))
);

Actually this is an overly simplified example, because there's so much more to using fetch and handling errors, but we only wanted to focus on the structure now and how to get from an async function to a stream. There is a collection of examples showing how to fetch data and handle retries and errors. Perhaps we'll write about those in more detail some day.

So, what's the key difference, in summary? In one case, in the imperative paradigm, you "call" the getData() function and await the result. In the stream-oriented paradigm, you don't call anything. You only create pure streams and declare how you'd like those to be called. An example could be like the click on a button triggers the stream and its output goes into a <div> somewhere on the page. HTML templates serve this exact purpose.

Benefits of thinking in streams

Embracing streams over traditional functions brings several practical and architectural benefits:

1. Event awareness and composability. Streams integrate seamlessly with events, which are the backbone of interactive systems. They let you model complex workflows as a network of dataflows rather than a series of callbacks.

2. True asynchronicity. Streams naturally handle asynchronous data over time without forcing developers into nested then chains or async/await boilerplate.

3. Declarative clarity. Instead of describing how to react to each event, you define what should happen when it does. This leads to more maintainable, predictable, and testable code.

4. Error resilience and recovery. Operators like catchError, retry, or switchMap give you built-in tools to manage transient errors or cancellation logic gracefully.

5. Framework synergy. Modern UI and data frameworks—especially those aligned with reactive programming—can automatically connect streams to views, enabling state updates without explicit imperative glue code.

6. Better scalability. As systems grow, adding new event sources or transformations doesn't require changing existing logic. Streams let you plug in new flows like components in a circuit.

By shifting from functions to streams, you're no longer writing programs that merely execute from top to bottom; you're designing living systems that react, evolve, and adapt continuously in response to their environment.

---

Learn More

	From Clicks to Dataflows: Stream-Oriented Programming in simple terms
	Signals have no operators. Try these instead
	A Stream-Oriented App — building in public

Comments

[Martin Klingenberg]

Love your work and this is a great article. I enjoy Rxjs but I see how other devs struggle with RxJS. My vision is that devs can realize that business logic can be separated from the frameworks and that frameworks should only be used for rendering.

If you like I would love to have your opinions on my React Rxjs bindings. I have thought about making a package for it and making some articles.

[Dario Mannu]

I’ve seen that too, some developers struggle with RxJS, but in my experience the real reason is that most frameworks just aren’t designed to work with streams.

You mentioned React bindings, is that something like react-rxjs, or are you approaching it differently?

[Martin Klingenberg]

React rxjs was not really something I saw working for me. react-rxjs is quite awesome. However I thought it might be a bit too complicated in some ways and a bit too little complicated in others. I have created a function that turns streams into something more like the outputs from React Query.

My thoughts about frontend architecture is to write the business logic in plain javascript / typescript. And then have some code that can turn my reactive streams into hooks. Basically creating a small bridge between react and RxJS. That way the only dependency used by my logic, is RxJS.

And yes. I believe my approach is a bit different. I also see that React in particular does not really like streams. So my solution is to not use streams directly in React. React likes values. Lets give react values even though my system uses streams.

[Dario Mannu]

I think you summarised react-rxjs very well, and I completely agree about keeping all logic in pure JS.

So, how do you convert streams to values? Hooks, you say, but isn’t that what react-rxjs does already? Do you convert them back too? I’m curious what new tricks you’ve come up with.

That said, it raises a broader question: do you think it’s the right thing to do?
React, as you said, doesn’t really like streams — and probably never will — so why invest so much energy in bridging something that resists integration by design?

From your comments, it’s clear you have a good understanding of streams. Perhaps your work could be better appreciated and valued in a novel ecosystem like Rimmel.js that's designed with streams in mind from the ground up?

[Martin Klingenberg]

Well React is kind of hostile to any library that is not written to be integrated with the React runtime.

However, the truth is that where I work, I am the only frontend developer. We have a quite large application and I have to keep the codebase and rather than rewriting it in something else, I want to make the codebase a nicer place to work. One of the large technical debts is the business logic being tightly integrated with the components. I clean it up piece by piece. I have a vision of the future architecture. And it separates the business logic and have a light binding to make it possible to keep a lot of the codebase. Maybe at one point in the future, I can write some of the UI in something else.

I want to be able to develop high quality code quickly. This is the way I do it

It is quite nicely done. I have an example below. Basically making a hook that handles values and errors. Errors are standardized in the codebase. That way it is easy to use a predefined Empty state-component. It renders errors in a neat and user friendly way.

// Lets define a hook
export const useAdminAssetsAndCompanies = createResilientStreamHook(
    AdminServiceContext,
    (service) => service.assetsAndCompanies$, // Reference an observable in a service
    () => [], // A callback to set a default value
    (value) => value.length === 0, // An isEmpty function
    (service) => service.assetsAndCompaniesLoading$, // Link to an observable that tells us if the data is loading
);

// Lets use the hook
const SomeAwesomeComponent: FC = () => {
  const { isEmpty, isLoading, value, error } = useAdminAssetsAndCompanies();
}

When it comes to contributing to the Rimmel.js-codebase that would be awesome. I will contact you when my backlog of tasks is cleared enough for me to contribute to the project.

[Dario Mannu]

| I have to keep the codebase and rather than rewriting it in something else

I feel your pain 😉
Out of curiosity, if you had the chance to embed non-React components into a React subtree as part of a potential step-by-step migration and in exchange you got the ability to use streams without any adapters plus you could more easily isolate your business logic into separate services as you describe, would you go for it, or you'd stick with React-only for consistency?

| useAdminAssetsAndCompanies

Interesting, but not 100% sure I got every aspect of this... mind dropping a tiny working example on stackblitz or something, if you're happy to share a bit more?

How about we take it to Discord?

[Martin Klingenberg]

Could you send an updated invite. The one above is expired

[Dario Mannu]

Maybe this one will work?