DEV Community: Adam L Barrett

A Tale of Two Apps

Adam L Barrett — Tue, 29 Dec 2020 19:52:39 +0000

There are 2 ways to think about the web application you're working on.

In truth there are way more than 2, but this article is about 2 particular ways and how they are different.

The difference is subtle and a bit nefarious because the idea is more philosophical than technical, but can have damaging effects when 2 or more members of the same team view their application differently.

Personally, I find it very frustrating when articles drag on like some sort of mystery novel, yammering about this and that until they finally get to the “big reveal” of what the article is actually about, and in my first draft of this article I found that’s exactly what I did, so with the power of editing, allow me to start off by describing the 2 ways to think about your web application:

#1: the Interface Model application

In this mental model, the application is generally thought of as “on the server” (regardless of what architecture that server is built on) and the web portion of that application is the User Interface (UI) or “view” of that application.

I would say this is often the “traditional” perspective taken by developers, especially those who did not start their careers in front-end development, though with all things of course there are exceptions. Storage is most often within databases of one kind or another, with decisions and business logic in server side code, sometimes exposing API interfaces such as RESTful APIs or GraphQL and other times web pages by serving HTML from URL endpoints.

#2: the Distributed Model application

In the distributed mental model, the client-side is the application. The RESTful and GraphQL APIs serve to support the application with services such as storage, aggregation and heavy calculation, but decisions, state management and UI are handled in the app, on the users device.

This is not to be confused with the narrow definition of distributed apps (dApps) running on top of a blockchain, smart contracts or peer-to-peer (P2P) networks, this is still just referring to web applications even if they have centralized authority and storage, but distributed in the sense that the application is intended to run on many machines independently, with both the benefits and detriments that entails.

This is often how native mobile developers model their thinking, and due to the rise of Single Page Apps (SPAs) on the web, has been a common perspective in web developers for many years now as well.

So what’s the problem...?

As mentioned before, this difference is subtle and is not based on the technology or framework, but instead it is more like a philosophy or a framework for your mind. It can be so subtle in fact that 2 members of the same team, working on the same codebase, can find themselves viewing the app differently in this regard.

This can lead to issues.

When the mental models of the application on a team are not aligned in this way, the problems often manifest themselves as criticism of “over engineering”, snarky remarks, hostile guffaws about “doing it wrong” and the far more insidious manifestation: assuming your co-worker “just doesn’t really know what they are doing”.

Sometimes, this can lead to wasted time, as developers debate and argue over technology choices. Sometimes it can grow worse as bolder developers change the work of others because "that should run on the server" or some other point of view. And sometimes, just sometimes, it can lead to conflict and the breakdown of trust on a team.

By clearly defining and documenting if your application is using an Interface Model or a Distributed Model, you can circumvent these issues, and it can even add another dimension to evaluate technology choices on, as some tech may feel more or less appropriate depending on your applications model choice.

For example:

If you are working on an interface model application, state management libraries such as Redux, NgRx, even MobX and others may seem like overkill, because you're not really working with your application state, you are working with a local cache of the application state.

I think the big feelings of great joy and gratitude that gushed forth across the intertubes when libraries like Recoil, SWR and the wicked-smaht React-Query, hit the mainstream, were directly from the idea that their concepts fit the mental model of an interface model application better.

Why I Stopped Using Redux is a great article, and the author is thinking about applications in the Interface Model and yet, immediately in the comments I see people responding who are thinking in terms of the Distributed Model. But without the framework or language to differentiate, they assume the author is “wrong” and tend to conflate the breakdown with complexity or scale, which seems to baffle other commenters who are thinking in terms of the Interface Model.

In the article My State Management Mistake, Kent C Dodds laments confusing "server cache" with UI state (the stuff that disappears when you hit refresh), and though I wholeheartedly agree in the difference, I think the article is very slanted towards the Interface Model and the same problem could be dealt with, also by separating the business domain data and the UI state on the client, if you were building with the Distributed Model in mind.

In a Distributed Model app, that’s not “just the cache” you’re working with, that is your apps current data and state. The GraphQL and RESTful API’s just serve their role of storage, aggregation and a service for heavy calculations, so, what may seem like over-engineering your server cache, may seem perfectly reasonable in the distributed context.

For a long time now, since the rise of SPAs, the Distributed Model was very popular in modern web development. Even when many developers expressed the idea we had strayed too far from traditional web apps “just for some fancy animations and transitions”, there continued to be litany of state management libraries released specifically for handling all your application needs right in the client.

