DEV Community: Dean Radcliffe

Vibe Coding an Audio Engineer Who Never Sleeps

Dean Radcliffe — Wed, 25 Feb 2026 19:09:12 +0000

I've been coding since I was 11, but playing guitar and writing and singing and recording songs for about a decade now. And somewhere in my musical journey, I realized something:

The red “Record” button changes you.

It tightens your shoulders.
It turns exploration into performance.
It makes you think instead of play.

So you leave it to not recording by default - then when inspiration strikes, and you think "Record that!” — oops it’s gone already. So I built myself an audio engineer agent to always be listening. I did it solely by chatting with OpenClaw via Telegram, on a Raspberry pi 5. He was up and running in under 30 minutes - using code techniques I didn't even know at the beginning! And if you were curious - I named him "Rick" - because he's always rolling...

The Idea: A Ring Buffer As The Engineer

The idea is simply this: An always-on ring buffer.

A rolling 10–15 minutes of audio. Continuously recording. Continuously overwriting itself.

Like an engineer in the room who’s always listening, but never judging.

If something magical happens?

You tell it "Rick send me the last 5 minutes you recorded"
And you get the file in under a minute as a telegram message.

No prep.
No red light.
No performance mode.

Just: Oh yeah - that's what I was going for.

How I Built it (OpenClaw Vibe Coding)

This is where it gets wild.

I didn’t open a whiteboard.
I didn’t spec it.
I didn’t design a formal architecture.

I opened OpenClaw and vibe-coded it by chatting with it and testing it out.

“Give me a low-latency circular audio buffer.”
“Now add a command to flush the last N minutes to disk and send that file via Telegram”

Each prompt fit in a text message. Each step took minutes. No doc-diving through audio libraries for two hours. Just momentum.

By 10 pm I had:

Live mic input
A rolling buffer
A save-last-5-minutes command
Zero disk clutter
Zero pressure

By 11 I was adding clip detection, file renaming, and purging as features. And of course I stayed up past that!

This Is the Era of the Single-Person Toolmaker

This would have been a weekend project a few years ago.

Or something I’d half-start and abandon.

Instead?

One evening.
Some prompts.
Tight feedback loops.
Working software.

And here’s what’s exciting:

I didn’t build a whole product.

I built a tiny tool I've dreamed about for years - that permanently upgrades how I create.

No Deployment. No Users. Just Me.

This never needs to ship.

It doesn’t need auth.
It doesn’t need analytics.
It doesn’t need a landing page.

It exists entirely in my studio.
If I want to share it with someone - I can send them the prompts I used and they can build it for themselves!

The Bigger Shift

As a software engineering manager, I spend a lot of time thinking about leverage. This was personal leverage.

The same force that’s reshaping design systems, agent-first dev, and code generation pipelines - can also reshape your personal and creative life.

Tonight, I sent 2 tracks to 2 friends just by talking to Rick.

I didn’t hit record once, or write any code by hand.

I just became a vibe coding believer.

This is how I'm going to Vibe Code from now on - Schema-First.

Dean Radcliffe — Mon, 19 May 2025 14:35:40 +0000

Schema-First: The Unsung Hero of Vibe Coding

Last Friday's AI workshop revealed an approach that genuinely caught my attention. After building systems for decades, I've seen countless methodologies come and go, but my colleague's presentation of a vibe-coded medical appointment scheduling system demonstrated something rare: perfect synchronization between frontend and backend components despite rapid development cycles.

What stood out wasn't the polished UI or time it took to occur—it was how locked-in every part of the application was. When he revealed the how it was simply: "Schema-first, with zero exceptions."

What struck me most was how this approach enhanced rather than restricted their "vibe coding" style. While they maintained the intuitive, developer-experience-focused approach that makes coding enjoyable, the schema provided guardrails that prevented chaos. Of course this has always been the case - to build a house you put up a foundation first - but in our hope to nail it all together with one prompt, one shot, we've forgotten how to do layer upon layer upon solid foundations.

I left that workshop with a renewed appreciation for architectural fundamentals. In our rush to embrace developer experience and intuition-driven approaches, we sometimes forget that structure enables creativity rather than hindering it. The lesson wasn't that vibe coding is wrong—it's that vibe coding becomes exponentially more powerful when built on a foundation of well-defined schemas and interfaces.

As I tried this approach on subsequent projects, the results confirm what I witnessed that Friday: architecture still matters, perhaps more than ever. The sweet spot isn't choosing between rigid structure and creative freedom—it's recognizing how the right structure creates the perfect playground for innovation.

Building the 7GUIs with GitHub Copilot

Dean Radcliffe — Wed, 13 Dec 2023 04:46:38 +0000

Unless you've been hiding under a rock, you know that 2023 has been quite a year for AI and programming. And Github Copilot is perhaps the biggest way programmers are using AI to supplement their work. But can AI replace the work of programming?

I think we should put Github Copilot - end of 2023 version - up to some tasks relevant to the modern UI/UX developer. Someone like yourself who might be using React to code front-ends to web applications, and wondering - can AI do my job? Will it take my job? I have a plan to answer that question - at least in 2023 terms.

There are a set of UI programming benchmarks named the 7 GUIs (link). 7 apps whose specifications range from the simple — a counter — to the complex — a spreadsheet. 7 quests designed to test the mettle of any developer— or AI. If we ask Github Copilot to build each of these 7 GUIs of increasing complexity — how far will it get? Can it do it all for us, from the UI to the logic, or is it useful more for one part of the app than another?

In order to make these solutions understandable to the widest audience of developers, I'll specify that these must be built in React, with hooks, not classes. I'll avoid requiring TypeScript types, but evaulate whether the code was written with correct types, if any. I'll include the prompts that I use.

A few disclaimers, for context: I am an English-speaking senior developer with over 20 years experience. I have built all the 7 GUIs in React before. But, I have been working with automated code generators like GitHub Copilot for only about a month. And I want to try, at least at first, getting it all done with standard English prompts that presume nothing about the target solution. I will not try my Spanish out in this series of posts, but I may in a future series, recognizing the global impact of AI across the diverse developer community. And finally I care about maintainability of software. I'll have a robot build my car, but I want the human mechanic to be able to get at the parts to replace them. And I want a certain aesthetic beauty when I look under the hood :)

Lastly, as part of the evaluation, I come with reference solutions to which I will compare the AI solutions. These reference solutions use my libraries @rxfx/bus and @rxfx/service on Github here. So this might become a commercial for those libraries, if the translation of natural language prompts to code goes smoother with RxFx than with Copilot.

With that said, I think we're ready to begin! ❤️ or comment on this post if you are willing to partake in this experiment with me, or have any ideas for how I could tailor it to what you are interested in learning.

See you in the ring, AI!

— Dean Radcliffe

The 7 GUIs:

Making Async, Animated Toasts with an RxFx Service

Dean Radcliffe — Wed, 15 Nov 2023 21:20:27 +0000

A use case: A list of notifications

One time, I needed to code up a list of Notifications, commonly known as "toasts". These pop up for a user's attention, populated by an API or some event, and can be dismissed by the user. They may look like this:

I wanted to build this in pure JS, but use it in React. At first I had an OOP model of it in mind- like this:

class Notifications<T> {
  private items: T[] = []
  get items(): T[] { }

  push(item: T){ }
  remove(item: T){ }
}

I wondered - could I use an object like this, in React, in such a way that whenever an item is added, the UI always displays the current items? It seemed this object model wasn't enough to support a fully reactive list. I didn't want to build this out of React state - I wanted my items in pure JS, so any file that wanted a real-time view of them could simply import and use them. I did not want to worry about Context, or ReactTransitionGroup, or any other view-layer-specific issues, just code in pure JS!

I also wondered how to implement them with fade-in/fade-out, since it's definitely smoother and less confusing with a transition.

I first tried to write an API like this, wrapping a hook around our object:

const notifications = new Notifications<string>;
notifications.push('Svelte')

function Notifications() {
  const items = useObject(notifications, 'items')
  const addNew = () => notifications.push('RxFx')

  return <ol onClick={addNew}> 
    { items.map(item => (<li>{ item }</li>)) }
  </ol>
}

I tried several times to implement this useObject hook, including polling items, but I was never happy with it. Particularly since it didn't address animation, and looked bad without it.

Then I found an object called a Service, from the @rxfx/service package. With a Service, I could have what I wanted, even queued animations! I only had to change the API from the useObject hook by a little bit:

const notifications = new createAsyncListService<string>();
notifications.request({ method: 'push', item: 'Svelte'})

function Notifications() {
  const { state: { items }} = useService(notifications)
  const addNew = () => {
    notifications.request({ method: 'push', item: 'RxFx'})
  }

  return <ol onClick={addNew}> 
    { items.map(item => (<li>{ item }</li>)) }
  </ol>
}

Instead of directly calling methods, I send objects with the method name into the service via its request() method. I invoke useService with a service you'll see defined shortly. Then I extract the state from the return value of useService, and pluck of its items field.

To ensure it was reactive, I wrote the addNew click handler to add an object on the fly. And did it update reactively? It did! Now, I had the reactive, async, animating list of my dreams!

And so I thought I'd share how you can build this functionality in just a few lines of code with an RxFx service, ending up with framework free code you can use in any view layer from ReactNative to Angular to Svelte.

Defining the Service

The first thing to understand about an async list vs. an immediate synchronous list, is that items can be in a state of entering or leaving, as well as fully present. So the state model can not simply be a list of items as in the OOP model.

There are at least two ways a service could represent this state.

Option 1 is that the state could contain a value ranging from 0 to 100, updated on every animation frame, representing how fully in the list the item was. So, for an appearing item in the list:

items: [
  {
    value: "RxFx"
    percentComplete: 95
  },
]

percentComplete could be used to update DOM properties like opacity, or height. But this approach fails to make use of CSS' power to perform animations with just a class name. And it's also not clear whether the item is coming or going.

Option 2 might be to model our state with items, but also with entering and leaving. Imagine we already had 'Svelte' in the list, and pushed 'RxFx'. The state would resemble this, until 'RxFx' is done animating in.

{
  items: ['Svelte', 'RxFx'],
  entering: ['RxFx'],
  leaving: []
}

This is the state model RxFx' createAsyncListService supplies. Here's all we have to do to use it. We define the service like this:

import { createAsyncListService } from "@rxfx/service";

const PER_ITEM_DELAY = 250;
const notifications = createAsyncListService<string>(
  "list/notifications",
  PER_ITEM_DELAY
);

The (optional) arguments are a name for logging, which we'll see more of later. And a delay in milliseconds for each animation.

Notice this service definition can and should live outside of any view component, it's just pure JavaScript! Let's see how to make our view layer react to it now.

Using the Service

Thanks to a utility from the @rxfx/react library called useService, the state of the service can be easily brought into the React view. This gives us arrays items, and entering, and we only need to check if an item is in entering, to assign a CSS class to it to fade it in. The component using the service looks like this:

function List() {
  const {
    state: { items, entering },
  } = useService(notifications);

  const addNew = () => {
    notifications.request({ method: 'push', item: 'RxFx'})
  }

  return <ol onClick={addNew}> 
    { items.map((item) => {
        const isEntering = entering.includes(item);
        const className = isEntering ? "item-entering" : "";

        return <li className={className}>{item}</li>;
      });
    }
  </ol>
}

You are easily able to test that calling addNew adds an item to the service state, and React picks up on it right away. If you wanted to see every change of the service state, you could also send it to the console on every change with this:

notifications.state.subscribe(console.log)

And if you wanted to see every lifecycle event of the service - you can use the fact that it's a listener on an RxFx event bus, and simply log all event bus events to the console:

import { defaultBus } from '@rxfx/service'

defaultBus.spy(({ type, payload }) => console.log(type, payload))

This makes debugging a breeze. Now, to finish things up, we just need some CSS to enable the fade, and voila, we're animating!

@keyframes fadeIn {
  0% { opacity: 0;  }
  100% { opacity: 1;  }
}

.item-entering {
  animation: fadeIn var(--per-item-delay);
}

A finishing touch is to send the same DELAY we used in JavaScript into CSS, so the CSS animation and the service' delay are the same:

document
  .querySelector("#root")
  .style.setProperty("--per-item-delay", (PER_ITEM_DELAY / 1000) + 's');

(Thanks to David Khourshid of Stately AI for introducing me to CSS variables)

Now, see the CodeSandbox for the working version.

Use `@rxfx/service` for all the things!

It turns out, this @rxfx/service container is useful for any async effect, from animation to AJAX. And it has a standard API: .request(), .state.value, and .cancelCurrent(), so you learn it once, and use it for many use cases. Even better, this code is directly usable in Svelte, or Angular or Vue, since it is pure JS/TS code with no view-layer dependencies!

It's built on RxJS, and in other articles I'll show you how other async situations can be handled easily by wrapping an effect in an @rxfx/service.

Happy Notifying!

Please star @rxfx/service on GitHub!

Appendix: Integrating with Redux

Many times, the need for animation comes up after a basic non-animated solution is in place. This was the case for these notifications. The items were in a Redux store, a dispatch was used to put an item into the store, and a useSelector hook brought the items to the page. After we add the RxFx service to handle transitions - will we need to keep Redux?

In this app, in this particular case, we want to keep Redux informed of our list of notifications. We'll have the benefit of the Redux ecosystem, like Redux-Persist, to save and load the store to localStorage.

So, we'll use the service for its animation ability, and Redux for persistence of state.

Inside a custom hook, make the service an intermediary

Initially the Notifications component looked like this:

function Notifications() {
  const { items, addNew, dismiss } = useNotifications();
  /* render items */
}

A custom hook useNotifications defined the API to notifications - you can retrieve items, or addNew or dismiss, and these were implemented by a selector, and sending dispatches.

We can keep this API - but internally we want to make the service an intermediary.

Instead of dispatching, we'll make request() calls to the service
The items of our service are used to populate Redux
items can still come from Redux
We can get a class name for an item, based on the state of the service.

We'll add a getClassName(item) to the hook's return value, then get to work inside:

Changing the custom hook

Inside the hook, push and remove performed dispatches, and items populated by a selector.

Instead, now we'll change the dispatching functions to make request() of our service. This ensures our service is in charge of all changes to items.

Next, we need to sync these items to Redux as they change. We'll use the power of RxJS to ensure that we have an Observable of only changes of items. This enables us to keep Redux free of any information like what is entering and leaving, and focus only on what should persist across sessions.

The finished useNotifications hook looks like this:

import { map, distinctUntilChanged } from 'rxjs'
import { store } from './store'
import { notifications } from './services/notifications'

// Sync to Redux
notifications.state.pipe(
  map(state => state.items),
  distinctUntilChanged()
).subscribe(items => store.dispatch(setItems(items)))

export const useNotifications() {
  const { state: { items, entering, leaving } } = useService(notifications);

  function getClassName(item) {
    /*  based on whether entering/leaving */
  }

  // Make changes first to our service
  function addNew(item) {
    notifications.request({ method: "push", item })
  }
  function dismiss(item) {
    notifications.request({ method: "remove", item })
  }

  return { items, addNew, dismiss, getClassName }
}

With that, we now have the service as our source of truth for the state of the UI, and Redux is a persistence layer, with all the benefits of its DevTools and persistence layer.

So, that's how we integrate. We let Redux do persistence, and let dynamic effects and animations live in a service, which is not persisted. A service will help you keep state fields like loading out of your stores. That's right - you don't need to track loading if you have a service! If you want to know whether the animation is running, you can pluck off the isActive field from the useService return value.

How to use 𝗥𝘅𝑓𝑥 for a realistic user-typing simulation.

Dean Radcliffe — Mon, 20 Mar 2023 18:14:06 +0000

Here we will use a couple of components from the 𝗥𝘅𝑓𝑥 toolkit to write some text into a textarea, much as a user would fill out a form.

If we use a library like @testing-library/user-event, we can automate typing into a field with a configurable delay between characters. However, real users don't type this way, they type in spurts, like this:

Filling out a form in a randomized way will stress-test your form more realistically - some of the time (about 1/6 of the time) your user's consecutive key presses will be half the average duration. Particularly if you are using React controlled inputs, this can reveal stutter in the system that you would not have known about. Also, I find that lorem ipsum text is more pleasurable to see typed with randomized timing than at a uniform rate! But importantly, we don't want total randomness - we want it to hover around a certain given amount.

So let's bring together a few 𝗥𝘅𝑓𝑥 tools together in order to pull this off, we will:

Use a bus, typed for character events.
Trigger character events from a source text.
Create a listener that returns a time-deferred typing from a character event
Allow the bus to execute and sequence those time-deferred typings
Randomize the time amounts

