DEV Community: Jérémy Bardon

Unexpected issue during concatLatestFrom migration

Jérémy Bardon — Wed, 12 Jul 2023 12:10:48 +0000

When using NgRx as a state manager for Angular, you end up using withLatestFrom RxJS operator. It's often in effects to retrieve the current state from selectors.

NgRx v11 introduced concatLatestFrom operator as a drop-in replacement for withLatestFrom. The migration should be seamless but sneaky issues can appear with withLatestFrom misuses.

Identify withLatestFrom misuses

This RxJS operator shines when you need to retrieve an observable value (aka. selector) within an effect.

// Emits 0, 1, 2 and 3 with a 2s interval
selectCount$ = timer(0, 2_000).pipe(take(4));

effect$ = this.actions$.pipe(
  withLatestFrom(selectCount$),
  tap(([action, count]) => console.log(action, count))
);

In this example, the selector value is available in the effect. action$ is the main observable while selectCount$ is a "side observable" running separately. Having updates on the selector won't trigger the effect.

As soon as the effect is active, withLatestFrom side process kicks in watching for given observables changes. It keeps track of the last known value to make it synchronously available by the main observable.

Curious about what "side process" means? Checkout RxJS source code, it does subscribe outside of the main observable scope

Let's look at another example but replace the selector with an HTTP request. The idea is to only trigger the request once and access its value.

// Emulates http request which don't emit immediately
httpRequest$ = of('result').pipe(delay(2_000));

effect$ = this.actions$.pipe(
  withLatestFrom(httpRequest$),
  tap(([action, result]) => console.log(action, result))
);

The above example works most of the time but can fail at some point. What happens if the effect receives an action before the request ends?

Nothing, the operator acts as a filter and ignores the action. withLatestFrom can't provide the last value since the request didn't emit any value yet.

Don't use withLatestFrom on observables without an initial value. Stick with selectors and be careful with other observables.

This issue is hard to spot since it doesn't happen often. withLatestFrom watch process starts at effect class instantiation time. Usually, there is enough time for the request to complete before the effect receives an action.

What's the difference with concatLatestFrom?

concatLatestFrom is an RxJS operator provided by NgRx to address the effect's specific use cases. NgRx v15 adds an
official ESLint rule which encourages migration.

effect$ = this.actions$.pipe(
  withLatestFrom(selectItem(action.id)),
);

This snippet doesn't work. The intent is to retrieve an item from the store based on the incoming id.

withLatestFrom can't help us in this case. The selector starts once at effect class instantiation time. At this moment, the effect didn't receive any action yet thus the item id isn't reachable.

effect$ = this.actions$.pipe(
  concatLatestFrom(action => selectItem(action.id)),
);

Did you notice the parameter changed from an observable to an arrow function? It's important to postpone the observable watch process.

The selector won't start at effect class instantiation time. Instead, the effect can start the selector on demand when it receives an action containing an id. It does so by executing the arrow function returning the selector to watch.

This example works fine, it looks safe to apply the new ESLint rule. Let's replace the existing withLatestFrom with its more flexible counterpart.

httpRequest$ = of('result').pipe(delay(2_000));

effect$ = this.actions$.pipe(
  concatLatestFrom(() => httpRequest$)
);

Unfortunately, this small change broke the effect. It seems concatLatestFrom ignores the action. Let's check this operator source code to figure out what happens.

It leverages withLatestFrom which makes sense. We observed this operator might ignore actions under some conditions, right?

The request starts once the effect receives an action. At this point, the main observable tries to read the request value synchronously. It fails since the request didn't emit the response yet hence no "latest" value is available.

Fix combineLatestFrom misuses

It's bad idea to use LatestFrom operators with observables without initial value (such as http requests). It means the observable to watch must emit without delay.

Imagine an effect which needs to retrieve a feature flag from an API before running another request based on the action id.

effect$ = this.actions$.pipe(
  concatLatestFrom(() => featureFlagRequest$),
  switchMap(([action, flag]) => {
    if (!flag) {
       return legacyRequest(action.id);
    }
    return request(action.id);
  })
);

Thanks to your experience, you can spot the misuse of concatLatestFrom watching an HTTP request.

Let's see how we can refactor this piece of code and keep the desired behaviour. The intuitive solution is to move the feature flag request into the switchMap.

effect$ = this.actions$.pipe(
  switchMap(([action, flag]) => featureFlagRequest$.pipe(
    switchMap(flag => {
      if (!flag) {
        return legacyRequest(action.id);
      }
      return request(action.id);
    })
  ))
);

Having both requests together adds nesting and result in complex RxJS code.

The request also runs on each action and not once slowing down the reactivity. It's good when having an up-to-date value is important but could have caching otherwise.

What about replacing concatLatestFrom with an observable composition operator?