But, the tides are certainly changing now, and with the rise of “island architecture” frameworks, like Remix, Hotwire, and others the pendulum is swinging back towards the Interface Model.

And that server-ward swing got punched into overdrive when Dan Abramov and Lauren Tan announced the upcoming React Server Components. Because they, and the rest of the React team, hold such an incredible amount of sway in JavaScript community, and have a tendency to deliver features that change the entire ecosystem, beyond just React, and despite warning and a plead to not jump in too early, a new mob of developers will be psyched, and start evangelizing Server Components as “the new way to write web apps”.

Soon, every other framework will be pummelled with issues and demands for “server components” of their own. Arrogant gatekeepers and well-meaning “JavaScript influencers” will begin to proclaim we are “doing it wrong” if we don't include an accompanying Node.js app filled with the magic of streaming DOM updates hidden behind the familiar React component interface. ...and to be honest, I am a little psyched myself.

But there is still a place for the distributed model in web applications.

If, for example, your team consists of mostly front-end developers who are comfortable with client side technology, that’s probably reason enough to work in the distributed model. The right tool for the job adage definitely includes the skills your team currently have.

You may also have an app that could make the jump to a dApp, built on Ethereum or some other distributed system, removed from centralization, and starting your app in the distributed model may better prepare you for that jump.

Maybe one of your app's primary features is offline use, and if a good portion of your app can be used without a network connection, that may be a strong indicator that the distributed model may be more appropriate.

It may also be that your app is simple in its data requirements, and differentiates itself with design and interactions, and treating the app as an interface model application just doesn’t feel right.

And maybe you want to minimize your server costs and security concerns, so you’re leaning full Jamstack, pushing your app to edge CDNs and leveraging cloud services like Auth0 and Fauna to handle the parts you just don’t want to deal with.

Conversely, using any technology that blurs the line between client and server is probably a good sign that the Interface Model is more appropriate for your application:

If your application implements an RPC (remote procedure call) API
React’s upcoming Server Side Components
Tools like Blazor (C#) or Flutter (Dart)

...or similar technologies.

So in closing, my advice is this:

Decide and document which mental model you are designing your app with. Evaluate your tech stack and see if alternatives may seem more appropriate with that decision in mind. Ensure every new developer onboarded to the team is also informed whether your app is built on the interface model or the distributed model. Stop assuming people don’t know what they are doing, and rather, see if you can understand how they are thinking.

That last one is pretty good advice in general.

RxJS with React: Actions and Subjects

Adam L Barrett — Mon, 31 Aug 2020 04:13:15 +0000

RxJS and React go together like chocolate and peanut butter: great individually but they become something incredible when put together.

Actions

So in the last article, we looked at how you can use the React built-in hooks useState and useEffect to subscribe to RxJS Observables. We created a custom useObservable hook that we can pass an RxJS Observable to, which will return the current value of the Observable and re-render every time the value changes.

In the React community, there used to be a lot more talk about the concept of Data Down and Actions Up (DDAU). With our useObservable custom hook, we've got the "data down" part cased, so now we need to handle the actions.

What are actions anyway?

Nowadays, there are 2 meanings to what we call React actions:

The original meaning, which was just about passing functions (callbacks) as props to communicate with your parent component. There is no 2-way binding in React, so if the child component wants to tell its parent component someone clicked a button or changed an input, it calls a function that was passed to it as a prop, which is sometimes known as the delegate pattern. Actions are just the act of calling those delegate prop functions (callbacks), like onChange or onPause.
Redux popularized a new meaning for actions though. In Redux, actions are serializable objects that describe the interaction or intent of the user. Conventionally they have a type property, and optional payload and meta properties as well. The action objects are dispatched into the Redux store by calling the store's dispatch() method, and passing the action object as an argument.

But whether actions are the act of calling a delegate callback function, or an object describing the intent passed to a dispatch call, it still represents the idea that "something happened", and I would like to send a message to my parent component, the store, or whatever, describing what happened.

Subjects

RxJS Subjects are a great fit for dispatching actions. Subjects are special Observables that can also act as observers, because they implement the observer interface, which is just a fancy way of saying it has the methods next(), error(), and complete(). You can dispatch actions by calling a subject's .next() method, and passing whatever description of the event you need as an argument: Whatever argument we pass to .next() is emitted to all the subject's observers, sometimes called subscribers.

We can use RxJS's Subject to implement something like a Redux store. We can derive our State observable, as a combination of the current state, and an observable of actions which we get from using our Action Subject.

To get a clearer picture of what that means, let's use the simple useObservable custom hook we wrote in Part 1 to create a simple count widget.

We'll create an observable of state (count), out the observable of actions + the current state:



// this will be an observable of `increment` or `decrement` strings
const action$ = new Subject();
// map the action strings to a state update number
const update$ = action$.pipe(
  map((action) => (action === "increment" ? +1 : -1))
);
// update the state by summing the state and the update
const count$ = update$.pipe(
  startWith(0), // our initial state will be 0
  scan((count, update) => count + update)
);

...and a widget component that uses the count$ observable and the custom useObservable hook to get a count state, and also uses the action$ Subject to update the state by passing increment or decrement actions to the action$.next() method.



const CountWidget = () => {
  const count = useObservable(count$);
  return (
    <div className="count-widget">
      <button onClick={() => action$.next("decrement")}>-</button>
      <span>{count}</span>
      <button onClick={() => action$.next("increment")}>+</button>
    </div>
  );
};

Here is the simple demo of the above.

This is simplistic but the idea can be expanded to something more useful. If we combine the same technique with our User Name Fetcher from Part 1, we could easily add a paging feature to give the user the ability to navigate through a list of items. We create a callback function that takes an Observable of the 'back' and 'forward' actions dispatched in our component, and based on that, it fetches new "pages" of users, by increasing or decreasing the page query parameter in the API call.

Though the example is a little more involved, the idea is the same, create an observable of "page number" which is derived from the actions, and use the page$ observable to derive the list of names from an API call.

Something like `useReducer`

One of the nice aspects of the React built-in hook useReducer is that you can define the reducer outside of the component. You can test the reducer function independently, and you know when you pass it to useReducer React will just update the state and re-render the component automatically.

Let's change our useObservable hook to have the same qualities.

To achieve this, we will alter our useObservable hook to take a function instead. The function passed to useObservable will receive an Observable of actions (the actions we dispatch from the component) as an argument, and will be expected to return an Observable of our new state. We’ll model the API for our custom hook afteruseReducer(), so it will return a tuple of

[state, dispatch].

This way, we can leave it up to the developer how they want to respond to the dispatched actions and how it will affect the state.

Something like this:



useObservable((action$) => {
  // let the developer decide how the action$ Observable affects the state
  actions$.pipe(/* … */);
  // returns an observable that emits the new state
  return newState$;
});

So to implement our new useObservable() custom hook we will:

take a callback function fn as an argument;
create an RxJS Subject as our action$ observable;
create a dispatch function that passes it's argument to action.next();
create a state$ Observable by calling the fn callback and passing the action$ as an argument
pull the state out of the state$ observable using the same useState/useEffect technique as before
return the new state and the dispatch function as a [state, dispatch] tuple

With that we end up with something like this:



const useObservable = (callback) => {
  // create the action$ observable only 1 time
  const action$ = useRef(new Subject()).current;
  // the dipatch function is memoized with useCallback()
  const dispatch = useCallback((v) => action$.next(v), [action$]);
  // store the callback on a ref, ignoring any new callback values
  const fn = useRef(callback).current;

  const [state, setState] = useState();
  useEffect(() => {
    // use the callback to create the new state$ observable
    const state$ = fn(action$);

    const sub = state$.subscribe(setState);
    return () => sub.unsubscribe();
  }, [fn, action$]);

  return [state, dispatch];
};

This looks a little like useReducer now, except that while useReducer is limited to synchronous updates to state, our useObservable can update state over time. Also, our useObservable is a safe async-hook, because it unsubscribes on clean-up, so you don’t have to worry about updating a components state after it has been unmounted.

Updating the example

Now, with that in place, we can define a getUserNames() function that follows our expected useObservable interface. Our getUserNames() function can be separate, isolated from our component. We can test it independently and, in theory, use the same functionality in different components. We'll extract the name fetching functionality into its own file and export the function getUserNames.



import { map, startWith, scan, switchMap } from "rxjs/operators";
import { ajax } from "rxjs/ajax";

const api = `https://randomuser.me/api/?results=5&seed=rx-react&nat=us&inc=name&noinfo`;
const getName = (user) => `${user.name.first} ${user.name.last}`;

export const getUserNames = (action$) => {
  const actionMap = {
    forward: +1,
    back: -1,
  };

  const page$ = action$.pipe(
    scan((page, action) => page + actionMap[action], 1),
    startWith(1)
  );

  return page$.pipe(
    switchMap((page) => ajax.getJSON(`${api}&page=${page}`)),
    map(({ results }) => results.map(getName))
  );
};

Then our component would import getUserNames and along with our new useObservable and look something like this:



function App() {
  const [names, dispatch] = useObservable(getUserNames);

  return (
    <div className="App">
      <h1>RxJS with React</h1>
      <List items={names} />
      <button onClick={() => dispatch("back")}>⇦</button>
      <button onClick={() => dispatch("forward")}>⇨</button>
    </div>
  );
}

Here is the example in full:

I think this is a really nice pattern: it is obvious what the component does, the presentation is decoupled from how the data is actually retrieved, it follows the flux pattern, and generally aligns nicely with React model of component state and side effects.

This is really just scratching the surface though, our useObservable hook could be improved in many ways, including exposing the current state to the callback function, using memoization and other techniques to improve the performance, and offering some way to allow component props/state to be exposed to the callback function as a stream of props.

If you'd like to see a more robust implementation of these ideas, you can check out my use-epic library on GitHub which follows a very similar pattern.

BigAB / use-epic

Use RxJS Epics as state management for your React Components

There is so much more that could be done when mixing React with RxJS: Animations, real-time updates, entity stores... the list goes on and on. If you'd be interested in any of those topics, let me know in the comments.

RxJS with React

Adam L Barrett — Thu, 10 Oct 2019 23:49:40 +0000

RxJS and React go together like chocolate and peanut butter: great individually but they become something incredible when put together.

A quick search on npm will find a slew of hooks to connect RxJS Observables to React components, but let’s start at the beginning, because RxJS and React fit very well together "as is" because they follow the same philosophy and have very compatible APIs.

A quick aside about Why RxJS

2019 has been the year of RxJS, blowing up across the web-dev community with events like rxjs.live and ng-conf. More and more developers are finding out that RxJS is awesome and it is totally worth climbing your way through the somewhat steep learning curve.

Angular devs have been using RxJS for a while now. A quick search will find vue-rx, ember-rx, and even Svelte can use RxJS Observables as stores by default. When you learn RxJS you are learning a highly portable skill that can be used across frameworks. The concepts of Rx can actually be used across languages and platforms.

RxJS is a mature, battle hardened library for dealing with events and data flow. It is definitely going to be valuable to familiarize yourself with how it works.

Let’s start with a simple example:

We’ve got a simple List component here that just lists the strings it is given:

const source = ['Adam', 'Brian', 'Christine'];

function App() {
  const [names, setNames] = useState(source);

  return (
    <div className="App">
      <h1>RxJS with React</h1>

      <List items={names} />
    </div>
  );
}

(follow along on CodeSandbox!)

Now, let’s pull those values from an RxJS Observable.

Let’s start by creating an Observable with the RxJS of() function.

We'll need to:

add rxjs as a dependency (npm i rxjs, yarn add rxjs or however you need to if you're not using CodeSandbox)
import of from rxjs

Then let's create an Observable called names$, whose value is the source array:

import { of } from 'rxjs';

const source = ['Adam', 'Brian', 'Christine'];
const names$ = of(source);

FYI: I will be following the convention of naming an Observable variable with a \$ suffix (aka Finnish Notation), which is completely optional but I think it may help for clarity while learning.

Now what we want to do is synchronize the component state with the state from the Observable. This would be considered a side-effect of the React function component App, so we are going to use the useEffect() hook, which we can import from react.

Inside the useEffect() callback we will:

subscribe to the names$ Observable with the subscribe() method, passing our "state setter function" setNames as the observer argument
capture the subscription returned from observable.subscribe()
return a clean-up function that calls the subscriptions .unsubscribe() method

function App() {
  const [names, setNames] = useState();

  useEffect(() => {
    const subscription = names$.subscribe(setNames);
    return () => subscription.unsubscribe();
  });

  return (
    <div className="App">
      <h1>RxJS with React</h1>
      <List items={names} />
    </div>
  );
}

Which at this point should look something like this:

The concepts and APIs in RxJS and React are very compatible: the way useEffect aligns with an RxJS subscription and how the clean-up call is a perfect time to unsubscribe. You’ll see a lot more of that "symbiosis" as we go on.

An aside about `useEffect`

When using useEffect to synchronize component state to some "outer" state, you must decide what state you want to sync with.

All state
No state
Some select pieces of state

This is represented in the deps array, which is the second argument passed to useEffect.

To use an quote from Ryan Florence:

// Detect dark theme var iframe = document.getElementById('tweet-1125041041063665666-773'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1125041041063665666&theme=dark" }

useEffect(fn) // all state
useEffect(fn, []) // no state
useEffect(fn, [these, states])

So, in this instance we don't have any props or other state to sync with: we just want our names array to be whatever is the current value of our Observable. We just want to update our component state whenever the Observables value changes, so we’ll go with No State and throw in an empty array [] as the second argument.

useEffect(() => {
  const subscription = names$.subscribe(setNames);
  return () => subscription.unsubscribe();
}, []);

Creating a custom hook

It looks like we'll be using this pattern a lot:

subscribing to an Observable in useEffect
setting the state on any changes
unsubscribing in the clean-up function

...so let’s extract that behaviour into a custom hook called useObservable.

const useObservable = observable => {
  const [state, setState] = useState();

  useEffect(() => {
    const sub = observable.subscribe(setState);
    return () => sub.unsubscribe();
  }, [observable]);

  return state;
};

Our useObservable hook takes an Observable and returns the last emitted value of that Observable, while causing a re-render on changes by calling setState.

Note that our state is initialized as undefined until some value is emitted in the Observable. We'll use that later, but for now, make sure the components can handle when the state is undefined.

So we should have something like this now:

Of course, we could, and probably should, have useObservable() defined as an export from a module in its own file because it is shareable across components and maybe even across apps. But for our simple example today, we'll just keep everything in one file.

Adding some asynchronicity

So we’ve got this list of names showing now, but this is all very boring so far, so let’s do something a little more Asynchronous.

Let’s import interval from rxjs and the map operator from rxjs/operators. Then, let's use them to create on Observable that only adds a name to the list every second.

import { interval } from 'rxjs';
import { map } from 'rxjs/operators';

const source = ['Adam', 'Brian', 'Christine'];
const names$ = interval(1000).pipe(map(i => source.slice(0, i + 1)));

Neat. So we can see our list appearing one at a time. Sort of useless, but off to a good start. 😄

Fetching some data

Instead of our source array, let’s fetch the list of names from an API.

The API endpoint we’ll be using comes from randomuser.me, which is a nice service for just getting some made up user data.

We’ll add these 2 helper variables, api and getName which will allow us to fetch 5 users at a time and the function will help extract the name from the user data randomuser.me provides.

const api = `https://randomuser.me/api/?results=5&seed=rx-react&nat=us&inc=name&noinfo`;
const getName = user => `${user.name.first} ${user.name.last}`;

RxJS has some great utility functions for fetching data such as fromFetch and webSocket, but since we are just getting some JSON from an ajax request, we’ll be using the RxJS ajax.getJSON method from the rxjs/ajax module.

import { ajax } from 'rxjs/ajax';

const names$ = ajax
  .getJSON(api)
  .pipe(map(({ results: users }) => users.map(getName)));

This will fetch the first 5 users from the API and map over the array to extract the name from the name.first and name.last property on each user. Now our component is rendering the 5 names from the API, yay!

It's interesting to note here, that since we moved our code into a custom hook, we haven't changed the component code at all. When you decouple the data from the display of the component like this, you get certain advantages. For example, we could hook up our Observable to a websocket for live data updates, or even do polling in a web-worker, but the component doesn't need to change, it is happy rendering whatever data it is given and the implementation of how the data is retrieved is isolated from the display on the page.

Aside about RxJS Ajax

One of the great benefits of using the RxJS ajax module (as well as fromFetch), is that request cancellation is built right in.

Because our useObservable hook unsubscribes from the Observable in the clean-up function, if our component was ever “unmounted” while an ajax request was in flight, the ajax request would be cancelled and the setState would never be called. It is a great memory safe feature built in without needing any extra effort. RxJS and React working great together, out of the box, again.

Actions

So now we have this great custom hook for reading state values off an Observable. Those values can come from anywhere, asynchronously, into our component, and that is pretty good, but React is all about Data Down and Actions Up (DDAU). We’ve really only got the data half of that covered right now, what about the actions?

In the next instalment of the series we'll explore Actions, how we model our RxJS integration after the built-in useReducer hook, and much much more.

If you have any questions, feel free to post in the comments, or you can join our Bitovi community Slack at https://bitovi.com/community/slack, and ask me directly. There are lots of other JavaScript experts there too, and it is a great place to ask questions or get some help.

DEV Community: Adam L Barrett

A Tale of Two Apps

#1: the Interface Model application

#2: the Distributed Model application

So what’s the problem...?

RxJS with React: Actions and Subjects

Actions

Subjects

Something like useReducer

Updating the example

BigAB / use-epic

Use RxJS Epics as state management for your React Components

RxJS with React

A quick aside about Why RxJS

An aside about useEffect

Creating a custom hook

Adding some asynchronicity

Fetching some data

Aside about RxJS Ajax

Actions

Something like `useReducer`

An aside about `useEffect`