In the final step, the code will change only by one line in order to switch to random from not random! Let's dive right in!

See the CodeSandbox

First, we can type the defaultBus from @rxfx/bus.

import { defaultBus, Bus } from "@rxfx/bus";
const bus = defaultBus as Bus<string>;

Next we'll use a good old-fashioned for loop to trigger an event for each character:

for (let i = 0; i < srcText?.length; i++) {
  bus.trigger(srcText?.charAt(i));
}

Building the listener will be tricky - first we know we can't have overlapping character typings - we want them serially. So we will create our listener with bus.listenQueueing. What will we return? We could have written any delayed Promise function and that would work, but the 𝗥𝘅𝑓𝑥 utility after is designed just for that.

import { after } from "@rxfx/after";

const typer = bus.listenQueueing(
  () => true, 
  (char) => {
    return after(AVERAGE_DELAY, () => {
      console.write(char);
    });
  }
);

This is our entire async behavior! Those after values just queue up - they're lazy Observables. But let's not forget that final touch - the randomization.

In case you are thinking this will be very hard, never fear, 𝗥𝘅𝑓𝑥' @rxfx/perception exports a function that randomizes numbers given it, but in a way that the average is preserved. We just drop it in a place that used to have a constant, and we're good.

+ import { randomizePreservingAverage } from "@rxfx/perception";