effect$ = this.actions$.pipe(
  switchMap(action => featureFlagRequest$.pipe(
    map(flag => [action, flag])
  ),
  switchMap(([action, flag]) => {
    if (!flag) {
       return legacyRequest(action.id);
    }
    return request(action.id);
  })
);

The feature flag request and the second request are in different code blocks. It looks like concatLatestFrom approach but switchMap waits for the request to complete.

The extra map operator is a downside. It could not scale with many requests. Another way to improve this is to leverage the zip operator.

effect$ = this.actions$.pipe(
  switchMap(action => zip(
    of(action),
    featureFlagRequest$, // Can safely add more requests here
  )),
  switchMap(([action, flag]) => {
    if (!flag) {
       return legacyRequest(action.id);
    }
    return request(action.id);
  })
);

The most scalable approach is quite verbose and complex. Prefer the previous solution for simpler use cases with a single request.

One last solution is to keep withLatestFrom for such cases while having its downsides in mind. Better avoid having both operators in your codebase to not confuse other developers.

Wrapping up

Using concatLatestForm as suggested by ESLint rules is a nice idea. It helps when selectors needs to access action details but also ease mocking in unit tests.

Pay attention to the watched observables, it should emit without delay. If not, the operator ignores the action whereas it might work with withLatestFrom.

Watch-out for withLatestFrom misusages during the migration and consider using switchMap instead. Listening selectors is safe but other observables such as HTTP request are not. Check out my Stackblitz playground to perform your tests.

Thanks for reading!

A quick guide to learn React and how its Virtual DOM works

Jérémy Bardon — Tue, 06 Feb 2018 00:00:00 +0000

Picture by @simonmigaj from Unsplash

Do you want to learn React without crawling the documentation (well written by the way)? You clicked on the right article.

We will learn how to run React with a single HTML file and then expose ourselves to a first snippet.

By the end, you will be able to explain these concepts: props, functional component, JSX, and Virtual DOM.

The goal is to make a watch which displays hours and minutes. React offers to architect our code with components. Let’s create our watch component.

<!-- Skipping all HTML5 boilerplate -->
<script src="https://unpkg.com/react@16.2.0/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom@16.2.0/umd/react-dom.development.js"></script>

<!-- For JSX support (with babel) -->
<script src="https://unpkg.com/babel-standalone@6.24.2/babel.min.js" charset="utf-8"></script> 

<div id="app"></div> <!-- React mounting point-->

<script type="text/babel">
  class Watch extends React.Component {
    render() {
      return <div>{this.props.hours}:{this.props.minutes}</div>;
    }
  }

  ReactDOM.render(<Watch hours="9" minutes="15"/>, document.getElementById('app'));
</script>

Ignore HTML boilerplate and script imports for dependencies (with unpkg, see React example). The few remaining lines are actually React code.

First, define the Watch component and its template. Then mount React into the DOM and ask to render a watch.

Inject data into the component

Our watch is quite stupid, it displays the hours and minutes we provided to it.

You can try to play around and change the value for those properties (called props in React). It will always display what you asked for even if it’s not numbers.

This kind of React component with only a render function are functional component. They have a more concise syntax compared to classes.

const Watch = (props) =>
  <div>{props.hours}:{props.minutes}</div>;

ReactDOM.render(<Watch hours="Hello" minutes="World"/>, document.getElementById('app'));

Props are only data passed to a component, generally by a surrounding component. The component uses props for business logic and rendering.

But as soon as props do not belong to the component they are immutable. Thus, the component which provided the props is the only piece of code able to update props values.

Using props is pretty straightforward. Create a DOM node with your component name as the tag name. Then give it attributes named after props. Then the props will be available through this.props in the component.

What about unquoted HTML ?

I was sure you will notice the unquoted HTML returned by the render function. This code is using JSX language, it’s a shorthand syntax to define HTML template in React components.

// Equivalent to JSX: <Watch hours="9" minutes="15"/>
React.createElement(Watch, {'hours': '9', 'minutes': '15'});

Now you may want to avoid JSX to define the component’s template. Actually, JSX looks like syntactic sugar.

Take a look at the following snippet which shows both JSX and React syntax to build your opinion.

// Using JS with React.createElement
React.createElement('form', null, 
  React.createElement('div', {'className': 'form-group'},
    React.createElement('label', {'htmlFor': 'email'}, 'Email address'),
    React.createElement('input', {'type': 'email', 'id': 'email', 'className': 'form-control'}),
  ),
  React.createElement('button', {'type': 'submit', 'className': 'btn btn-primary'}, 'Submit')
)

// Using JSX
<form>
  <div className="form-group">
    <label htmlFor="email">Email address</label>
    <input type="email" id="email" className="form-control"/>
  </div>
  <button type="submit" className="btn btn-primary">Submit</button>
</form>

Going further with the Virtual DOM

This last part is more complicated but very interesting. It will help you to understand how React is working under the hood.

Updating elements on a webpage (a node in the DOM tree) involves using the DOM API. It will repaint the page but it can be slow (see this article for why).

Many frameworks such as React and Vue.js get around this problem. They come up with a solution called the Virtual DOM.

{
   "type":"div",
   "props":{ "className":"form-group" },
   "children":[
     {
       "type":"label",
       "props":{ "htmlFor":"email" },
       "children":[ "Email address"]
     },
     {
       "type":"input",
       "props":{ "type":"email", "id":"email", "className":"form-control"},
       "children":[]
     }
  ]
}

The idea is simple. Reading and updating the DOM tree is very expensive. So make as few changes as possible and update as few nodes as possible.

Reducing calls to DOM API involves keeping DOM tree representation in memory. Since we are talking about JavaScript frameworks, choosing JSON sounds legitimate.

This approach immediately reflects changes in the Virtual DOM.

Besides, it gathers a few updates to apply later on the Real DOM at once (to avoid performance issues).

Do you remember React.createElement ? Actually, this function (called directly or through JSX) creates a new node in the Virtual DOM.

// React.createElement naive implementation (using ES6 features)
function createElement(type, props, ...children) {
  return { type, props, children };
}

To apply updates, the Virtual DOM core feature comes into play, the reconciliation algorithm.

Its job is to come up with the most optimized solution to resolve the difference between previous and current Virtual DOM state.

And then apply the new Virtual DOM to the real DOM.