const typer = bus.listenQueueing(
  () => true, 
  (char) => {
-    return after(AVERAGE_DELAY, () => {
+    return after(randomizePreservingAverage(AVERAGE_DELAY), () => {
      console.write(char);
    });
  }
);

Now, all that's left to do is trigger each character to the bus, and the queued effects will produce randomly timed typing!

const msg = "This message will reveal randomly";
for(let char in msg) {
  bus.trigger(char)
}

There we go! A pseudo-human typist - something that will look good for chatbot responses, AI, Chat GPT - whatever!

Check out the CodeSandbox and then see how you can use, and enjoy using this!

—𝗥𝘅𝑓𝑥

PS How does randomizePreserveAverage work? One answer I could tell you is that it scales a number by the absolute value of a randomly chosen logarithm between 0 and 1. But a more intuitive way to say it is that it makes 1/3 of numbers larger, while 2/3 get smaller — given that a single doubling event requires two halving events to preserve the average.

Excellent Effect Management in React with 𝗥𝘅𝑓𝑥 and RxJS

Dean Radcliffe — Fri, 17 Mar 2023 19:45:28 +0000

In Part 1, I'd shared an interview that opened my mind to how, and why, to use 𝗥𝘅𝑓𝑥 in React.

In this final installment part we take the UX of the Cat Fetcher to the extreme by adding these features:

Preload images as a chained part of the gifService.
Cancel an image preload when canceled.
Send out Analytics events, without coupling to existing code.
Apply a timeout to the Ajax load and overall load.
Pad the loading spinner to a minimum duration.

We'll even build a cancelable image preloader along the way. So let's dive right in!

Chained Loading Of the Image Bytes

There was an issue with our service. isActive would become false at the time where we knew the URL of the cat image- but didn't yet have its bytes:

This led to the loading indicator turning off, and the UI looks like it's doing nothing - until the image bytes arrive. And that image could take a while to load, if over a slow pipe!

Image Preloading

This old trick always worked to preload an image:

function preloadImage(url) {
  return new Promise((resolve) => {
    const img = new Image();
    img.onload = () => resolve(url);
    img.src = url;
  });
}

This is a Promise-returning function that resolves (with the img url) only once the image has loaded. Perfect! But how would we chain/compose that with the Observable? Simple - one line, like this:

  return
     ajax.getJSON("https://api.thecatapi.com/v1/images/search", {...})
     .pipe(
        map((data) => data[0].url),
+        mergeMap(preloadImage)
     );

Perfect! We've used the fact that a function which returns Promise<string> can be composed onto an Observable with mergeMap - because a Promise<string> is a subset of an ObservableInput<string>. That's all we needed.

But for comparison purposes, and to get ready for cancelation, let's return an Observable instead:

function preloadImage(url) {
  return new Observable((notify) => {
    const img = new Image();
    img.onload = () => {
      notify.next(url);
      notify.complete();
    };
    img.src = url;
  };
};

So we change our Promise-returning function into an Observable-returning one - sending out a single next notification (like a Promise's singular resolution) - followed by a single complete notification. Now we're ready for cancelation.

Cancelation

This chaining, or 'composition', is convenient, but not yet optimal. If a cancelation occurs while the image bytes are loading - the loading of the image itself is not canceled.

The strength of the Observable is you can bundle cleanup/cancelation logic right at the definition of the Effect. For this cancelation, we should cancel the Image loading by switching the src property to an image that doesn't need downloading. The DOM would then cancel itself..

So we simply return a cancelation function from the Observable constructor:

function preloadImage(url) {
  return new Observable((notify) => {
    const img = new Image();
    img.onload = () => {
      notify.next(url);
      notify.complete();
    };
    img.src = url;
+
+   return () => img.src = "data:image/gif;base64,R0lGOD...Ow==";
  };
};

Now, even when cancelation occurs during image bytes downloading, the Observable teardown can stop it mid-request! Cool and performant!

Other Subscribers - Analytics

Now, a new Feature Request arrives that requires we log clicks to an Analytics Service whenever the Fetch Cat button is pressed, so marketing can assess how engaging the app is.

You might be wondering now whether the UI onClick handler, or the gifService Observable ought to change. 𝗥𝘅𝑓𝑥 says - change neither, they're done already!

Handle it by observing the service's requests, with a cancelable item called a Subscription:

const analyticsSub = gifService.observe({
  request(){ logAnalytics('fetch cat clicked') }
})
// to turn off
// analyticsSub.unsubscribe();

For light-weight fire-and-forget functions you don't need to chain or concurrency-control, this mechanism will decouple sections of your codebase, and allow you to keep the code intact (and tests!) of existing components.

Timeouts

Users don't want to wait forever without feedback, and even a spinner gets old. In this post, I set out some thresholds that are handy to reference in timing constants - they are published in the @rxfx/perception library. Whatever values we choose, we need to pass them into code somewhere, and there are a few places this may happen.

For the AJAX to get the URL of the next cat image, we can specify a timeout directly in its options:

function fetchRandomGIF() {
  return ajax({
    url: "https://api.thecatapi.com/v1/images/search",
+    timeout: TIMEOUTS.URL
  }).pipe(

The gifService will trigger a gif/error to the bus if it fails to get the url within that timeout.

But we must ask if overall our gif/request handler might exceed the user's patience. For that, we can wrap the handler in a timeoutHandler modifier from @rxfx/service.

export const gifService = createQueueingService(
  "gif", // namespace for actions requested,started,next,complete,error,etc
  bus, // bus to read consequences and requests from
-  fetchRandomGIF,
+  timeoutHandler({ duration: TIMEOUTS.OVERALL }, fetchRandomGIF),
  (ACTIONS) => gifReducer(ACTIONS)
);

Doing it this way, our currentError property of the service will display information about the timeout, just like any other error!

Concurrency Control

We just handled what happens when the connection is too slow - and we ensured that users get feedback rather than wait forever. But can it ever trouble users if their connection is too fast? Imagine - a user performs 3 quick clicks to queue up 3 kitty downloads - and they could be displayed, and gone before they have a chance to be admired if they download too fast. Here we can pad the download with just another RxJS operator:

function fetchRandomGIF() {
  return ajax({
    url: "https://api.thecatapi.com/v1/images/search",
    timeout: TIMEOUTS.URL
  }).pipe(
    mergeMap(preloadImage),
+   padToTime(TIMEOUTS.KITTY_MINIMUM)
  )
}

While we may decide this amount of padding isn't necessary in every app, for these cute kitties it's probably worth it 😀 🐈 The lesson, of course, is that any RxJS or 𝗥𝘅𝑓𝑥 operator can be used to modify timing with usually no change to surrounding code - whether it's for timeout or time padding. This lets our UX be more intentional in its experience, and less vulnerable to random network conditions.

Conclusion

If there's one thing this code example showed, it's that there's never anything as simple as 'async data fetching'. Timing, timeouts, cancelation, and chained and related effects are requirements that swiftly come on the heels of making a simple fetch. Excellence in UX depends upon handling these 'edge cases' in the very core of your product.

𝗥𝘅𝑓𝑥 has the features you need so that the app can scale in functionality without ballooning in complexity.

The Radcliffe Concurrency Model

Dean Radcliffe — Sun, 13 Nov 2022 08:38:08 +0000

TL;DR The Radcliffe Concurrency Model is a way of understanding how a computer resource, or person responds to an interruption, which will help us understand multitasking in programming, and in life.

Interruptions are a fact of life. Nobody has the luxury of being able to single-task on each thing they start until its sweet completion. No— life is more like this:

Kid: "Dad, I want a grilled cheese, please."
Dad: starts making a grilled cheese sandwich...
Kid: "Dad, can I have chicken nuggets?"

When we ask what we would do as the dad, we are considering which one of our Concurrency Strategies should we use? We'll list these out shortly. But first - notice that although everyone makes these strategy choices - nobody can quickly list what all the choices are! It's like we haven't studied this problem space well enough to pin down the options.

So we'll list the options-but first we'll see how much we need them, and how widely they apply, for developers and humans alike :)

A Lack of Shared Vocabulary Weighs Us Down

If you do something alot, it pays to have concise words to describe it. Some languages have many words for rain or snow or love. Resource schedulers like us need better conceptual tools as well.

What I find today is that async programs —and the humans that make them— do not currently reflect the awareness of these modes. They seem to be a mix of defaulting into a strategy like Immediate , or using only what's easiest in the features of our programming tools. But now, to be able to make clear, tiny-sized changes that fix timing behavior declaratively is a game changer.

Interruptions Affect Computers, UX and People

Computers too must decide what to do when they are busy and get a new request. A chain of coffeehouses has a Dropbox into which each coffehouse uploads its daily transactions as a CSV file. The server is now processing a file of 500 transactions, and a new, different file from the same coffeehouse gets dropped there. What should the server do?

In User Interface / UX these strategies must be chosen and used everywhere! A user begins one download while already downloading another. Or a Ring notification sound is triggered but another just started. Or a like button is clicked twice, or two like buttons in close succession. Or a remote control is slow to respond and you press the button again. What should the app do?

Front-end development, back-end development, and every person you know depends upon selecting good Concurrency Strategies. Then, why don't we know what they are? Is there a listable set? There is, and the Radcliffe Model of Concurrency makes them available for our understanding, so that we can choose the correct one for each UX, or life situation.

(Also a JavaScript library 𝗥𝘅𝑓𝑥 makes them available to program with directly)

Knowing Our Options is Empowering

Before they were called The Radcliffe Model, the Concurrency Strategies, aka modes, were cheekily called: The 5 Kinds of Busy. For the situation of the Dad making dinner, then given another request, the dad could:

Start satisfying the 2nd request right away.
Make it after the 1st request, to use the same pan.
Stop the 1st request, make the 2nd instead.

The other two modes sound funny when applied to humans, but are still relevant sometimes!

Ignore the 2nd request—basically the "Not Now" response.
Turn off the stove and just quit. "I cant keep changing what I make for you— come back when you know what you want!" (This has never happened in the Radcliffe household! 😂)

So, it was out of necessity, that the Radcliffe Model was born!

The Radcliffe Model of Concurrency

The modes in the Radcliffe Model, in English are:

Immediate
Queueing
Replacing
Blocking
Toggling

I recognize these might not be the names you'd call these - you may have used serial and parallel, for either of the top 2 modes. Fine! But the value is not in what they are called, but the fact that they are known as an entire set.

Sometimes, trying to fulfill every request of you, as Immediate and Queueing modes do - stretches resources too thin. The Blocking mode may smartly reduce concurrency by favoring a prior request, just as an elevator that is already requested does nothing on subsequent calls to the same floor. The Replacing mode is seen in how one video playing replaces another when we browse a social site, or how your session timeout keeps starting over after activity. And Toggling is what a one-button power switch does - more on Toggling later.

The reason to learn this model is that getting a computer program, UX, or human behavior to be correct is often done simply by choosing the best mode from the list!

I'll save an elaboration and derivation of each mode for another article. The graphic arranges them spatially to show how they relate, and at the end of the article are some trading-card-style images you can even print as a reference! (And play Oblique Strategies with them if you like)

Yes, Toggling is a Real Thing!

Some of you inquire why Toggling is in this list, since it's actually a failure to do anything concurrent. That's true. Yet still - sometimes it is the called-for response to an interruption.

Sometimes the presence of a 2nd request - like a second nightly file put into the Dropbox on the same night - indicates an exception or error condition.

Toggle and kin are analyzed more in the next post

Go Forth and Be Concurrent!

You can use this model to further your or your colleagues' understandings of multitasking strategies. Or if you program asynchronous systems like User Interfaces, you can use 𝗥𝘅𝑓𝑥, to have the easiest, framework-free async programming experience you could have.

To share it, just consult the Attribution-Share-alike license, which generally says it is free to share,provided you attribute the author and maintain the same terms.

Folks with translation skills - would you propose your languages' names for the modes in the comments?

Thanks, I'd love to hear how you've found this model to apply to you!

Dean Radcliffe (@DeanDevDad)

RxJS - I Have A Bone To Pick With You

Dean Radcliffe — Mon, 31 Oct 2022 14:28:23 +0000

RxJS, there are some things I really love about you, but I think I'm falling for someone new - 𝗥𝘅𝑓𝑥

Your popularity— You have more downloads a month than React and Angular combined.

Your maturity— You're a ripe 13 years old. Forever in technology time, and 3 years older than Promises, even.

Your utility— For eliminating race conditions, all forms of timing control, and resource management— you have no equal.

But RxJS— with all this time you've been around, how come everybody doesn't know that you're the best already? How did you let React become the biggest framework, with useEffect and its quirks, and not even have them build upon you - the best choice available at the time? Now there are all these React developers out there who don't know the joy and power of working with you, RxJS.

But I know you're thinking what React did can't be your fault right? I mean - your documentation is perfect right? No friction to onboarding at-all, right...

So to help you out, I'm going to tell you about your DevRel issues (DevRel) and how to fix them. To start, you gotta do something about your...

Confusing Concurrency Docs

Your documentation for your *Map operators is tragically hard to read. In the v6 docs you say exhaustMap:

Projects each source value to an Observable which is merged in the output Observable only if the previous projected Observable has completed.

So, a previously running ~~Observable~~ Subscription blocks others from starting, you mean.

You could have called it something resembling Blocking.

Your concurrency operators (mergeMap, concatMap, switchMap, and exhaustMap) focus on the notifications themselves, instead of the concurrency strategy that produces them.

This mapping operator could be illustrated by a picture:

Or the family of all of them illustrated as cards with common names and use cases.

That will straighten out your comprehensability issue around these operators.

Observable vs Subscription Confusion

Developers who understand Promises often fail to realize that an Observable is doing nothing without a Subscription. This is what makes an Observable not something you can await.

But RxJS, you sometimes fail to differentiate sufficiently between an Observable and a Subscription in the docs! When the exhaustMap docs said: "only if the previous projected Observable has completed" - that should have said "the previously running Subscription has completed". Observables are templates for work. Only subscriptions can deliver values.

I don't think calling an Observable multicast helps either. An Observable, being like a command, can be executed several times - we dont say that the command is multicasting to its executions.

I don't like calling an Observable a 'stream' of notifications either - it may not have any! I prefer to say that an Observable is a template for creating a process - containing a start function and a cleanup function.

So - terminology is confusing. But it's also unclear where to split up a big chain of Observables.

App Partitioning / Where to Call Subscribe

Some schools of RxJS believe in constructing a giant chain of Observables, with some higher-order ones in the middle, and calling .subscribe() once at the end of it only. The Swipe-To-Refresh example from LearnRxJS.io does this.

Check out its code on StackBlitz. I don't know what you thought separation of concerns was supposed to be - but I don't think that is it.

What are good practices, when combining Observables, especially higher-order ones? If operators are the individual words of your code paragraphs, what does a sentence-level structure look like? If we had that it might help us solve...

Operator Soup

The Swipe-To-Refresh example from LearnRxJS.io starts out with 19 imported operators and functions with raw RxJS. With 𝗥𝘅𝑓𝑥 you implement the same functionality with 6. That's 66% less you have to fit into your mind at once, 13 fewer operators to understand.

Some of this comes from demo sites wanting to show all operators in use. But it's not uncommon to find a ton of operators in real RxJS production code. While each one is purposeful, their many combinations can be confusing.

If we could use fewer operators, we would have less code, and not suffer from as many...

Errors

This is already a well covered topic, RxJS. But you already know it's a source of pain and confusion. Recent changes have helped producers interfere with each other less, but the risk of UnhandledRejectionError bringing down a process is still large.

Why can't we specify 'containers' that can individually terminate on error, without risk to the overall process?

You see, we need some help, RxjS.

Solution - 𝗥𝘅𝑓𝑥

When a community and library are mature enough, some "contrib" library emerges that the community puts its best value-add goodies in. That is what 𝗥𝘅𝑓𝑥 aims to be.

𝗥𝘅𝑓𝑥 is RxJS "The Good Parts". With infinite expansion possibilities via 'raw' RxJS.

Problems like Confusing Docs, Observable vs Subscription Confusion, App partitioning, and Operator Soup, and even Errors are reduced when 𝗥𝘅𝑓𝑥 is your interface to RxJS.

Think of 𝗥𝘅𝑓𝑥 as sugar around an RxJS Subject that acts as an event bus. Each subscriber we call a "listener", and it is a concurrency-controlled, independent Subscription that is error-isolated from all others.

Basically, this means you can get more done with less skipping the several years you need to be fluent in RxJS.

Case Study— RxJS Swipe-To-Refresh Demo

The Swipe-To-Refresh Demo starts out with 19 imported operators and functions with raw RxJS. In 𝗥𝘅𝑓𝑥 - it needs only 6.

I'll dissect and rebuild it in my next post :)

𝗥𝘅𝑓𝑥 - A productivity layer around RxJS.

Dean Radcliffe — Mon, 17 Oct 2022 19:43:09 +0000

RxJS and Observables solve 2 problems that every front-end dev has: Tuning async code for performance and eliminating race conditions for optimal UX.

In this post, we'll deep-dive into building an example with the two main abstractions for async in 𝗥𝘅𝑓𝑥: the bus listener, and the service.

Example: Swipe To Refresh

Obective: Build a "Swipe To Refresh" UX widget with an 𝗥𝘅𝑓𝑥 event bus from @rxfx/bus, and a service on that bus from @rxfx/service.

(A complete version is here on StackBlitz, and built incrementally on GitHub)

What We'll Build

A drag-and-drop UI widget that can trigger a refresh.

The requirements are:

The dot is draggable
The dot triggers a refresh when it overlaps the darker dot.
The dot's position resets upon refresh or release.
The time displays 1 second after a refresh
During time refresh, no other refreshes can begin, and the dot is not draggable.

Overview

This widget will be made from two async 'containers' which we'll develop separately:

The time 'endpoint' (simulated)
The draggable refresh dot

Then to cap it all off, we'll trigger the Time Listener when the Pointer Service is ready, no problem!

One decision criteria for whether to use a listener on an @rxfx/bus or an @rxfx/service is whether we need to know when the service is 'active'. Changing the dot's appearance while dragging is such a use case. To start with, we'll make the mouse-dragger a full service, and the time 'endpoint' a simple listener, and go from there!

Setup / Organization

We're starting with a styled HTML document, and a module of DOM mutating functions. We'll place these in services/DOM. Our time lookup will go in services/time, and our pointer service in services/pointer. A bus will connect all of these, allowing for centralized logging, error handling, etc.

Install The Bus

The bus is like a Subject, on which next is renamed to trigger, and listenBlocking(cond, handler) is a shortcut for subject.asObservable().pipe(filter(cond), exhaustMap(handler)). It comes pre-wired in a single import.

Understanding that, let's declare a bus that accepts strings, and listen for those to implement the refresh side

const bus = new Bus<string>();

The Time Listener

PR containing Just Time Listener Code

A delayed value with `@rxfx/after`

The original Swipe-To-Refresh demo on LearnRxjs.io demo uses no fewer than 4 functions to create a delayed time endpoint: of, delay, pipe and tap.

We can declare a fake value using after from @rxfx/after with only one. Depending on whether we want the time computed at the beginning or the end, we can call after with either a value or a function.

const fakeDateNow = after(2000, Date.now()) // 
const fakeDateAtEnd = after(2000, () => Date.now()) // 

const fakeEndpoint = () => fakeDateAtEnd;

On request, call the time 'endpoint'

Now, we'll create a bus listener to respond with the fake data. Suppose the initiation of the time lookup is to begin when an item equal to time/request goes on the bus.

bus.listen(event => event === `time/request`, () => fakeEndpoint())

We intentionally return the deferred value of the date from the handler. This would work whether the return value was a Promise or an RxJS Observable. Since after is an Observable, thus lazy, we return it to the bus so that it can call .subscribe() on it. But we don't want to subscribe to a new delayed date if one is pending already, so let's solve that.

Don't refresh while already refreshing

Using the console, we see that calling bus.trigger(TIME_REQUEST) twice results in double loading messages.

To adjust this In raw RxJS we would pipe something through an exhaustMap, but we can skip those imports.

In contrast to bus#listen, bus#listenBlocking takes the same arguments, but runs the effect with exhaustMap semantics. We just do:

- bus.listen(
+ bus.listenBlocking(
  event => event === `time/request`, 
  () => fakeEndpoint()
)

Even if our UI will disable things, this makes the intention clear to those reading it. Now lets see these results in the DOM!

On reponse, update the DOM

We have a couple of wrapper functions around our DOM mutation functions, called handleRequestBegin and handleRequestDone, which will update the DOM with the text ...loading..., or the new date, respectively.

To recap, the arguments to listen* are:

cause - the condition that will cause the effect
effect - the side-effecting function to call

and to this we'll now add:

reactions - callbacks that will react to life-cycle events of the Effect.

This observer will be tap-ped in without us needing to import tap, finalize, or others.

const handleRequestBegin = () => {
  console.log('loading...');
  setData('loading...');
};

bus.listen(
  (e) => e === TIME_REQUEST,
  () => fakeResponse,
  {
    subscribe: handleRequestBegin,
    next: handleRequestDone,
  }
);

Time Listener Complete!

This completes our time listener! Whenever anyone calls trigger(TIME_REQUEST), the time will go in the DOM with Blocking behavior. We've cut out a lot of operators at this point, but we can do more.

Let's build the Swipe-To-Refresh pointer functionality out of the higher-level 𝗥𝘅𝑓𝑥 building block - the @rxfx/service, akin to createAsyncThunk or NgRx, and continue to drop operators.

Pointer Service

PR containing Just Pointer Service Code

We expect our Pointer Service to implement dragging our UI element under the pointer, then trigger the time listener. To create the service we need to know what kinds of "requests" it can get - in this case the string "up" or "down". We want its responses to be a stream of numbers - the clientY field of each pointer/move it sees. And its errors are the normal type Error.

export const pointerService = createService
  <'up' | 'down', number, Error>
 ('pointer', bus, () => mouseMoveYs)

const mouseMoveYs: Observable<number> = () => null

The arguments are the namespace, for logging purposes, the bus on which it will put responses, and the effect. The effect will return an Observable of responses, and these will go onto our bus as they occur.

DOM listeners talk to the Pointer service

Now we can add DOM listeners that will pass the service the string 'up' or 'down'.

const sendDown = (e: Event) => {
  e.preventDefault();
  pointerService.request('down');
};
const sendUp = (e: Event) => {
  e.preventDefault();
  pointerService.request('up');
};

export const connectDOMEventsToPointerService = () => {
  document.addEventListener(POINTER_EVENTS.DOWN, sendDown);
  document.addEventListener(POINTER_EVENTS.UP, sendUp);
};

We'll write a disconnectDOMEventsFromPointerService function as well, not shown here. First - let's specify this service's effect and its responses.

On down, moves become responses (until up)

First, let's ensure we're spying on all bus events so we can see what's going on even before we hook it up to the UI.

Now, import fromEvent and map from RxJS..

const mouseMoveYs: Observable<number> = () => {
  return fromEvent(document, 'pointer/move').pipe(
    map(ev: MouseEvent => ev.clientY)
  )
}

Try pressing the mouse down, and notice how as you move the pointer, the console will stream with:

{type: 'pointer/next', payload: 10}
{type: 'pointer/next', payload: 11}

Now, we add in cancelation with takeUntil.

const mouseMoveYs: Observable<number> = () => {
  return fromEvent(document, 'pointer/move').pipe(
    map(ev: MouseEvent => ev.clientY),
    takeUntil(fromEvent(document, 'pointer/up'))
  )
}

We're using operators, but only for their intended purposes. Now, when it comes to updating the DOM, our service gives us choices and modularity that raw RxJS doesn't.

Dot follows pointer / is dragged

We established that pointerService has responses that are of type number, right? And we have a setRefreshPos function that changes the DOM position of the refresh dot. So all we need is:

pointerService.responses.subscribe((r) => setRefreshPos(r.payload));

While the pointerService effect returned raw numbers, the @rxfx/service bundled them into the Flux Standard Actions. We retrieve the raw number from their payload - and yes, TypeScript would have helped you see that :)

What's nice about adding dragging this way is that it doesn't tap into one giant chain. The Dot position is a subscriber - a follower of those pointer/moves. This helps us keep things separated, like ...

On cancel (or complete), reset the dot's DOM position

We'd like, once we've stopped dragging, for the refresh dot to return to its initial position. As you saw in the console, once the pointer/up event occurred, a pointer/complete event was also seen.

We can hook off of this pointer/complete event to call resetRefresh:

bus
  .query(pointerService.actions.complete.match)
  .subscribe(() => resetRefresh());

We are filtering the bus down to all pointer/complete events, and each one causes a resetRefresh. We query the bus since these events are not part of the stream of pointerService.responses.

Now let's hook up our final part, the refresh!

On move, if far enough, cancel drag and trigger the time refresh

We can listen to our service's responses as a stream, and if we exceed the Y threshold to trigger the refresh, we can reset the refresh button by canceling it.

pointerService.responses.subscribe(({ payload: y }) => {
  if (isPastThreshold(y)) {
    pointerService.cancelCurrent();
    bus.trigger(TIME_REQUEST);
  }
});

Our pointer will return to the starting point, because the pointer/complete event will fire upon cancelCurrent(). And we'll no longer be draggging the dot until the next pointer/down. Lastly, we've triggered our time listener with that event of TIME_REQUEST, so everything is working!

Bonus: during drag, change appearances.

I wouldn't want to miss describing one of the great features of @rxfx/service - the isActive Observable that lets you react to one of its effects being active. Just watch how we can make it easier on the eye!

pointerService.isActive.subscribe((isActive) => {
  const method = isActive ? 'add' : 'remove';
  document.getElementById('refresh').classList[method]('isDragging');
});

While refreshing, the dot is not draggable

We built our Pointer Service and Time Listener to not know about each other—initially. Now that we want to do something while the Time Listener is active, we could re-write it as a service and subscribe to its isActive property as we could for the Pointer Service.

But since we already have functions in the Time Listener's Observer we can use those to stop sending events to the Pointer Service.

const handleRequestBegin = () => {
  console.log('loading...');
+ disconnectDOMEventsFromPointerService();
  setData('loading...');
};

Now, as our coup-de-grâce, we have implemented a form of blocking mode by hand to complete our widget!

PR of Pointer Service

PR of entire demo

Summary

We used fewer individual RxJS operators to build the 𝗥𝘅𝑓𝑥 way than with raw RxJS. The service and listener concepts let us apply operators without creating a giant chain. Features are added separately, with little interference to each other.

With 𝗥𝘅𝑓𝑥 your app is mostly a list of tuples of:

[cause1, effect1, reactions1[]]
[cause2, effect2, reactions2[]]

Your app grows in a maintainable and performant fashion — at least, it has for me. You can also use it to create Observables of state from triggered events, and a lot of other fun things. Pub-Sub is a great paradigm for rapid and modular app building.

Enjoy building and listening!

𝗥𝘅𝑓𝑥 Creator, Dean Radcliffe

Ordering Event Bus Events with RxJS and concatMap

Dean Radcliffe — Tue, 20 Sep 2022 04:34:20 +0000

An Event Bus can help our app by providing a single source of truth for the relative timing of events. If trigger('B') follows trigger('A') , then we we expect listeners will receive events in A, B order. Any other order would certainly lead to bugs.

Strangely enough, with a simple implementation of an Event Bus in RxJS (a Subject, and some Observers that tap in a function), one can accidentally introduce a bug in which listeners don't hear events in the same order! Both the buses Luis Aviles made here and the one I built in this post suffer from this bug. In this post we will use concatMap to fix that, learning the "Return The Work" principle of Observables.

Your Thoughts?

The library that implements this bus fully today is called omnibus-rxjs. I'm thinking of putting it up as @rxfx/bus, and extracting out a family of libraries under that namespace. Which name do you like? Leave a comment below.

Trigger and Listen

In part 1 we constructed an Event Bus that let us:

Call bus.trigger to trigger an event to the bus
Use bus.listen to register a function to be run on matching events.

On this bus, what happens if a handler function run by bus.listen contains a call to bus.trigger? Could this confuse the event ordering?

bus.listen(
  (item) => item === "hello-dave",
  () => { bus.trigger("hello-HAL") }
);

On the surface there's nothing suspicious here. And to review our bus code at this point, it's nothing more than this:

class Bus<T> {
  private events: Subject<T>;
  constructor() {
    this.events = new Subject();
  }
  listen(matcher: Predicate<T>, handler: (item: T) => void): Subscription {
    return this.events
      .asObservable()
      .pipe(filter(matcher), tap(handler))
      .subscribe();
  }
  trigger(item: T) {
    this.events.next(item);
  }
}

So, assuming 3 events are triggered, how could 2 listeners disagree on what order the events arrived?

// Listener 1 heard: ["hello-world", "hello-Dave", "hello-HAL"]
// Listener 2 heard: ["hello-world", "hello-HAL", "hello-Dave"]

The Stack is The Culprit

JavaScript is a stack-based language, where each synchronous function call begins and ends inside its parents'. How is this relevant? Allow me to illustrate..

Suppose there are 3 listeners on a bus carrying strings. First we create a logger called L1. Then our 'Dave listener' which will re-trigger. Then another logger called L2 will be attached. If we fire an event that re-triggers, like "hello-dave", this shows the sequence of calls to the listeners that results in the problem:

 trigger('hello-Dave')
  - L1 listener
  - Dave listener
     - trigger('hello-HAL')
        - L1 listener
        - L2 listener
  - L2 listener

At runtime, the trigger('hello-HAL') from inside the "Dave" listener started firing each matching listener sequentially. But L2 hadn't yet processed hello-Dave, so L2 sees hello-HAL even before hello-Dave. This is what we want to prevent. Our answer will be to not begin the re-triggering immediately, but to "Return the Work"

Observables - Units of Work

Of all the definitions of Observables out there, the one I like is that an Observable represents the potential for some work to be done, or resource to be used. Like the command-line string ls -l encodes the potential of a memory-occupying, data-emitting process. So wherever you did work immediately before, you can now do it in an Observable. Like React VDOM is for DOM elements, Observables are to effects.

Now, if we have a stream of these work Observables, we can strictly serialize them with the RxJS operator concatMap.

The Fix

If you suspected some kind of queueing was the solution you're right. But if you didn't know aboutconcatMap, you may have imagined building some data structure to hold the queue. But the concatMap operator actually does this internally already. Let's give our bus an RxJS Subject for the triggerings we want to serialize.

class Bus<T> {
  private events: Subject<T>;
+  private triggerings: Subject<Observable<void>>;

  constructor() {
    this.events = new Subject();
+    this.triggerings = new Subject();
+    this.triggerings.pipe(
+      concatMap((t) => t)
+    ).subscribe();
  }
}

When the constructor is run, the triggeringsSubject begins listening for work items—Observables—which it passes to concatMap to execute only serially. Now, we change the implementation of trigger to push one of these work items to that Subject:

  trigger(item: T) {
-    this.events.next(item);  
+    this.triggerings.next(
+      new Observable((notify) => {
+        this.events.next(item);
+        notify.complete();
+      })
+    );
  }

The Observable's work is to run each listener for the item completely and synchronously with events.next(item), and only then call notify.complete().

And voila! concatMap can serialize the calls now! We no longer violate causality, and our logs show each listener agrees on the same event ordering.

// Listener 1 heard: ["hello-world", "hello-Dave", "hello-HAL"]
// Listener 2 heard: ["hello-world", "hello-Dave", "hello-HAL"]

And we can see this is because triggerings—the execution of those Observables—always finishes notifying listeners for one event before processing the next one.

 trigger('hello-dave')
  - L1 listener
  - Dave listener (queues hello HAL)
  - L2 listener
 trigger('hello-HAL')
  - L1 listener
  - L2 listener

Decoupling For The Win

Where we're going with this bus is to make it usable for a Pub-Sub implementation. This bug we just fixed was a kind of coupling, where "Dave listener" was interfering with L2's event order. This is normal when making sync calls in a stack-based language, but we can bring order back to it again with RxJS.

Now that we've decoupled this runtime behavior of listeners from each other, it's time to look at another important way listeners should be decoupled: errors. And that will be the topic of the next post.

How an Interview Convinced Me to Use 𝗥𝘅𝑓𝑥 and RxJS for Effect Management in React

Dean Radcliffe — Fri, 20 May 2022 15:02:58 +0000

Edit: Here is part 2 of this series.

Note: Some images refer to the library's old name "Omnibus-RxJS" and have not been updated to 𝗥𝘅𝑓𝑥.

An Interview Like No Other

It was a front-end React UI developer interview which began like any other. But unlike others, by the end of it I'd learned enough to change my whole approach to data-fetching, or maybe to async programming in general.

I was the interviewer for a 60 minutes live-coding interview. The goal was to build a simple React GUI that could fetch a random GIF. We assumed any candidate who reached this round could do async data-fetching in React. But we wanted to learn how a candidate thought about front-end problems in general. We were looking for some insight that we didn't already have. And in this candidate— call them Chris - we found it :)

I handed Chris the paper with the requirements for their live-coding interview.

Getting Acquainted

The requirements contained an image of what was to be built in the interview.

Chris asked a few questions:

"Does it have to be cats, or will any GIF do?"

"Ha!" I said. "You can choose any GIF you want, but we've provided a function to get cats."

const fetchRandomGif = () =>
  fetch("https://api.thecatapi.com/v1/images/search", {
    headers: { "x-api-key": "blah-blah" },
  })
    .then((res) => res.json())
    .then((data) => data[0].url);

"Can I use any libraries?" was Chris's next question. I replied: "Do you think one is needed for this app?"

"Well, we need a cancel button... And I find Observables make for cleaner, less error-prone code around cancelation."

This took me by surprise. I only knew of one cancelation tool, AbortControllers, and Chris pinpointed my frustrations with them - that they're easy to forget, don't compose well, and obscure the logic of the happy path.

I said, "yes you can use a library, but you must be able to explain what it is doing, and justify its contribution to the bundle size."

Chris chimed up with, "Sounds good— shall we get to work then?"

𝗥𝘅𝑓𝑥—An Odd Choice of Library

Chris started by creating a new file, naming it gifService.ts. I gently inquired why they made a separate file instead of coding into the provided React component.

"React is the view layer, this is- well, a service layer. Easier to test with no React dependencies. Can I proceed?"

"Go for it," I said. Chris wrote the following as though from memory, and in TypeScript, but I'll post just the JS here.

import { createService } from "@rxfx/service";
import { fetchRandomGif } from "./prebuilt-for-candidate";

export const gifService = createService("gif",() => fetchRandomGif);

gifService.bus.spy(console.log); // log all lifecycle events on its default bus

I said - Ok, now what is this library doing?

"Have you used Redux Saga, createAsyncThunk, or other async middleware? 𝗥𝘅𝑓𝑥 is a drop-in replacement, at less than half the bundle size. The bus receives events, which the service will put onto the bus as the effect starts, provides data, etc."

I knew Redux Saga. I said "The fetchRandomGif function - it's not written as a generator function or a saga, it just returns a Promise. Is that going to be compatible with your bus?"

"Yep, no problem. It can do Promises, Observables, iterables. It's just RxJS underneath.

If you've ever been frustrated using React Context or prop-drilling to share data across an app, a service or bus is a framework-free way to do the same. It was Signals before Signals! It's so useful, I don't know why it's not built into every app!"

I did have prop-drilling and React Context issues, and I saw how events being visible to any part of the app by default would result in less code. That satisfied me of their choice, and I asked Chris to continue.

The State Model and Reducer

"Great— now let's start on our state model. It looks like there's only one field we need in state - the URL of the current image - is that right?"

I said "Are you forgetting the loading and error states?"

"One nice thing about an 𝗥𝘅𝑓𝑥 service is your state model doesn't need to include loading and error. You get into trouble when you mix transient fields like loading and error into state fields that you may want to persist for longer - like across sessions. Separate things that change at different rates, right?"

I had just dealt with a bug where a loading state loaded from local storage with a value of true - the spinner spun but nothing was happening. It occurred to me it was not really DRY to have a state field that isn't a direct reflection of whether a process is actually running, so I was ready to see it in action.

"We still need to see loading and error in the UI, but let's go ahead with a loading-free reducer."

The reducer looked like this:

const initialState = {
  url: "",
};

export const gifReducer = (state = initialState, e = {}) => {
  switch (e.type) {
    case "gif/next":
      return { ...state, url: e.payload };
    default:
      return state;
  }
};

I noticed the strings in the case statements, and I said "These look like Redux Toolkit conventions, but with different names - where do they come from?"

"Fair question. A service has a standard set of actions, based on Observable life-cycle events. The next event delivers data, error an error, and started indicates a search began. There are typesafe versions of these too, do you want me to use them?"

I said, "Let's skip that for now and get our data in the UI."

"Cool. Then let's add the reducer to our service."

Chris changed the line to create the service ever-so-slightly, by adding the reducer.

- createService('gif', () => fetchRandomGif);
+ createService('gif', () => fetchRandomGif, () => gifReducer);

"And now let's bring state into our UI".

UI Updates

Chris typed the following in a flurry of keystrokes..

import { gifService } from "./services/gifService";
import { useService } from "@rxfx/react";

function CatFetcher() {
  const { state, request } = useService(gifService);
  const { url } = state;

  <img src={url} alt="Animal GIF" />
  <button onClick={() => request()}/>

I said "Let me get caught up. Through the useService hook, we have a reference to the state produced by the reducer. And we have a function with which to request the effect, which changes the state?

"Yeah, precisely!"

It worked great— on the happy path. Now what about errors, I asked.

Errors

Chris hacked a thrown error into the fetch endpoint. Then captured a currentError field from the hook. Then used it in React to show the message.

-  const { state, request } = useService(gifService);
+  const { state, request, currentError } = useService(gifService);

<div className="error">{currentError}</div>

I tested that when an error was shown in the GIF fetcher, the error display just worked. And it was cleared automatically on the next click. I guess that's why the field is named "currentError"—once a new one begins there is no current error. A nice convenience.

After it had shown an error, it resumed future fetches just fine. I said to Chris "You pulled that off nicely. But since you left loading out of your state, how will we display that?"

Loading State

While the GIF is loading, let's change the text "Fetch Cat" to "Fetching.."

Chris captured the isActive field from the useService hook return value.

-  const { ... currentError } = useService(gifService);
+  const { ... currentError, isActive } = useService(gifService);

<button onClick={() => gifService.request()}>
  {isLoading ? "Fetching." : "Fetch Cat"}
  {/* Fetch Cat */}
  <HourglassSpinner show={isLoading} />
</button>

That isActive variable - the hook just knows that a fetch is active?

"Sure does. The service knows when it's doing work. It keeps a count of gif/started and gif/complete events and emits true when the count is > 0 and false otherwise."

I pretty much decided Chris had passed the interview, but to throw a challenge I asked about cancelation.

Cancelation and The Finished Product

I'd shipped many apps without cancelation before, especially before Abort Controllers. But I knew that to do top-notch UX, one had to be able to cancel effects to free up resources.

I asked how we could cancel a load while in progress. Chris added a Cancel button to the form, and I stepped out of the room for a second.

<button onClick={() => gifService.cancelCurrent()}>Cancel</button>

When I returned, I opened up DevTools, and clicked Fetch Cat. I clicked Cancel, and BOOM, a canceled XHR on /search!

Chris showed the new fetchRandomGif function - which looked like the Promise-based version.

import { ajax } from "rxjs/ajax";

const fetchRandomGif = () => ajax.getJSON({
    url: "https://api.thecatapi.com/v1/images/search",
  }).pipe(
    map((r) => r.response[0].url)
);

Seeing this, I asked, "So the service can just cancel this AJAX, even without an AbortController?"

"Cancelation is automatic- as long as the endpoint returns an Observable. It's crazy - every Observable since 2012 is cancelable, and yet today we have just Promises. It's nice that in 𝗥𝘅𝑓𝑥 you can return a Promise for an MVP, and switch to an Observable when you implement cancelation in phase 2 - with no change to surrounding code."

This was great. That ease of change was not my experience with Promises, where switching to a Promise requires all kinds of functions to be labeled async.

I made a mental note: Suggest the whole team learn about Observables and this API around them. Promises being run-to-complete by default started to look like a very bad idea, especially when it was easy as this to swap a non-cancelable AJAX with a cancelable one.

A Mysterious Departure

Chris had exceeded expectations on the first 3 mandatory points of the challenge. I wanted to hire, so I moved on to Chris's questions. We talked pleasantly, then when we were standing up to say goodbye, curiosity got the best of me, and I asked one more technical question:

"Just curious- but how would you handle a click while a GIF was already loading? Something like XState?"

Chris lifted their backpack to their shoulder and smiled.

"Oh, the 𝗥𝘅𝑓𝑥 service has that covered too. Just change the call to createService to createQueueingService and you're covered. I'll send you a CodeSandbox of it later today so you can try it out."

And with that, Chris was gone. And my learning into RxJS and 𝗥𝘅𝑓𝑥 had just begun.

Author's Note

Here's the CodeSandbox of the Cat Fetcher.

As you may have guessed, this was a fictitious story, written by me, Dean, the author of the 𝗥𝘅𝑓𝑥 packages. 𝗥𝘅𝑓𝑥 was not designed to handle interview problems, but real world ones! And it has been deployed to production in various forms for 4 years, solving problems like dynamic forms, 60FPS animation, Web Sockets and many more. I hope you will give it a look, and let me know what you think!

And soon there will be Part 2 where we address timeouts, maintaining the loading state until the bytes of the image have arrived, and other subtleties of data fetching and effects in general.

-- Dean

Update: Here is part 2!

Kata, Bunkai and Testing

Dean Radcliffe — Sun, 06 Mar 2022 19:06:26 +0000

Kata

Kata (martial arts): A detailed, choreographed sequence of movements, blocks, strikes and footwork, executed without a partner. Kata are used as a mnemonic device for a series of techniques, flowed together.

Bunkai

Bunkai (分解) in Japanese, literally meaning "analysis" or "disassembly" is used in Japanese martial arts to describe the process of extracting fighting techniques from the movements of a kata.

Kata in the Karate Kid (and Cobra Kai)

In the 1989 film Karate Kid, Mr. Miyagi has Daniel-san practice cleaning the dojo as part of his training. You may recall the "wax-on, wax-off" lesson. This introduced Daniel to a technique, or fragment of a kata. For the longest time Daniel didn't know if he was doing it right. Then Mr. Miyagi throws a punch at him - and his body reacts with the technique he rehearsed. "Wax on" - and he deflects the punch automatically! This illustrates the power of intentional practice - which by analogy we will extend to writing production code as its own kind of fight.

Kata in Karate

A karate class usually has a group kata practice toward its end. The time before is spent focusing on individual techniques, often practiced with partners. This helps establish the building blocks of the kata.

A belt promotion depends, among other things, on satisfactory demonstration of that belt's entire kata. This ensures that all the techniques associated with that belt level are demonstrated by the student. Thus the number of demonstrable katas is one measure of a student's skill level. The first 10 levels up to 1st degree black have widely varying kata, ensuring each level adds to the student's skill.

"Code" Kata

Code Kata is the rehearsal of specific coding problems, and I've definitely seen workshops built on it. Sites like Project Euler and Code Warrior provide simple problems where you can focus on honing individual skills. I suggest at least trying them. Many coders think it's pointless to solve 'simple' problems, and thus miss the opportunity to develop the "wax on wax off" kind of mastery that comes only from repetition.

Testing as Bunkai

The analogy of kata to production code is pretty interesting. Both are composed of smaller building blocks. Both are complex and take time to get right. Kata, like production code, are what get people promotions and recognition. But bunkai, like testing, is the counterpoint is needed to develop them.

How bunkai develops kata is like this: To practice a kata's block/punch combination, your partner will throw an attack. When you respond to the attack, you practice the kata's technique in the context of its intended application.

In this way, the bunkai is the reason for the kata. Exactly as test-first development 'throws the first punch' and puts pressure on the code to respond correctly!

Kata that are not practiced against opponents' bunkai seldom have the snap or polish they could have. Could the same be true about code that is not robustly tested?

Tests Shape Code as Testing Shapes Developers.

What if I said, "I think 50/50 is a good theoretical split of time focused on tests/prod code". Would that be an uncomfortable thought to you? If so-why? It could be that you haven't figured out how to turn its benefits to your favor. Perhaps doing an 'analysis' aka bunkai will help.

If you believe testing is less than 50% important, consider a thought experiment: Imagine a machine, or an AI, that could spit out source code, which you could quickly test whether that source code satisfied the test suite or not. You might not know or care what the code looks like, you just know it does what you specified in the test suite! Programmers may become replaceable, but those who write the specifications (aka tests) can't be replaced! Investing in those skills just seems smart to me.

In summary, testing is an "analysis" or "disassembly" of production-ready code, as bunkai is for kata in karate. When there are complementary evolutionary pressures, it results in growth on both sides. Anyway its secretly fun! If you've never written a failing test first, then made it pass, you are missing out on one of the great satisfactions of programming. To have pairing sessions where someone 'tests' and another codes - aka "ping-pong" style 🏓 - is simply delightful.

Let testing do for your software practice what bunkai does for kata in karate. Enjoy crane-kicking your way to success!

A Personal note: My adult karate path began in 2010 when my friend Hope gave me a gift certificate for a membership at her karate dojo. Though I saw her achieve 1st black belt, mental health and depression issues claimed her before her time. This one is for mental health awareness—and Hope.

DEV Community: Dean Radcliffe

Vibe Coding an Audio Engineer Who Never Sleeps

The Idea: A Ring Buffer As The Engineer

How I Built it (OpenClaw Vibe Coding)

This Is the Era of the Single-Person Toolmaker

No Deployment. No Users. Just Me.

The Bigger Shift

This is how I'm going to Vibe Code from now on - Schema-First.

Schema-First: The Unsung Hero of Vibe Coding

Building the 7GUIs with GitHub Copilot

Making Async, Animated Toasts with an RxFx Service

A use case: A list of notifications

Defining the Service

Using the Service

Use @rxfx/service for all the things!

Appendix: Integrating with Redux

Inside a custom hook, make the service an intermediary

Changing the custom hook

How to use 𝗥𝘅𝑓𝑥 for a realistic user-typing simulation.

Excellent Effect Management in React with 𝗥𝘅𝑓𝑥 and RxJS

Chained Loading Of the Image Bytes

Image Preloading

Cancelation

Other Subscribers - Analytics

Timeouts

Concurrency Control

Conclusion

The Radcliffe Concurrency Model

A Lack of Shared Vocabulary Weighs Us Down

Interruptions Affect Computers, UX and People

Knowing Our Options is Empowering

The Radcliffe Model of Concurrency

Yes, Toggling is a Real Thing!

Go Forth and Be Concurrent!

RxJS - I Have A Bone To Pick With You

Confusing Concurrency Docs

Observable vs Subscription Confusion

App Partitioning / Where to Call Subscribe

Operator Soup

Errors

Solution - 𝗥𝘅𝑓𝑥

Case Study— RxJS Swipe-To-Refresh Demo

Links

𝗥𝘅𝑓𝑥 - A productivity layer around RxJS.

Example: Swipe To Refresh

What We'll Build

Overview

Setup / Organization

Install The Bus

The Time Listener

A delayed value with @rxfx/after

On request, call the time 'endpoint'

Don't refresh while already refreshing

On reponse, update the DOM

Time Listener Complete!

Pointer Service

DOM listeners talk to the Pointer service

On down, moves become responses (until up)

Dot follows pointer / is dragged

On cancel (or complete), reset the dot's DOM position

On move, if far enough, cancel drag and trigger the time refresh

Bonus: during drag, change appearances.

While refreshing, the dot is not draggable

Summary

Ordering Event Bus Events with RxJS and concatMap

Your Thoughts?

Trigger and Listen

The Stack is The Culprit

Observables - Units of Work

The Fix

Decoupling For The Win

Links

How an Interview Convinced Me to Use 𝗥𝘅𝑓𝑥 and RxJS for Effect Management in React

An Interview Like No Other

Getting Acquainted

𝗥𝘅𝑓𝑥—An Odd Choice of Library

The State Model and Reducer

UI Updates

Errors

Loading State

Use `@rxfx/service` for all the things!

A delayed value with `@rxfx/after`