DEV Community: Mike Pearson

10 Tips for Scaling Signals

Mike Pearson — Thu, 07 Sep 2023 09:52:24 +0000

After converting ~1800 lines of code to signals, I have learned a few important lessons. Signals scale very well if you follow the tips in this article.

1. `computed` can be inefficient by default

Edit: In the finalized version of signals, computed no longer runs excessively! Skip to tip #2

How many times will this log?

export class Component {
  e = signal({ f: { f: 'f' } });
  f = computed(() => this.e().f);

  constructor() {
    effect(() => {
      console.log(this.f());
    });
    setTimeout(() => {
      this.child.c.update((e) => ({ ...e }));
    }, 1000)
  }
}

Well, the top-level object changes, but the value returned from the computed() will be the exact same object reference { f: 'f' } both times.

But this actually logs twice. This is different from createMemo from SolidJS or createSelector from NgRx, and I predict a lot of people will be surprised by this behavior when they encounter it.

The reason for this behavior is that the Angular team doesn't want to have downstream code miss updates in case the object or array is mutated without getting a new reference. There is a mutate method on signals, after all.

But there's a way to opt-in to more efficient behavior: Pass in equal: (a, b) => a === b.

This is the only behavior I want. So I wrapped computed in my own function so I don't have to define that equal function everywhere:

import { computed } from '@angular/core';

export function memo<T>(fn: () => T) {
  return computed(fn, { equal: (a, b) => a === b });
}

I suggest exporting this from an Nx lib, or giving the file a TypeScript path alias.

StackBlitz

2. Reuse logic, not state

The old implementation managed form state in NgRx, which is a perfectly reasonable thing to do, as I explained in this article.

However, unfortunately, most NgRx developers have never read my article on how to avoid shooting yourself in the foot by coupling state logic with actual state. But there are a lot of reusable forms patterns, so the previous implementation centralized all form state in a single reducer. This is inconvenient in a few ways, but no page contains multiple forms, so it's not a disaster.

Still, I wanted to colocate forms with relevant state. I thought of 2 ways of doing this: Reusable functions, or a base class. Generally I like avoiding inheritance, but I found defining a base class the simplest strategy in this case.

3. Signal update timing can break e2e tests

How many times do you think this will log?

export class CountComponent {
  state = signal(5);
  constructor() {
    effect(() => console.log(this.state()));
    this.state.set(6);
    this.state.set(7);
  }
}

Answer: Twice! 5 and 7 will be logged.

So if you have some code that results in a state change in an e2e test and expect the result to immediately be reflected, your test will break. In this app, the form state was not updated immediately, so I had to add a short wait before submitting the form. (One field was optional, so I couldn't simply wait for the submit button to become enabled.)

4. The auto-signal pattern is awesome

After rewriting 1856 lines of NgRx code to 1323 lines using the auto-signal pattern, I like it very much. It is very convenient to able to share signals in a way that doesn't block subscription information in RxJS streams. Both NgRx and toSignal block RxJS subscriptions, so from the existing NgRx implementation I was able to remove all of the manual initialization, resetting and refetching code.

Look at all the code that became 100% unnecessary when RxJS was free to handle data dependencies:

// apps/conduit/src/app/app.component.ts
  constructor(
    private readonly store: Store,
    ...
  ) {}

  ngOnInit() {
    ...
        take(1),
        ...
      .subscribe(() =>
        this.store.dispatch(authActions.getUser()),
      );
  }

// libs/articles/data-access/src/lib/+state/article-list/article-list.effects.ts
export const loadArticle$ = createEffect(
  (
    actions$ = inject(Actions),
    ...
  ) => {
    return actions$.pipe(
      ofType(articleActions.loadArticle),
      ...
    );
  },
  { functional: true },
);
...
export const loadComments$ = createEffect(
  (
    actions$ = inject(Actions),
    ...
  ) => {
    return actions$.pipe(
      ofType(articleActions.loadComments),
      ...
    );
  },
  { functional: true },
);

// libs/articles/data-access/src/lib/+state/article-list/article-list.effects.ts
export const setListPage$ = createEffect(
  (actions$ = inject(Actions)) => {
    return actions$.pipe(
      ofType(articleListActions.setListPage),
      map(() => articleListActions.loadArticles()),
    );
  },
  { functional: true },
);

export const setListTag$ = createEffect(
  (actions$ = inject(Actions)) => {
    return actions$.pipe(
      ofType(articleListActions.setListConfig),
      map(() => articleListActions.loadArticles()),
    );
  },
  { functional: true },
);

export const loadArticles$ = createEffect(
  (
    actions$ = inject(Actions),
    store = inject(Store),
    ...
  ) => {
    return actions$.pipe(
      ofType(articleListActions.loadArticles),
      ...
    );
  },
  { functional: true },
);

// libs/articles/feature-article/src/lib/article-guard.service.ts
    this.store.dispatch(articleActions.loadArticle({ slug }));
    ...
      tap(() =>
        this.store.dispatch(
          articleActions.loadComments({ slug }),
        ),
      ),

// libs/articles/feature-article/src/lib/article.component.ts
  ngOnDestroy() {
    this.store.dispatch(articleActions.initializeArticle());
  }

// libs/articles/feature-article-edit/src/lib/article-edit.component.ts
  ngOnDestroy() {
    this.store.dispatch(formsActions.initializeForm());
  }

// libs/articles/feature-article-edit/src/lib/article-edit.routes.ts
        resolve: { articleEditResolver },

// libs/articles/feature-article-edit/src/lib/resolvers/article-edit-resolver.ts
export const articleEditResolver: ResolveFn<boolean> = (
  route: ActivatedRouteSnapshot,
) => {
  const slug = route.params['slug'];
  const store = inject(Store);

  if (slug) {
    store.dispatch(articleActions.loadArticle({ slug }));
  }

  return of(true);
};

// libs/auth/data-access/src/lib/+state/auth.effects.ts
export const getUser$ = createEffect(
  (
    actions$ = inject(Actions),
    ...
  ) => {
    return actions$.pipe(
      ofType(authActions.getUser),
      ...
    );
  },
  { functional: true },
);

// libs/auth/feature-auth/src/lib/login/login.component.ts
  ngOnDestroy() {
    this.store.dispatch(formsActions.initializeForm());
  }

// libs/auth/feature-auth/src/lib/register/register.component.ts
  ngOnDestroy() {
    this.store.dispatch(formsActions.initializeForm());
  }

// libs/home/src/lib/home.component.ts
  ngOnInit() {
        ...
        this.getArticles();
        ...
  }

// libs/home/src/lib/home.store.ts
  ngrxOnStateInit() {
    this.getTags();
  }

// libs/profile/data-access/src/lib/+state/profile.effects.ts
export const getProfile$ = createEffect(
  (
    actions$ = inject(Actions),
    ...
  ) => {
    return actions$.pipe(
      ofType(profileActions.loadProfile),
      groupBy((action) => action.id),
      ...
    );
  },
  { functional: true },
);

// libs/profile/data-access/src/lib/resolvers/profile-articles-resolver.ts

export const profileArticlesResolver: ResolveFn<boolean> = (
  route: ActivatedRouteSnapshot,
) => {
  const username = route.params['username'];
  const store = inject(Store);

  store.dispatch(
    articleListActions.setListConfig({
      config: {
        ...articleListInitialState.listConfig,
        filters: {
          ...articleListInitialState.listConfig.filters,
          author: username,
        },
      },
    }),
  );

  return of(true);
};

// libs/profile/data-access/src/lib/resolvers/profile-favorites-resolver.ts
export const profileFavoritesResolver: ResolveFn<boolean> = (
  route: ActivatedRouteSnapshot,
) => {
  const username = route?.parent?.params['username'];
  const store = inject(Store);

  store.dispatch(
    articleListActions.setListConfig({
      config: {
        ...articleListInitialState.listConfig,
        filters: {
          ...articleListInitialState.listConfig.filters,
          favorited: username,
        },
      },
    }),
  );

  return of(true);
};

// libs/profile/feature-profile/src/lib/profile.routes.ts
        resolve: { profileArticlesResolver },
...
        resolve: { profileFavoritesResolver },

// libs/profile/data-access/src/lib/resolvers/profile-resolver.ts
  store.dispatch(profileActions.loadProfile({ id: username }));

// libs/settings/feature-settings/src/lib/settings.component.ts
@UntilDestroy()
...
  ngOnInit() {
    this.store.dispatch(authActions.getUser());
    ...
    this.store
      .select(selectUser)
      .pipe(untilDestroyed(this))
      .subscribe((user) =>
        this.store.dispatch(
          formsActions.setData({ data: user }),
        ),
      );
  }

// libs/settings/feature-settings/src/lib/settings.store.ts
          map(() => this.store.dispatch(authActions.getUser())),

That is a lot of code.

It's a lot of potential bugs, too. For example: Why didn't settings.component.ts have an ngOnDestroy to reset the form state like the other form components did? Maybe that was a bug. Regardless, RxJS takes care of that stuff now.

Maintaining this logic is harder than learning the auto-signal pattern.

5. The reactive variation of auto-signals is cleaner

There are 2 ways to implement state changes with auto-signals:

Method
Subject

1. Method

export class CountStateService {
  // State
  state = signal(0);

  // Non-UI events and effects
  serverCount$ = inject(CountService).fetch();

  // Auto-signal connection
  connection$ = connectSource(this.state, this.serverCount$);

  // State change methods
  increment() {
    this.state.update(n => n + 1);
  }
}

This is most similar to what people are used to, but it encourages more of an imperative/non-unidirectional style of state management, so I prefer using subjects.

2. Subject

export class CountStateService {
  // State
  state = signal(0);

  // All events/effects, including server and UI
  serverCount$ = inject(CountService).fetch();
  increment$ = new Subject<void>();

  // New state; similar to Redux/NgRx reducer
  newState$ = merge(
    this.serverCount$,
    this.increment$.pipe(map(() => this.state() + 1))
  )

  // Auto-signal connection
  connection$ = connectSource(this.state, this.newState$);
}

This has many of the same advantages as Redux/NgRx:

All logic that controls this state (other than the initial state) is centralized in the single declaration of newState$, which helps avoid bugs that arise from developers forgetting important context
Grouping relevant logic makes debugging easier
Event sources are not burdened with downstream concerns

Imagine we had multiple counts, and a button to reset all of them. With methods, we would need another method to call the other increment methods:

export class CountComponent {
  count1StateService = injectAutoSignal(Count1StateService);
  count2StateService = injectAutoSignal(Count2StateService);

  resetAll() {
    this.count1StateService.reset();
    this.count2StateService.reset();
  }
}

Or we could export a subject:

export const resetAll = new Subject<void>();

And import that into each state service, and react to its events inside the declaration newState$ in each service. This is just like an NgRx action. Using it in the component is easy:

export class CountComponent {
  count1StateService = injectAutoSignal(Count1StateService);
  count2StateService = injectAutoSignal(Count2StateService);
  resetAll$ = resetAll$;
}

<button (click)="resetAll$.next()">Reset All</button>

Here's the difference in data flow between these approaches:

The subject version might look more complicated, but it's actually less code, and that code is more appropriately colocated.

Don't follow the dogmatic tradition of creating an event handler for every event. It is entirely unnecessary. If you need flexibility, it can be downstream from the subject. The subject perfectly represents that something happened; it is a perfect abstraction, which means it acts as a simple, self-contained block that can be easily built upon by any future code.

6. State changes and events should be separate

Originally I wrote the form state base class like this:

  newData$ = new Subject<any>();
  newDataChanges$ = this.newData$.pipe(
    map((data) => ({ ...this.state(), data })),
  );

  dataUpdate$ = new Subject<any>();
  dataUpdateChanges$ = this.dataUpdate$.pipe(
    map((data) => ({
      ...this.state(),
      data: { ...this.data(), ...data, touched: true },
    })),
  );

  reset$ = new Subject<void>();
  resetChanges$ = this.reset$.pipe(map(() => formsInitialState));

  newState$ = merge(
    this.newDataChanges$,
    this.dataUpdateChanges$,
    this.resetChanges$,
  );

But I came to see the separation between events and state as more primary than the separation between individual event/state change pairs. The events themselves don't have an opinion on how state should react, and may even be used in other services to cause unrelated state to react, so it felt better to group them like this:

  newData$ = new Subject<any>();
  dataUpdate$ = new Subject<any>();
  reset$ = new Subject<void>();

  newState$ = merge(
    this.newData$.pipe(
      map((data) => ({ ...this.state(), data })),
    ),
    this.dataUpdate$.pipe(
      map((data) => ({
        ...this.state(),
        data: { ...this.data(), ...data, touched: true },
      })),
    ),
    this.reset$.pipe(map(() => initialFormState)),
  );

Once I made this change, I also noticed that newState$ resembled an NgRx reducer:

export const formReducer = createReducer(
  initialFormState,
  on(FormActions.newData, (data) => ({ ...this.state(), data })),
  on(FormActions.dataUpdate, (data) => ({
    ...this.state(),
    data: { ...this.data(), ...data, touched: true },
  })),
  on(FormActions.reset, () => initialFormState),
);

Basically, it felt more natural to me to group the state logic together. Also, when I have a hard time choosing between alternatives, I prefer the more succinct choice.

7. Base `connection$` observables should be `Observable<any>`

If you want to share state change logic by extending a base auto-signal class, TypeScript will infer the type of connection$ and prevent you from changing it in a child class. We don't want this because it doesn't matter what kind of values connection$ emits. So, we should just type it as Observable<any>:

this.connection$ = merge(
  this.connection$,
  connectSource(this.newState$),
) as Observable<any>;

8. Some HTTP utilities are useful

HTTP observables often emit different values for success vs error. States need to react differently to these events, so I found myself writing some code over-and-over again, and eventually made these reusable utilities instead:

export function filterSuccess<T>(
  source: RequestObservable<T>,
): Observable<T> {
  return source.pipe(
    filter(
      (result): result is T => !('errors' in (result as object)),
    ),
  );
}
export function filterError<T>(
  source: RequestObservable<T>,
): Observable<{ errors: {} }> {
  return source.pipe(
    filter(
      (result): result is { errors: {} } =>
        'errors' in (result as object),
    ),
  );
}

Here's an example of how I used these:

  articles$ = toObservable(this.listConfig).pipe(
    debounceTime(100),
    switchMap((config) => this.articlesService.query(config)),
    share(),
  );
  articlesSuccess$ = this.articles$.pipe(filterSuccess, share());
  articlesFailure$ = this.articles$.pipe(filterError, share());

  ...

  newState$ = merge(
    ...
    this.articlesSuccess$.pipe(
      map((result): ArticleListState => {
        // return new state
      }),
    ),
    this.articlesFailure$.pipe(
      map((): ArticleListState => {
        // return new state
      }),
    ),
    ...
  );

9. `resetOnRefCountZero` can smooth transitions

Route guards present an awkward challenge for reactive apps. Imagine an auto-signal connected to an HTTP observable like this:

export class NameStateService {
  state = signal('');

  nameFromServer$ = inject(NameService).fetch();

  connection$ = connectSource(this.state, this.nameFromServer$);
}

If we use nameFromServer$ directly in a route resolver, the signal won't ever get the data. We should use injectAutoSignal like this:

export function resolveName() {
  const state = injectAutoSignal(NameStateService).state;
  return toObservable(state).pipe(
    filter(s => s !== ''), // Wait for it to be defined
    take(1), // Resolvers need observables to complete
  );
}

But this observable completes before the route is loaded and any subscribers within the route have the opportunity to inject this auto-signal. This means there is a very short period of time where connection$ will have no subscribers. This triggers the finalize inside connection$, so state resets to ''.

Thankfully, RxJS gives us a way to prevent connection$ from completing for a period of time until new subscribers arrive. We can define connection$ like this instead:

  connection$ = connectSource(this.state, this.nameFromServer$).pipe(
    share({ resetOnRefCountZero: () => timer(1000) }),
  );

Our route will load much more quickly than 1000 ms, but I thought it might be nice to wait that long in case someone accidentally clicks away from the route and comes back quickly. If they come back within a second, the old state will be preserved.

UX Note: Route guards should be avoided. It isn't a great user experience to click a button or link and wonder if it's broken or needs to be clicked again. I would much rather see some instant feedback as the route loads, even if that means looking at a spinner until the data arrives. I would even prefer getting kicked out of a route than watching a motionless app while it decides if I should be allowed to view a route. So I think route guards should be avoided in general. But I'm sure there are specific scenarios where they are necessary.

10. Accessing route data in services is a pain

Services don't belong to routes. Components do. Services belong to injectors.

What if you inject a service inside a component? You would need to inject it into the route's root component, and it wouldn't be clear why it was there. It wouldn't be used in that specific component.

In my case, it was a route resolver that first needed the service. Route resolvers are not part of the route itself, but they get route data passed in directly. This doesn't help if the service is trying to inject it.

Previously, when I've had a service providedIn 'root' and wanted route data, I've just listened to router events and parsed the URL manually. It's usually not very hard, although I still hate it because it seems a little fragile. However, not even this option worked in this case, because when the resolver runs, the navigation events haven't been fired yet.

What I had to do was define a BehaviorSubject in the service for holding route data and imperatively set it from the resolver. Every time the route reloads, the resolver runs, so this will always be up-to-date. But having to write imperative code bothers me. When looking at the BehaviorSubject itself, there is no indication of where it gets its data from; you have to find all references to it and find where the resolver pushes data to it. But at least it worked.

Here's what it looked like:

export const profileResolver: ResolveFn<boolean> = (
  route: ActivatedRouteSnapshot,
) => {
  const profileStateService = inject(ProfileStateService);

  profileStateService.routeParam$.next(route.params['username']);
...

Bonus Tip: Type object literal returns

This tip doesn't just apply to signals or auto-signals, but when defining newState$ with object literals I noticed some dangerously forgiving TypeScript behavior. It was allowing not just extra properties like usual (usually harmless), but incorrect types of expected properties. So, instead of relying on inference in this case, I suggest typing return values whenever defining newState$ for nontrivial state, like this:

export class SomeStateService {
  ...
  newState$ = merge(
    // Explicitly type return as State
    this.increment$.pipe(map((): State => ({
      ...this.state(),
      count: this.count() + 1,
    }))),
  )
}

This will give you much more useful TypeScript errors than just typing newState$, like newState$: Observable<State> = .... Typing every single return type is repetitive, but the improved TS errors are worth it in my opinion.

Conclusion

I am having a lot of fun with RxJS + signals. As an Angular community, we are learning a lot together. And remember that signals are still in developer preview, so experiment with them and let the Angular team hear your feedback. I hope they change computed to memoize everything, regardless of type. And personally, I wish it was named memo, but maybe that's just me.

Thanks for reading!

Introducing the auto-signal pattern

Mike Pearson — Wed, 02 Aug 2023 08:21:51 +0000

YouTube

Signals are perfect for synchronous reactivity, and observables are perfect for asynchronous reactivity. They are complimentary, but also at odds with each other. In this article I will share a neat trick to get them to play well with each other.

The Problem

toSignal(source$) immediately subscribes to the source$ observable, and stays subscribed until it is destroyed. This is necessary because signals are expected to always contain a current value that can be read from at any time. However, it blocks the ability of RxJS streams to automatically

clean up
reset and re-fetch
cancel requests
defer work and requests

1. Automatic cleanup

Listening to data sources can be expensive. Firebase has different price levels depending on the number of simultaneous connections, and other data sources can cause memory leaks if not cleaned up. Apps that don't use RxJS effectively need manual cleanup code, which can easily be neglected in some scenarios.

If you need an event source on only some pages, observables can automatically clean up the connections or listeners when the user goes to other pages and all subscribers have unsubscribed.

But if you call toSignal in a shared service, the source observable will never clean up resources.

2. Reset and re-fetch

When you leave a page and come back later, seeing stale data there can be deceptive or even jarring. Apps that don't use RxJS effectively will have extra code that runs inside an OnDestroy to manually clear stale data. They also have to manually trigger a re-fetch.

Observables can automatically reset state when the user goes to other pages and all subscribers have unsubscribed, and automatically re-fetch data when the user returns to a page that needs it.

But if you call toSignal in a shared service, the source observable will never reset its state or re-fetch data:

3. Automatic cancel

When you leave a page, it becomes pointless and wasteful to continue fetching unnecessary data or creating expensive data sources. Without RxJS, it is up to developers to notice when certain data sources are large enough, or typical user connection speed is slow enough, that it noticeably deteriorates the user experience.

Observables can automatically cancel requests when the user goes to other pages and all subscribers have unsubscribed.

But if you call toSignal in a shared service, the source observable will continue on with unnecessary requests and download unnecessary data

4. Automatic defer

It is pointless and wasteful to fetch data or create expensive connections before they are necessary.

Observables can represent data sources but wait for subscribers instead of prematurely consuming them.

But if you call toSignal in a shared service, the source observable will consume the data source it represents as soon as that service is created:

Don't share signals?

If you want to share synchronously derived state, you either can't use signals, or you have to sacrifice automatic cleanup, resetting, refetching, cancellation and deferment. The more complex your application is, the more painful this tradeoff will be.

This is why, despite the huge benefits of signals, I have advised to never use signals in a shared service. It sucks to not have efficient derived state, but usually it sucks more to have lower code quality because RxJS can't automatically manage data dependencies.

Note: I'm really not asking for anything excessively luxurious here. These benefits are commonly achieved in React with hooks like useQuery. I believe Angular can have nice things too, if people want them.

Real-world example

One company I worked for had 2-3 routes using realtime data, but the users spent the majority of the time away from those routes, so it was important to close unused connections. The most complex feature required this series of asynchronous data dependencies:

Get Firebase token from server
Create Firebase connection
Listen to message data from Firebase
Use message data to fetch more details from server

RxJS automatically closed unused Firebase connections for us. We never worried about orchestrating when sibling routes might need the Firebase connection or not. We had a service providedIn: 'root' and the Firebase connections automatically closed when they were not needed by any component.

Realtime data is awesome for users, and RxJS makes it easy for developers. Once you get used to automatic cleanup, resetting, refetching, cancellation and deferment, you will never want to code any other way, even in simple apps. It is just too convenient to not have to use imperative duct tape everywhere.

The Solution

Rather than converting an observable to a signal with toSignal, we can keep the observables and signals separate, but build a connection between them that lasts exactly as long as we need it.

Let's say we have an observable of asynchronous data:



interval$ = interval(3000);

And we have a signal with synchronously derived state:



count = signal(0);
double = computed(() => this.count() * 2);

What we can do is make a function that creates a connection between interval$ and count, and we can represent this connection as an observable. When we subscribe to this observable, it will subscribe to interval$. When interval$ emits it will call count.set(value) with the value from the interval. It should do this only once, no matter how many subscribers it has, so we'll add a share() at the end. And we want it to reset to the initial state after all subscribers are gone, so we'll use a finalize for that. Also, we don't want self-completing observables to trigger this behavior, so we have to merge interval$ with NEVER to prevent the finalize from running too soon. Now this connection observable will only complete once all subscribers unsubscribe. Here's the implementation of the function that can create this connection observable:



import { WritableSignal } from '@angular/core';
import { Observable, tap, share, finalize, merge, NEVER } from 'rxjs';

/**
 * https://dev.to/mfp22/introducing-the-auto-signal-pattern-1a5h 
*/
export function connectSource<State>(
  state: WritableSignal<State>,
  source$: Observable<State>,
) {
  const initialState = state();
  return merge(source$, NEVER).pipe(
    tap(s => state.set(s)),
    finalize(() => state.set(initialState)),
    share(),
  );
}

And here's how to use it:



@Injectable({ providedIn: 'root' })
export class CountService {
  count = signal(0);
  double = computed(() => this.count() * 2);

  interval$ = interval(3000);

  connection$ = connectSource(this.count, this.interval$);
}

Now, whenever we want to use these count or double signals in a component, we need to make sure that connection$ has a subscription. We can create a function that does this automatically, by injecting a service, looking for a connection$ property and subscribing to it with takeUntilDestroy:



import { DestroyRef, inject, ProviderToken } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { Observable } from 'rxjs';

/**
 * https://dev.to/mfp22/introducing-the-auto-signal-pattern-1a5h 
*/
export function injectAutoSignal<
  T,
  Service extends { connection$: Observable<T> },
>(token: ProviderToken<Service>) {
  const service = inject(token);
  service.connection$.pipe(takeUntilDestroyed()).subscribe();
  return service;
}

And here's how to use that function:



@Component({
  // ...
  template: `
    <h1>Count is {{countService.count()}}</h1>
    <h1>Double is {{countService.double()}}</h1>
  `
})
export class CountComponent {
  countService = injectAutoSignal(CountService);
}

And we get almost everything we want: Derived state with signals, automatic cleanup, resetting, refetching and cancellation!

The one missing feature is automatic deferment. Our source observable is not completely deferred, because the component subscribes as soon as it is created and injects the service, rather than waiting for an actual subscription in the template. However, this is good enough for the vast majority of use cases.

If we want to use our derived state in another service, we just have to make sure we copy the connection$ observable to the new service so components can subscribe through the new service:



@Injectable({ providedIn: 'root' })
export class AnotherService {
  countService = inject(CountService);

  message = computed(() => `Count is ${this.countService.count()}`);

  connection$ = this.countService.connection$;
}

Definitely don't inject CountService using injectAutoSignal, because that would immediately subscribe to connection$, which would behave just like toSignal. Just use inject inside services.

You can also combine 2 connections using merge:



@Injectable({ providedIn: 'root' })

export class CountService1 extends CountService {}

@Injectable({ providedIn: 'root' })

export class CountService2 extends CountService {}

@Injectable({ providedIn: 'root' })

export class CombinedService {

  countService1 = inject(CountService1);

  countService2 = inject(CountService1);

combinedCount = computed(

    () => this.countService1.count() + this.countService2.count(),

  );

connection$ = merge(

    this.countService1.connection$,

    this.countService2.connection$,

  );

}

Conclusion

It looks like we have everything we want! We get the best of both worlds: Efficient synchronous reactivity with signals, and on-demand asynchronous reactivity from RxJS!

Hopefully this helps the Angular community write cleaner and safer code.

Please share this article with other Angular developers.

RxJS can save your codebase

Mike Pearson — Mon, 24 Jul 2023 06:42:37 +0000

YouTube

Sometimes RxJS is the perfect tool for the job. If you've used it for the wrong job, you might never want to touch it again. But if you remain open-minded towards it, it can sometimes save your codebase from exploding into overly complex spaghetti-code.

We've seen what happens when we use RxJS for synchronous reactivity. Now let's try to use signals to implement asynchronous behavior. We'll compare both RxJS and signal implementations of this dinosaur animation from the opening screen of the Angular Tetris app (See the demo here, but be careful... you might lose an hour):

Let's look at the implementations first, then analyze them.

Implementations

RxJS

export class LogoComponent {
  runningClass$ = timer(0, 100).pipe(
    startWith(0),
    takeWhile((t) => t < 40),
    map((t) => {
      const range = Math.ceil((t + 1) / 10);
      const side = range % 2 === 0 ? 'l' : 'r';
      const runningLegState = t % 2 === 1 ? 3 : 4;
      const legState = t === 39 ? 1 : runningLegState;
      return `${side}${legState}`;
    })
  );

  blinkingEyesClass$ = timer(0, 500).pipe(
    startWith(0),
    takeWhile((t) => t < 5),
    map((t) => `l${t % 2 === 1 ? 1 : 2}`)
  );

  restingClass$ = timer(5000).pipe(
    startWith(0),
    map(() => 'l2')
  );

  dragonClass$ = concat(
    this.runningClass$,
    this.blinkingEyesClass$,
    this.restingClass$
  ).pipe(repeat(Infinity));
}

Signals

type State = 'running' | 'blinking' | 'resting';

type RunningSide = 'r' | 'l';

interface RunningState {
  count: number;
  side: RunningSide;
}

// ...
export class LogoComponent {
  private runState = signal<RunningState>({ count: 1, side: 'r' });
  private blinkingCount = signal(1);
  private state = signal<State>('running');

  className = computed(() => {
    switch (this.state()) {
      case 'running': {
        return this.getRunningClassName();
      }
      default: {
        return this.getBlinkingClassName();
      }
    }
  });

  private intervalRef = null as null | number;
  private setTimeoutRef = null as null | number;

  constructor() {
    effect(
      () => {
        switch (this.state()) {
          case 'running': {
            if (!this.intervalRef) {
              this.intervalRef = this.startRunning();
            }

            const { count } = this.runState();

            if (count > 40) {
              this.clearInterval();
              this.state.set('blinking');
              this.runState.set({ count: 1, side: 'r' });
            }
            break;
          }
          case 'blinking': {
            if (!this.intervalRef) {
              this.intervalRef = this.startBlinking();
            }

            if (this.blinkingCount() >= 6) {
              this.clearInterval();
              this.state.set('resting');
              this.blinkingCount.set(1);
            }
            break;
          }
          case 'resting': {
            this.setTimeoutRef = window.setTimeout(() => {
              this.state.set('running');
            }, 5000);
            break;
          }
        }
      },
      { allowSignalWrites: true }
    );

    inject(DestroyRef).onDestroy(() => {
      if (this.intervalRef) {
        clearInterval(this.intervalRef);
      }

      if (this.setTimeoutRef) {
        clearTimeout(this.setTimeoutRef);
      }
    });
  }

  private startBlinking() {
    return window.setInterval(() => {
      this.blinkingCount.update((count) => count + 1);
    }, 500);
  }

  private startRunning() {
    return window.setInterval(() => {
      this.runState.update(({ count, side }) => {
        const newCount = count + 1;

        return {
          count: newCount,
          side:
            newCount === 10 || newCount === 20 || newCount === 30
              ? side === 'r'
                ? 'l'
                : 'r'
              : side
        };
      });
    }, 100);
  }

  private getRunningClassName(): string {
    const { count, side } = this.runState();
    const state = count === 41 ? 1 : count % 2 === 0 ? 3 : 4;
    return `${side}${state}`;
  }

  private getBlinkingClassName() {
    const state = this.blinkingCount() % 2 === 0 ? 1 : 2;

    return `l${state}`;
  }

  private clearInterval() {
    if (this.intervalRef) {
      clearInterval(this.intervalRef);
    }
    this.intervalRef = null;
  }
}

Lines of Code

RxJS wins at this:

	Lines of Code
RxJS	30
Signals	123

More code usually takes more time to understand, leaves more room for mistakes and is harder to change.

Level of Abstraction

The signals implementation is working on a lower level of abstraction. This RxJS code:

    takeWhile((t) => t < 40),

Becomes this with signals:

            if (count > 40) {
              this.clearInterval();
              this.state.set('blinking');
              this.runState.set({ count: 1, side: 'r' });
            }

RxJS operators describe actual behavior. If you don't use them explicitly (or something equivalent), you will be redefining them implicitly in scattered, repetitive logic coupled to business logic.

A developer who understands RxJS operators automatically understands more potential behavior of features, so the cost of becoming familiar with a new codebase that uses RxJS is less than the cost of learning the equivalent codebase that doesn't use them.

Learning RxJS is a good investment for your career.

Debugging

When something is wrong it is usually faster to directly inspect the thing that's wrong instead of making a guess about what code is related and trying to find the problem from there.

Imagine you wanted to know why the dragon was blinking for 2.5 seconds. If you directly inspected the dragon, you would find this (in the RxJS implementation):

<div [ngClass]="['bg dragon', dragonClass$ | async]"></div>

If you Cmd Click on dragonClass$, you see this:

  dragonClass$ = concat(
    this.runningClass$,
    this.blinkingEyesClass$,
    this.restingClass$
  ).pipe(repeat(Infinity));

concat means "run these back-to-back". repeat(Infinity) repeats the previous behavior Infinity times.

So now we already understand the main behavior, and we could Cmd Click on blinkingEyesClass$ to go into more detail.

This is a very convenient debugging experience, and it's because RxJS enables declarative syntax for even asynchronous behavior.

Declarative Code

Most of the benefits of the RxJS approach come from its declarative structure.

What does that mean?

Declarative Code Definition

Declarative code is where each declaration completely defines a value across time. The answer to the question "Why is this thing behaving this way?" is always answered in its declaration, not somewhere else.

Non-declarative code only initializes values, then leaves it up to scattered imperative code to define subsequent behavior. To answer the question "Why is this behaving this way?", you have to find all references to the variable, understand the context of each of those references, then determine if and how those references are controlling that variable.

Examples of Declarative vs Non-Declarative Code

UI

Declarative

<div>{{count()}}</div>

Non-Declarative

<div id="count">0</div>

countElement.innerText = +countElement.innerText + 1;

Variables

Declarative

const count = 0;

Non-Declarative

let count = 0;

// ...

  count++;

State

Declarative

const count$ = increment$.pipe(scan(n => n + 1, 0));

const count = toSignal(count$);

Non-Declarative

const count = signal(0);

// ...

  count.set(count() + 1);

Effect Events

Declarative

const increment$ = incrementRequest$.pipe(
  mergeMap(() => server.increment()),
);

Non-Declarative

const increment = createAction('INCREMENT');

// ...

increment$ = this.actions$.pipe(
  ofType('INCREMENT_REQUEST'),
  mergeMage(() => server.increment()),
  map(() => increment()),
);

(Note: Technically it's the store itself that's non-declarative, being modified by store.dispatch. But effectively each action is an event stream, and this code is defining when it gets dispatched.)

UI Events

Declarative

const incrementRequest$ = fromEvent(incrementButton, 'click');

Non-Declarative

const incrementRequest$ = Subject<void>();

// ...

  incrementRequest$.next();

Benefits of declarative code

Focus

Declarative code allows behavior to be self-contained and isolated. When you're working on one specific feature or behavior, you don't have to worry about imperative statements elsewhere changing it, so you can ignore the entire rest of the world and just define that one thing.

Debugging with Context

When behavior is being controlled from one place, rather than from many places, bugs are easier to track down.

Avoiding Bugs with Context

It's easier to avoid bugs when you can reference all relevant context when editing code that defines its behavior. This is the reason Facebook invented Flux for state management.

Comprehensibility

It's easier to quickly understand code when it's organized by what it does rather than by when it's executed. Callback functions contain imperative code that runs at the same time (mostly) but controls unrelated states, whereas reactive declarations organize code by the actual behavior they define.

Declarativeness in RxJS vs Signals Only

I color-coded the RxJS and signals-only implementations by what state/behavior the code is defining/modifying:

The signals implementation is not very declarative. This is because signals and computeds enable declarative code only for synchronous behavior. When time enters the equation, you need an effect, which, like all callback functions, is a container for imperative code. Since this feature involves a lot of timing behavior, it requires a lot of scattered imperative logic inside an effect and a few other places.

RxJS operators are currently the only comprehensive way to enable declarative code for asynchronous behavior. The only way to declare an asynchronous relationship between 2 variables is to define how they are related, which involves the logic contained in the operators.

For example, delay and debounceTime are just 2 different ways in which a reactive asynchronous relationship can be defined:

const b$ = a$.pipe(delay(20));

const b$ = a$.pipe(debounceTime(10));

Signal Operators

Could there be a way to define reactive asynchronous relationships without RxJS operators? RxJS operators are just functions that take in observables and return different observables. Could we write functions that could take in signals and return different signals and call them "signal operators"?

I think we can.

Let's try delay:

export function delay<T>(inputSignal: Signal<T>, t: number) {
  const outputSignal = signal(undefined as undefined | T);

  effect(() => {
    const value = inputSignal();
    setTimeout(() => outputSignal.set(value), t);
  }, { allowSignalWrites: true });

  return outputSignal;
}

This can be used like this:

count = signal(0);

delayedCount = delay(this.count, 3000);

This works, and delayedCount is 100% declarative syntax! We abstracted away the effect usage and imperative code, and enabled a declarative API.

This is an extremely simple example. Something much more sophisticated is required to achieve what the dozens of RxJS operators achieve.

So, my advice is this:

When you think you might need to write an effect for a signal, first try instead to

reorganize the code to use a computed

use an existing signal operator

write a new custom signal operator

convert to an observable with toObservable and use an RxJS operator

And only as a last resort, use effect directly.

Currently you will have to always either use RxJS operators, or write your own signal operators. But I think I am going to work on a library for signal operators. I explained the full reasons in this tweet thread and in this YouTube video. Follow me on Twitter for updates :)

Conclusion

This example was almost completely asynchronous. What you will see in the real world will land somewhere on the spectrum between synchronous and asynchronous.

The more asynchronous your app is, the more RxJS can help you keep your codebase clean, bug-free and easy to debug.

Just remember:

Avoid effect.

Use computed.
Use a signal operator.
Create a signal operator.
Use RxJS.

Thanks for reading! Follow me on Twitter for more frequent content: https://twitter.com/mfpears

Signals make Angular MUCH easier

Mike Pearson — Tue, 18 Jul 2023 21:41:30 +0000

YouTube

Why shouldn't RxJS do everything?

RxJS is amazing, but it has limitations. Consider a counter implemented using a simple variation of the "Subject in a Service" approach:



export class CounterService {
  count$ = new BehaviorSubject(0);

  increment() {
    this.count$.next(this.count$.value + 1);
  }
}

Now multiple components can share and react to this state by subscribing to count$:

Now let's add some derived states with the RxJS map and combineLatest operators:



  count$ = new BehaviorSubject(1000);

  double$ = this.count$.pipe(map((count) => count * 2));
  triple$ = this.count$.pipe(map((count) => count * 3));

  combined$ = combineLatest([this.double$, this.triple$]).pipe(
    map(([double, triple]) => double + triple)
  );

  over9000$ = this.combined$.pipe(map((combined) => combined > 9000));

  message$ = this.over9000$.pipe(
    map((over9000) => (over9000 ? "It's over 9000!" : "It's under 9000."))
  );

Here's a diagram of these reactive relationships:

Here's what that looks like:

Isn't this easy? RxJS just takes care of everything for us. There's probably nothing wrong with this.

Actually there is. Let's put a console log inside the map for message$ and see what happens when we increment the count once.



  message$ = this.over9000$.pipe(
    map((over9000) => {
      console.log('Calculating message$', over9000);
      return over9000 ? "It's over 9000!" : "It's under 9000.";
    })
  );

Why did it run 4 times? We only incremented the count once. That's not efficient.

Something weird is going on. Let's put console logs inside each observable so we can get a view into everything happening. And think for a minute about what we should expect. We have a single event, and 5 derived states: double$, triple$, combined$, over9000$, and message$. Shouldn't we see 5 console logs? Well, here's what we actually get:

It's over 9000!!! We just implemented our feature in the simplest way possible, and this is what RxJS gave us. This is 40 logs, or 8x what it should be.

We need to understand how subscriptions work. We have 2 components subscribing to several of these observables. Here I've added a colored line for each subscription:

Each subscription gets passed all the way up to the top of the chain. If you count the number of blue and green lines next to double$ and triple, it's 8 each. That's the number of console logs for each of those. combined$ has 12 lines around it (because of the branching), and 12 logs. But message$ has 2 lines and not 2 but 4 console logs, and over9000$ has 4 lines but 8 console logs. That's because each of those lines ends up splitting into 2 lines up at the combineLatest.

We have to learn more operators to deal with these problems: map and distinctUntilChanged (sometimes with a comparator), combineLatest and debounceTime, and shareReplay. Actually, not shareReplay, more like publishReplay and refCount. Or actually, merge, NEVER, share and ReplaySubject (more on these later). The really crazy thing is that most people aren't even aware of all these issues. It takes some painful experiences to learn that these operators are necessary.

But asking everyone to avoid the numerous RxJS pitfalls, become intimately familiar with how subscriptions work, and learn all these operators, all just for basic derived state, is absurd. And, these operators increase bundle size and do work at runtime. Creating a custom operator doesn't fix that.

So, while RxJS is amazing for managing asynchronous event streams, it is inefficient and difficult to use for synchronizing states.

How about selectors?

Selectors are pretty efficient at computing derived states.

But I never liked their syntax:



createSelector(
  selectItems,
  selectFilters,
  (items, filters) => items.filter(filters),
);

So for StateAdapt I came up with new syntax:



buildAdapter<State>(...)({
  filteredItems: s => s.items.filter(s.filters),
})();

But selectors require a state management library with a global state object, which makes them impossible to integrate tightly with framework APIs, such as component inputs.

Signals

Angular needed a reactive primitive of its own, and out of all the options, signals were the best choice for synchronization.

Let's implement our counter with Angular signals:



  count = signal(1000);

  double = computed(() => this.count() * 2);
  triple = computed(() => this.count() * 3);

  combined = computed(() => this.double() + this.triple());

  over9000 = computed(() => this.combined() > 9000);

  message = computed(() =>
    this.over9000() ? "It's over 9000!" : "It's under 9000."
  );

Now when we click, we get the 5 expected logs:

It's more efficient than even optimized RxJS, and we only needed one "operator": computed.

The Angular team did an amazing job with the implementation, too. If you want to learn more about how it works, I recommend this interview they did with Ryan Carniato.

Problems with signals

Signals are awesome, but like RxJS, they have limitations:

Asynchronous Reactivity
Eager & Stale State

These will be the topics of my next articles.

Why your folder structure sucks

Mike Pearson — Tue, 06 Jun 2023 06:36:49 +0000

YouTube

Inexperienced developers organize their code by technology rather than by feature. This is a mistake. Separating by technology leads to

folder straddling
hard-to-find files
reusability confusion
slow load times
slow build times
huge folders

1. Folder straddling

When do you tend to edit or view all files that use the same technology? It’s usually when you are

learning the technology
teaching the technology
adding/upgrading the technology

This is why every time a new technology is invented, everyone seems to agree that all the files that use it should have a dedicated folder. Learners and teachers both want to quickly become oriented with the new technology and switch easily between examples that use it.

But they eventually grow out of this pattern. Let's look at some examples.

HTML + JavaScript + CSS

In the early days of AngularJS, everyone had separate templates/ and controllers/ folders. Both learners and teachers were focused on AngularJS, which treated HTML, CSS and JavaScript very differently.

This was okay for demos and small projects, but as real-world AngularJS applications grew, developers spent most of their time editing files in completely different folder paths. This was extremely annoying.

Pretty much all at once, everyone in the Angular community decided to refactor to a separation by components instead, where each component had its own folder with all its relevant files, regardless of the fact that multiple technologies were being used.

State

When state management became a primary concern with SPAs, developers felt the need to create a separate folder for managed state. This means in order to work on a single feature, you needed to spend most of your time editing files in completely different folder paths. This was extremely annoying. Unfortunately, people blamed Redux instead of the bad folder structure.

But a global store is an implementation detail, and nothing more. The fact that reducers/states/slices are ultimately collected into a single, global object is only a mechanism for reactivity and Redux Devtools. Any code that assumes it can just grab any state from anywhere in the global store is going to be bug-prone, so each store slice needs to export its own selectors/actions to interface with instead, which entirely abstract away the global store behind them. In the end, you just have a bunch of independent features, like always. Your folder structure should reflect that.

Types

When most Angular developers learned TypeScript in 2016, for a short period of time they wanted to put all their types in a central types/ folder. They have almost completely moved away from that, because if a developer needs to edit a type, they are guaranteed to need to edit other files in their project, which would require editing files in completely different folder paths, which is extremely annoying. React developers adopted TypeScript much later, and many new React projects are still set up with a central “types” folder. This will not last very long, just like it didn’t in the Angular community.

This will always happen

Whenever there is a new technology, there is always a strong influence from tutorials, content creators and project scaffolding tools to separate by technology instead of by feature. If the cost isn’t too high, this naïve strategy will remain a habit for some time.

New tools can be intimidating, but the actual purpose of a project quickly overshadows the technology as the primary concern.

2. Hard-to-find files

When do you look for files? It’s usually when you are

becoming familiar with a project
debugging an issue

Becoming familiar with a project

If a project is your first encounter with a technology, you will want to see that technology reflected in the folder structure. But you are not going to understand much about what you are looking at, no matter how the folders are structured. The technology-based organization will give a slight sense of familiarity, but it won’t help you understand the actual project in front of you any more than picking an arbitrary file that uses that technology and trying to understand that.

If you want to see examples of a technology, you can just search for files with the extension for that technology, such as .slice.ts. File extensions indicate what technology is being used, and it's the last part of the file name because it's the least important detail.

If you are experienced, you will want the details of the project to be reflected first.

Debugging an issue

When debugging an issue, you start by seeing a broken feature. Problems are connected to features, which require multiple technologies to define, and, therefore, can be messed up by multiple technologies. Horizontally scanning all files by technology is useless for debugging anything but the technology itself. What you want is good developer tools that lead you through the technology layers, from the problem to the cause.

Let's say something is wrong in the UI. You start by inspecting the HTML. Then you use your framework's devtools to go directly to the component. Then you "click to definition" to a state management file, and continue until you find the problem. Now, if your folder structure is organized by technology, you will have jumped between 5 totally different folders. If it's organized by feature, you might not even have had to open more than 1 file, let alone folder. And maybe you even immediately saw the problem when you opened the component file, because every layer defining the feature was already there in front of your eyes.

3. Reusability confusion

If your code is organized by technology rather than by feature, you may be tempted to reuse one slice of that technology layer across multiple features. This seems convenient at first, but it introduces unnecessary complexity. Each feature is an independent concern, and is likely to drive changes across multiple technology layers that don't make sense to have in other features.

I was once a naïve Angular developer arguing for keeping HTML and JavaScript separate. I thought it would be good to have the flexibility to have multiple templates available for a single controller. The controller was responsible for managing state, and the template was responsible for displaying that state. Those are separate concerns, right?

But I have been writing component-only UI code for 8 years now, and never once have I taken advantage of Angular's separation of HTML and JavaScript; I have never used the same template in 2 different components, nor have I used the same component class in 2 different components.

HTML and JavaScript are different technologies, but your primary concern should be vertical slices of functionality that may span multiple technologies. These vertical slices are likely to change independently from other slices.

Reusability comes from having thin vertical slices that can be imported by other thin vertical slices. And these slices should be organized around a single type/interface, because that is the foundation that everything else is built on: When a type changes, everything that references it needs to change too. Ideally, those should be in the same folder. Even if your vertical slice extends all the way up to "global" state or even server-side code, it should be in the same folder as the primary type it uses. And if the feature is small, maybe it should even be in a single file.

4. Slow load times

Developers often prefer horizontal separation because they never have to worry about dependencies. They can just import whatever they want, because layers from above never import from layers below. At the top you have types, which are extremely abstract; then there are utilities; then you have state; then components.

Because of this, circular dependencies are easily avoided when code is separated by technology. So this is the one problem separation by technologies seems to handle very well.

But this is more of a strategy of avoidance than a solution.

A circular dependency is when multiple things have actually become one thing.

The reason we want our build tools to warn us of this is so we don't accidentally create giant things and make our users download more code than necessary. Separation by technology is just an escape hatch that allows us to be complacent about large bundles, as long as they only include code from the same horizontal layer (technology).

Users only need the code for the features on the current page, so we want our code bundles to only include what is needed for each feature. If it's okay to import anything from the technology layers above, there will be no friction to prevent developers from coupling each feature to every other feature. We want our tools to prevent us from creating circular dependencies between features, not technologies.

How do you deal with circular dependencies between features? You create a 3rd feature that the other features import from. Just because it doesn't plainly exist in the designs or in a route, doesn't mean you can't have a folder for it. You should. Every unique type can have its own folder, and you will never have circular dependencies. It doesn't have to have API, state or UI files, but you will have a place for them later.

5. Slow build times

Smaller bundles are great for users, but they are also great for developers, because they mean faster build times. With Nx, for example, running nx affected:build will build only the code related to the feature you've been working on, if libraries are organized by feature. But if you have a types library, for example, and you make a change to just one type inside it, then every library that depends on any type needs to rebuild. This will cascade to a huge amount of code totally unrelated to your changes in a specific feature. In large projects this can extend build times by multiple orders of magnitude.

I may or may not have written that last paragraph while waiting for a build.

6. Huge folders

Imagine you have 5 features, each with a component and a Redux slice.

This is a folder structure organized by technology:

store
    a.slice.ts
    b.slice.ts
    c.slice.ts
    d.slice.ts
    e.slice.ts
components
    A.tsx
    B.tsx
    C.tsx
    D.tsx
    E.tsx

This is a folder structure organized by feature:

a
    a.slice.ts
    A.tsx
b
    b.slice.ts
    B.tsx
c
    c.slice.ts
    C.tsx
d
    d.slice.ts
    D.tsx
e
    e.slice.ts
    E.tsx

When we organize by technology, we have more large folders than when we organize by feature.

However, both have the problem that there is at least 1 folder with 5 things in it. If we keep adding features, the folder will keep getting bigger.

One solution is to group the features into scopes or categories. So let's say A, B and D are related somehow, and we can change the folder structure to this:

some-commonality
    a
        a.slice.ts
        A.tsx
    b
        b.slice.ts
        B.tsx
    d
        d.slice.ts
        D.tsx
c
    c.slice.ts
    C.tsx
e
    e.slice.ts
    E.tsx

If we were organizing by technology, we would have to create this nested structure in 2 different places:

store
    some-commonality
        a.slice.ts
        b.slice.ts
        d.slice.ts
    c.slice.ts
    e.slice.ts
components
    some-commonality
         A.tsx
         B.tsx
         D.tsx
    C.tsx
    E.tsx

That's annoying.

Another way is to nest the store and component folders like this:

some-commonality
    store
        a.slice.ts
        b.slice.ts
        d.slice.ts
   components
        A.tsx
        B.tsx
        D.tsx
store
    c.slice.ts
    e.slice.ts
components
    C.tsx
    E.tsx

This is a little better, but now we're going to be repeating store and components folders a lot, which gets annoying to deal with.

Ultimately, organizing folders by feature is the least annoying strategy.

Organizing by routes

Features usually correspond with routes, but as projects grow, this 1-to-1 relationship has exceptions. Often a single feature needs to appear inside multiple routes.

It is fine to start by organizing files by routes first, since there are some benefits to doing it this way. However, it is important to realize that nesting a folder slightly couples it to its parent feature, and as soon as it needs to be reused, it needs to be moved to a top-level folder where it can be imported into both routes.

Directory trees are inherently limited

Organizing folders by feature is better than organizing by technology, but ultimately there is no great way to organize code in a folder structure.

If you think about the actual code you are writing, what is its relationship with other code? It imports it, right? It gets imported, too. And that creates a dependency graph. And if we try to fit a graph into a directory tree, we are going to have a bad time.

Imagine if we didn't have to deal with this fundamental problem!

Every once in a while developers will try to use symlinks to make the folder structure behave like a graph instead of a tree, but these are irritating to deal with, so this pattern never catches on.

What we need is a solid abstraction on top of files that allows us to manage our assets as a graph instead of a tree. I think Nx Devtools' dependency graph visualization is awesome, and could maybe do the job if it could be used to open the files it's visualizing, maybe as a VSCode extension. Then you could completely ignore the underlying folder structure.

We also need the ability to create relationships that are purely organizational. Sometimes it's helpful to be able to hide code inside a parent folder with a more abstract name. This relationship doesn't come from importing the code, but from an implicit relationship between the code and code that's similar to it. But this relationship should be a graph too, because there are multiple ways to categorize all code.

For example, you could have a file called concat-array-strings.function.ts. Would you put that in a string folder, an array folder, or a utils folder? A utils folder is like organizing by technology (or lack thereof), so it is not ideal in my opinion. But the point is that there are potentially multiple buckets you could put a concat-array-strings.function.ts file in, so why do you have to choose? Each of these potential parent folders is just abstracting out a different property of the code, when in reality it is all of those things.

This might be getting a little too philosophical now. I have many ideas about how code could be organized. But for now, I would just be happy if people would start organizing their folders by types more instead of by technology. Maybe some content creators will see this and realize they have been misleading new developers this whole time.

Conclusion

There is no folder structure that is perfect, but some are definitely better than others. You should realize that what you are concerned with at the beginning of a project may not be your primary concern later on, and you may later regret the decisions you make.

Ever since I started organizing my project folders by feature instead of technology, getting stuff done has been less annoying. If you haven't tried it yet, please do. And again, comment below if you think you have an example that I have not thought of.

And if you agree, please share this with your team!

How to not regret useState

Mike Pearson — Tue, 28 Feb 2023 06:47:09 +0000

YouTube

Features need to be able to evolve with unpredictable business needs. Features that are simple today are unlikely to remain simple.

useState is great for simple features. But when a feature needs to become more complex, how many developers are going to suddenly throw away all existing local state code and create a Redux store that takes 3x the amount of code? It's much easier to just add another line of imperative code to the mess.

The syntactic gap between imperative and declarative state management gradually steers the codebase towards a big ball of spaghetti that looks like the left version of this real example:

Whereas, the fully unidirectional/reactive solution would have looked more like the version on the right.

The spaghetti codebase will be buggier and developers will be less productive in it. It is technical debt that has to be paid. The codebase has traveled along a certain path, and that path is no longer tenable. And in order to get out of it, we need to refactor to a completely different syntax. So we need to undo most of the work we've done, and start over on the right path. This is what I call a syntactic dead-end.

The only way to avoid these syntactic dead-ends is to use tools that enable minimal, declarative syntax at each level of complexity.

I have seen 8 levels of state management complexity:

Simple Local State
Complex State Changes
Derived State
Global State
Reusable State Logic
Global Events/Actions
Asynchronous Events
Combined Global Derived State

At each level we will see a fork in the road: Imperative vs Declarative. Let's look closely at each level and see what kinds of syntax could make the declarative path as easy as possible, so we can steer clear of syntactic dead-ends.

1. Simple Local State

Let's start with

function Component() {
  const [name, setName] = useState('Bob');
  return (
    <>
      <h2>Hello {name}!</h2>
      <button onClick={() => setName('Bilbo')}>Change Name</button>
    </>
  );
}

We've got name local state and we're setting it to 'Bilbo'. And we're using JSX, which is already declarative, so let's move on to the next level.

2. Complex State Changes

Let's say we need to add a button to reverse the name.

We need to choose between an imperative style and a declarative style. In the declarative style, all code that controls a piece of state is included in the state's declaration. The imperative style is the opposite of this, where state is controlled from inside event handlers away from the state's declaration.

2. Complex State Changes: Imperative

To solve this imperatively, we could add an event handler containing the state change logic:

function Component() {
  const [name, setName] = useState('Bob');
  const reverseName = () => {
    setName(n => n.split('').reverse().join(''));
  };
  return (
    <>
      <h2>Hello {name}!</h2>
      <button onClick={() => setName('Bilbo')}>Change Name</button>
      <button onClick={reverseName}>Reverse Name</button>
    </>
  );
}

At this point we've already started down the path towards a syntactic dead-end. It looks harmless right now, but as the feature becomes more complex, that event handler will likely take on more and more responsibilities, and that state will be controlled by more and more event handlers. We will eventually have to remove the code we just wrote in order to get out of the mess. So let's not write it in the first place.

So how can we implement this declaratively? What tools allow us to include the state change logic in the state's declaration itself?

This is the problem useReducer was created to solve.

2. Complex State Changes: Declarative with `useReducer`

type Action = { type: 'reverse' } | { type: 'set'; payload: string };

function Component() {
  const [name, dispatch] = useReducer((state: string, action: Action) => {
    if (action.type === 'set') return action.payload;
    if (action.type === 'reverse') return state.split('').reverse().join('');
    return state;
  }, 'Bob');
  return (
    <>
      <h2>Hello {name}!</h2>
      <button onClick={() => dispatch({ type: 'set', payload: 'Bilbo' })}>
        Change Name
      </button>
      <button onClick={() => dispatch({ type: 'reverse' })}>Reverse Name</button>
    </>
  );
}

The benefit of this is that it is extremely similar to the syntax we'd use if we converted to a global Redux store later. It's declarative, meaning all logic that controls what this state will be is centralized in its declaration.

The drawback is that this is awful. There is so much work to add the syntax for this state change, it's no wonder most developers take the imperative path that eventually leads to spaghetti code.

Other tools are already disqualified as well. Redux is just like this, but even slightly worse. If our official policy was to use useReducer or Redux, most developers would constantly be pushing code into syntactic dead-ends instead of coding declaratively.

What we want is syntax that makes the declarative style just as easy as the imperative style.

Admittedly, I'm not an expert in every state management library in React, but after I couldn't find anything that already solved these problems for Angular apps I created my own solution and recently made it much easier to use in React. If you're aware of anything that's close to what I've created for React, please let me know. Regardless, whatever tool you use to solve this problem will have somewhat similar syntax, otherwise it wouldn't solve the problem.

2. Complex State Changes: Declarative with StateAdapt

function Component() {
  const [name, nameStore] = useAdapt(['name', 'Bob'], {
    reverse: state => state.split('').reverse().join(''),
  });
  return (
    <>
      <h2>Hello {name.state}!</h2>
      <button onClick={() => nameStore.set('Bilbo')}>Change Name</button>
      <button onClick={() => nameStore.reverse()}>Reverse Name</button>
    </>
  );
}

This is slightly more work than creating the imperative solution, but it's declarative, and it's much less code than useReducer.

3. Derived State

Let's say we want to display the name in all uppercase letters.

Declarative, derived state in React is trivial. All we have to do is add toUpperCase() to the JSX expression, and we have created some declarative, derived state.

function Component() {
  const [name, nameStore] = useAdapt(['name', 'Bob'], {
    reverse: state => state.split('').reverse().join(''),
  });
  return (
    <>
      <h2>Hello {name.state.toUpperCase()}!</h2>
      <button onClick={() => nameStore.set('Bilbo')}>Change Name</button>
      <button onClick={() => nameStore.reverse()}>Reverse Name</button>
    </>
  );
}

It gets more interesting in React when we need to actually share that derived state. In StateAdapt, we do this by adding a selectors object to our state changes object:

function Component() {
  const [name, nameStore] = useAdapt(['name', 'Bob'], {
    reverse: state => state.split('').reverse().join(''),
    selectors: {
      uppercase: state => state.toUpperCase(),
    },
  });
  return (
    <>
      <h2>Hello {name.uppercase}!</h2>
      <button onClick={() => nameStore.set('Bilbo')}>Change Name</button>
      <button onClick={() => nameStore.reverse()}>Reverse Name</button>
    </>
  );
}

So we have two choices. Is one of them a syntactic dead-end?

What if we choose the simple solution first? Will we regret it later? Here's all the work required when starting with local derived state first, then changing to StateAdapt's sharable derived state syntax:

Actually, everything we did for pure local state was something we would have needed to do anyway to make it sharable. So we do not need to worry about syntactic dead-ends with derived state.

4. Global State

StateAdapt makes it very easy to move from local state to global state:

const nameStore = adapt(['name', 'Bob'], {
  reverse: state => state.split('').reverse().join(''),
  selectors: {
    uppercase: state => state.toUpperCase(),
  },
});

function Component() {
  const name = useStore(nameStore);
  return (
    <>
      <h2>Hello {name.uppercase}!</h2>
      <button onClick={() => nameStore.set('Bilbo')}>Change Name</button>
      <button onClick={() => nameStore.reverse()}>Reverse Name</button>
    </>
  );
}

Here's what we had to do:

Copy-paste the state declaration
Change useAdapt to adapt outside the component
Change useAdapt to useStore inside the component
Only define the nameStore outside
Only define name inside

That's easy enough to not regret having our state local at first. That's because declarative code is inherently more portable.

5. Reusable State Logic

Sometimes you not only need to share state, but also the logic that controls that state. For example, if you have one paginated datagrid and the designer produces a design that puts a 2nd datagrid of the exact same kind on the same page, you would want to reuse the state logic between the two separate instances of state.

This doesn't happen very often, but when it does, if your state logic is coupled to specific state and specific event sources, you are going to have a bad time.

In order to avoid this dead-end, you need to be putting all of your state logic from the beginning into a class or object that can easily be moved around independently. Here's how StateAdapt handles this scenario:

const nameAdapter = createAdapter<string>()({
  reverse: state => state.split('').reverse().join(''),
  selectors: {
    uppercase: state => state.toUpperCase(),
  },
});
const name1Store = adapt(['name1', 'Bob'], nameAdapter);
const name2Store = adapt(['name2', 'Bob'], nameAdapter);

function Component() {
  const name1 = useStore(name1Store);
  const name2 = useStore(name2Store);
  return (
    <>
      <h2>Hello {name1.uppercase}!</h2>
      <button onClick={() => name1Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name1Store.reverse()}>Reverse Name</button>

      <h2>Hello {name2.uppercase}!</h2>
      <button onClick={() => name2Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name2Store.reverse()}>Reverse Name</button>
    </>
  );
}

This is as easy as it could possibly be.

6. Global Events/Actions

Let's say we need to add a button to reset each store back to its initial state.

Once again, we need to choose between an imperative style and a declarative style.

6. Global Events/Actions: Imperative

To solve this imperatively, we could add an event handler containing the state change logic:

const nameAdapter = createAdapter<string>()({
  reverse: state => state.split('').reverse().join(''),
  selectors: {
    uppercase: state => state.toUpperCase(),
  },
});

const name1Store = adapt(['name1', 'Bob'], nameAdapter);
const name2Store = adapt(['name2', 'Bob'], nameAdapter);

function resetBothNames() {
  name1Store.reset(); // `reset` comes with every store
  name2Store.reset();
}

function Component() {
  const name1 = useStore(name1Store);
  const name2 = useStore(name2Store);
  return (
    <>
      <h2>Hello {name1.uppercase}!</h2>
      <button onClick={() => name1Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name1Store.reverse()}>Reverse Name</button>

      <h2>Hello {name2.uppercase}!</h2>
      <button onClick={() => name2Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name2Store.reverse()}>Reverse Name</button>

      <button onClick={() => resetBothNames()}>Reset Both Names</button>
    </>
  );
}

Again, we've started down the path towards a syntactic dead-end. As the feature becomes more complex, that event handler will take on more and more responsibilities, and that state will be controlled by more and more event handlers. We will eventually have to remove the code we just wrote in order to get out of the mess. So let's not write it in the first place.

So how can we implement this declaratively?

6. Global Events/Actions: Declarative with StateAdapt

The reason Redux is declarative is because each reducer/state declares for itself which actions its interested in and how its state reacts to them. State is downstream from actions.

StateAdapt uses RxJS to enable the exact same kind of declarative state management. You can define a Source, which is like an RxJS Subject but emits Action objects similar to those in Redux. And stores are able to react to these action sources, just like in Redux:

const nameAdapter = createAdapter<string>()({
  reverse: state => state.split('').reverse().join(''),
  selectors: {
    uppercase: state => state.toUpperCase(),
  },
});

const resetBothNames$ = new Source<void>('resetBothNames$'); // action type

const name1Store = adapt(['name1', 'Bob', nameAdapter], {
  reset: resetBothNames$,
});
const name2Store = adapt(['name2', 'Bob', nameAdapter], {
  reset: resetBothNames$,
});

function Component() {
  const name1 = useStore(name1Store);
  const name2 = useStore(name2Store);
  return (
    <>
      <h2>Hello {name1.uppercase}!</h2>
      <button onClick={() => name1Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name1Store.reverse()}>Reverse Name</button>

      <h2>Hello {name2.uppercase}!</h2>
      <button onClick={() => name2Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name2Store.reverse()}>Reverse Name</button>

      <button onClick={() => resetBothNames$.next()}>Reset Both Names</button>
    </>
  );
}

This is just 1 more line of code than the imperative solution, so it should be easy to stay declarative with this syntax.

7. Asynchronous Events

Now let's say we want to load the names from the server. The name from the server can be declared as an observable, and StateAdapt provides an RxJS operator called toSource that converts an observable into a source.

const nameAdapter = createAdapter<string>()({
  reverse: state => state.split('').reverse().join(''),
  selectors: {
    uppercase: state => state.toUpperCase(),
  },
});

const resetBothNames$ = new Source<void>('resetBothNames$');

const name$ = timer(3_000).pipe( // Pretend it's from the server
  map(() => 'Bob'),
  toSource('name$'),
);

const name1Store = adapt(['name1', 'Loading', nameAdapter], {
  set: name$,
  reset: resetBothNames$,
});
const name2Store = adapt(['name2', 'Loading', nameAdapter], {
  set: name$,
  reset: resetBothNames$,
});

function Component() {
  const name1 = useStore(name1Store);
  const name2 = useStore(name2Store);
  return (
    <>
      <h2>Hello {name1.uppercase}!</h2>
      <button onClick={() => name1Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name1Store.reverse()}>Reverse Name</button>

      <h2>Hello {name2.uppercase}!</h2>
      <button onClick={() => name2Store.set('Bilbo')}>Change Name</button>
      <button onClick={() => name2Store.reverse()}>Reverse Name</button>

      <button onClick={() => resetBothNames$.next()}>Reset Both Names</button>
    </>
  );
}

Asynchronous side-effects and events are where most state management libraries stop being declarative. But RxJS allows StateAdapt to let the stores define their own behavior over time.

8. Combined Global Derived State

Now let's say we want to show a message "Hello Bobs!" when both names are 'Bob'. So we want derived state that is true when both names are Bob, and we want to be able to use this in multiple components.

The syntactic dead-end for this feature is using RxJS. We need RxJS for declarative asynchronous logic, but it is not great for synchronously derived state, as I explain here.

In StateAdapt, all stores are part of a single global store, so we use selectors to efficiently compute derived data between stores:

const name12Store = joinStores({
  name1: name1Store,
  name2: name2Store,
})({
  bothBobs: s => s.name1 === 'Bob' && s.name2 === 'Bob',
})();
// ...
  const name12 = useStore(name12Store);
  // ...
      {name12.bothBobs && <h2>Hello Bobs!</h2>}

This isn't as concise as it could be for defining only one selector, but the syntax helps avoid a different kind of syntactic dead-end that's a little too obscure to talk about here :) For more information, see the documentation for joinStores.

Conclusion

Here is how the code may have looked if we had taken the imperative path at every step:

(I used Jotai in the imperative example, but I'm sure Jotai can be used more reactively.)

Now, ask yourself, "What is the value of name1?" In the declarative implementation you can use "Click to Definition" until you get your answer; everything is centralized and directly referencing what it needs to define itself. But in the imperative implementation you have to use "Find all References" because name1 is controlled from many places.

This is a very simple example. In real-world applications the imperative style becomes much harder to follow.

Like many developers, I'm too lazy to implement this in Redux. But you can imagine that it would have been quite a bit more code, and as a consequence, the odds that a developer would have taken the imperative path at some point would have been very high.

So, for almost all teams, it seems that adaptive state management is necessary for clean, maintainable code.

StateAdapt is very close to releasing version 1.0. I would love to hear what you think about it.

If there are any state patterns you think I'm missing in this article, let me know.

Stop managing state

Mike Pearson — Thu, 05 Jan 2023 09:17:36 +0000

YouTube

Have you ever written state management that looked like this?

return ({
  ...state,
  checked: !state.checked,
});

You've probably done this a million times.

But you won't have to anymore, thanks to state adapters.

What are state adapters?

State adapters are objects that contain reusable logic for changing and selecting from state. Each state adapter is dedicated to a single state type/interface, which enables portability and reusability. Everywhere you need to manage state with a certain shape, you can use its state adapter.

If someone just made a boolean state adapter, nobody on Earth would ever need to write that code again. Instead, they could just write something like this:

return adapter.toggleChecked(state);

Booleans are the simplest type of state, but even in the case of booleans, being able to reuse state management logic is very nice.

Decoupled state management, without the boilerplate

Most state management code is coupled to specific state. For example, in Redux or NgRx apps you will see state management like this:

on(TodoActions.createSuccess, (state, { todo }) => ({
  ...state,
  todos: [...state.todos, todo],
  loading: false,
})),

The action createSuccess has specific event sources dispatching it, and this reducer is managing specific state. So all the state logic defined in this code is coupled to that specific state and that specific action, and it takes a fair amount of work to decouple it.

Imagine if object-oriented programming didn't support the new key word. Every class you defined would actually be a specific object, not just some abstraction that could be used as over and over again with different data. How would people reuse any logic? They would define it externally, and import it into each class that needed it. But then the business logic isn't in the class anymore. The class turns into nothing more than a slab of boilerplate.

Does that sound familiar? This might remind you of reducers in Redux/NgRx. And extracting the logic into utilities is exactly what these libraries have done with their entity adapters. These provide some utilities for handling common state management patters, like this:

on(TodoActions.createSuccess, (state, { todo }) =>
  adapter.addOne(todo, { ...state, loading: false })
),

But this only handles some of the logic; the remaining logic is still coupled to this specific reducer.

What if we had an asyncEntityAdapter?

on(TodoActions.createSuccess, (state, { todo }) =>
  adapter.addOneResolve(todo, state)
),

That's better.

Now we just have the reducer boilerplate left.

What if we just always wrote our state management logic inside adapters where it would be decoupled from any specific reducer? Our reducers would then only ever be calling adapter methods. And we could remove some boilerplate if the arguments of those adapter methods were switched and we could just reference the method:

on(TodoActions.createSuccess, adapter.addOneResolve),

Now our reducer contains almost no boilerplate. If we want to get rid of all of it, we should be able to define our adapter code inside the reducer function itself, and only when needed, extract it by cutting and pasting the code to the outside where it can be used by multiple reducers. So the syntax for defining reducers and state adapters should be the same. But Redux and NgRx can't do this and don't provide any utilities for developers to easily define state adapter logic themselves, so we will look into some simple utilities we can provide ourselves later.

First, let's explore state adapters themselves and other ways in which they might be valuable.

Composability

State is usually composed of smaller types/interfaces, like this:

interface OptionState {
  value: string;
  checked: boolean;
}

In the first example above we saw that even a boolean state adapter could be valuable. And what if we also had a stringAdapter? And if we had those two, could we somehow define an optionAdapter that is composed of those two adapters, just as the OptionState interface is composed using the string and boolean types?

Let's say we have a utility that allows us to define adapters with type inference. Our booleanAdapter could be defined like this:

export const booleanAdapter = createAdapter<boolean>()({
  setTrue: () => true,
  setFalse: () => false,
  toggle: state => !state,
});

Imagine a similar definition for stringAdapter.

Now how do we define an optionAdapter composed of these two adapters? We could just create a new adapter and use the child adapters directly:

export const optionAdapter = createAdapter<Option>()({
  setValue: (state, value: string) => ({ ...state, value }),
  toggleChecked: state => ({
    ...state,
    checked: booleanAdapter.toggle(state.checked),
  }),
});

But booleanAdapter.toggle(state.checked) could have just been !state.checked. So this actually sucks.

So I came up with a function to make it easier to compose adapters:

export const optionAdapter = joinAdapters<Option>()({
  value: baseStringAdapter,
  checked: booleanAdapter,
})();

That's all it takes, and in the end we get an object like this:

{
  set: (state: Option, payload: Option) => payload,
  update: (state: Option, payload: Partial<Option>) => ({ ...state, ...payload }),
  reset: (s: Option, p: void, initialState: Option) => initialState,
  setValue: (state: Option, value: string) => ({ ...state, value }),
  resetValue: (state: Option, p: void, initialState: Option) => ({
    ...state,
    value: initialState.value,
  }),
  setChecked: (state: Option, checked: boolean) => ({ ...state, checked }),
  resetChecked: (state: Option, p: void, initialState: Option) => ({
    ...state,
    checked: initialState.checked,
  }),
  setCheckedTrue: (state: Option) => ({ ...state, checked: true }),
  setCheckedFalse: (state: Option) => ({ ...state, checked: false }),
  toggleChecked: (state: Option) => ({ ...state, checked: !state.checked }),
  selectors: {
    value: (state: Option) => state.value,
    checked: (state: Option) => state.checked,
  }
}

See how booleanAdapter.setTrue became optionAdapter.setCheckedTrue? joinAdapters assumes that each state change name will start with a verb. I thought about putting the namespace first, like checkedToggle and checkedSetTrue, but in some cases that gets confusing. Inserting the namespace after the first word is a small computational cost, but it makes the names clearer. And as of TypeScript 4.1, these types of string transformations are possible while keeping type inference intact. So it will warn you if you try to pass a payload into optionAdapter.setCheckedTrue and it will make sure you pass a boolean into optionAdapter.setChecked.

If state from multiple child adapters needs to change at the same time, joinAdapters has a way to let you define that so it happens efficiently. It also has a way to let you define memoized selectors that combine state from multiple child adapters. You can read more about these adapter patterns here.

Between createAdapter and joinAdapters we can create and reuse some really sophisticated state patterns.

Adapter Creators

What if we want to create an adapter for some properties, but allow for consumers of our adapter to define extra properties on the state interface? What we need is a function like this:

export function createOptionAdapter<T extends Option>() {
  return joinAdapters<T, Exclude<keyof T, keyof Option>>()({
    value: baseAdapter,
    checked: booleanAdapter,
  })();
}

This will create the same adapter as above, but it will also allow additional properties on the state object. So if you had an Option interface, it could have all the properties you wanted, as long as it also had value and checked. This is similar to how state shape can be extended with NgRx/Entity and Redux Toolkit.

So, somebody could take the adapter returned from your function and combine it with their own adapter:

interface Person {
  loading: boolean;
  value: string
  checked: boolean;
}

const optionAdapter = createOptionAdapter<Person>();

export const personAdapter = createAdapter<Person>()({
  receivePerson: (state, person: Person) => ({
    ...state,
    ...person,
    loading: false,
  }),
  ...optionAdapter,
  selectors: {
    loading: state => state.loading,
    ...optionAdapter.selectors,
  },
});

An OP entity adapter

Most state management libraries that provide utilities for managing lists of entities give you all the basic tools, like addOne, removeOne, setAll, removeMany, etc...

But what if we assume that developers are going to be creating state adapters for the entities in the entity state? And what if they pass that adapter into our createEntityAdapter function? What could we do with that?

Normally an entity adapter will have state change functions called updateOne and updateMany. The entity adapter itself has no idea what update is being passed to it—just that it needs to spread it into the entity object. Here is an example I found:

      return optionEntityAdapter.updateMany(
        state.ids.map((id: string) => ({
          id,
          changes: { selected: true },
        })),
        state,
      );

All of this work just to flip selected to true in every entity.

If we use the booleanAdapter to define an optionAdapter, and in turn use the optionAdapter to define the entity adapter, we could know that setSelectedTrue is a state change on optionAdapter and automatically generate a state change function that can be used like this:

return optionEntityAdapter.setManySelectedTrue(state, state.ids);

For that matter, why not just give them an All variation for each state change function:

return optionEntityAdapter.setAllSelectedTrue(state);

Think of all the state change functions we could define in an individual entity's adapter, and then createEntityAdapter can handle all the annoying list stuff!

Filter selectors

What about filtering our entities? Well what if the optionAdapter had selectors that returned booleans? Couldn't we provide some entity selectors that used those to filter the entities?

Yes we can. I just used the same name as the filter, and it returns all entities for which selected is true.

What if we need to filter using multiple criteria? Just define it as another selector in the optionAdapter.

We can also use filter selectors to apply state changes selectively. Redux Toolkit and NgRx/Entity will have the One, Many and All ways of choosing which entities to change, but those are basically just filters. We can also create state change functions for each filter selector.

So let's say we wanted to select all options that start with the letter A. The optionAdapter first needs a filter selector for this:

startsWithA: option => option.value.startsWith('A')`,

Now that becomes available on the entityAdapter like this:

entityAdapter.setStartsWithASelectedTrue

Sorter selectors

If you define a selector that returns a value that can be compared with >, then it can also be used to sort the entities in a selector. The optionAdapter has a selector called value that returns a string, so we can use it to sort the entities in a selector called entityAdapter.selectedByValue, or entityAdapter.allByValue.

But should one?

This is extremely powerful. Potentially over-powered, and not in a good way. You might all be feeling like Jeff Goldblum right now.

We already had a dozen or so state change functions in the optionAdapter, and that balloons to a ridiculous number when we feed it into createEntityAdapter. So, I added an options object that forces developers to specify which selectors to generate additional filter selectors and sort selectors for:

const optionEntityAdapter = createEntityAdapter<Option>(optionAdapter, {
  filters: ['selected'],
  sorters: ['value'],
  useCache: true, // Selectors for each entity can be memoized if expensive
});

Even with this, optionEntityAdapter has around 100 state change functions to choose from. Honestly this is awesome, because TypeScript will filter the suggestions as you type and tell you what each does as you need it, none of which you needed to write. But what is the computational cost of this? Surprisingly, in my tests it only adds around a millisecond or two of computation time compared to creating a traditional entity adapter. This was something like 50% more time. So it's not going to slow the app down, but if it ever does, I can also look into making adapters proxy objects and defining these state change functions lazily.

TypeScript is also doing a lot of work, but so far the type-checking is still very fast. I fine-tuned it a bit, but I'm not a TypeScript mastermind, so I'm sure it could still be optimized.

But even with performance not being an issue, some of these names are just... awkward, aren't they? Any weird or ambiguous name in the individual entity adapter will get amplified in the entities adapter.

But all of this saves so much code, and could really speed up development. So, with all the code that this saves, maybe it is worth it.

Please feel free to try it out and give feedback!

Conclusion

I'm really sick of writing code that looks like this:

({
  ...
  {
    ...
    {
      ...
    }
  }
})

or even dot-chaining with imperative code. Especially when it's the same exact code I've written dozens of times before!

I don't expect state adapters to completely solve all of these issues. But UI components didn't solve all our issues either, did they? But they made UI development much simpler in the end, because you don't even have to think about whether the UI code you're writing needs to be reused, because it's already in a component by default! Why not write our state management code in the same way? And just like how component libraries were created, maybe state adapter libraries could be created too, or maybe shared alongside component libraries. Think of how much component libraries have sped up your work; maybe state adapters could do the same.

I don't know if state adapters are the ultimate solution to state management, but I am certain that they are better than coupling state management logic with reducers, and the syntax is much nicer. If you're hesitant about any of the composability stuff I talked about in this article, maybe you could just try using the simple createAdapter function and see how that goes.

Also, if you want a really nice experience managing state with state adapters, I would recommend you look into using the other StateAdapt libraries. I have an RxJS library that hooks into Redux Devtools; you can see me using it in SolidJS and Svelte in this video (look at the timestamps). There's also an Angular library built on top of RxJS. And there's a React library too, although it could use some refining.

StateAdapt 1.0 hasn't been released yet, so be aware that this isn't production ready. However, it's very close. After I've applied the entity adapter to a few projects, I will be releasing 1.0.

Thanks for reading! Let me know what you think.

I changed my mind. Angular needs a reactive primitive

Mike Pearson — Wed, 07 Dec 2022 08:18:55 +0000

YouTube

Angular developers have waited 7 years for better integration with RxJS, but this doesn't seem to be happening. Instead, the Angular team wants its own reactive primitive that can't even handle asynchronous reactivity.

This made me angry at first, but after a lot of thinking and talking with other developers, I now believe that a reactive primitive could provide an overall better developer experience than just better RxJS support, even for the most diehard RxJS fans.

Better promises?
A split in the Angular community
Rejecting vs outgrowing NgRx
Angular is not reactive enough
You turned them against me!
Ryan Carniato
Oh yeah, RxJS actually sucks at that
Selectors
Colocation
SolidJS signal syntax is awesome
What I want
RxJS compatibility is still necessary
Summary and conclusion

Better promises?

Most Angular developers didn't even know about RxJS until Angular made them learn it for some core Angular APIs.

At first, most of us thought observables were just a nicer version of promises, since they could do everything promises could do, but also return multiple values over time. So we thought we would just get HTTP data like http.get(...).subscribe(data => this.data = data), and we could even handle websocket data the same way, but that would be the extent of RxJS's benefits. I think the Angular team thought of observables this way too.

But the ability to represent long-lived sources of data turned out to be far more than a slight improvement over promises. Observables enable functional reactive programming (FRP), where asynchronous code is defined declaratively. This is a huge deal. FRP can entirely eliminate race conditions and inconsistent state, improve code organization, reduce page load times, simplify state management and make naming easier. My last article explains all of this.

A split in the Angular community

But FRP requires adopting a different mindset in order to take advantage of these benefits. This is known as "thinking reactively." For most Angular developers, the opportunity to explore this mindset came with their first interactions with NgRx/Store.

Rob Wormald created NgRx in 2016 as a go-to state management library for Angular by combining Redux and RxJS. This seemed natural, because Redux was very popular in the React community, and the Redux store already came with a subscribe method, just like observables. It basically already was an observable waiting to be implemented with RxJS.

NgRx sounds really cool and powerful. It's probably really easy to use. Oh wait, how do you access current state? You can't just this.store.currentState?

Nope.

And what's more, there were no plans to add this. And there weren't even plans to plan on adding it either.

This turned out to be the result of some kind of RxJS doctrine. After further exploration, we encountered bizarre advice like "don't unsubscribe", and "don't subscribe". Can you imagine people telling you to not use .then with promises? But in RxJS, we're supposed to use withLatestFrom, takeUntil and Angular's async pipe instead. And if we use the async pipe, supposedly our apps can be more performant.

This was a fork in the road for Angular developers: Do I have something to learn, or is RxJS stupid because I can't do the first thing that came to my mind?

Rejecting vs outgrowing NgRx

Soon after NgRx introduced more RxJS into Angular apps, alternatives started popping up that appealed to developers who didn't want to learn how to think reactively, such as NGXS and Akita.

The split in the Angular community widened as other developers took RxJS and ran with it. I remember listening to a podcast where Rob Wormald (creator of NgRx and member of the Angular team) suggested that the future of Angular would be zoneless with RxJS streams stretching all the way from event sources down to the template.

This was very exciting to me. I imagined we'd eventually have precise updates fed directly into the DOM by RxJS streams, with no need for change detection at all. This would supercharge Angular performance, which was already starting to be on par with React. I hoped that this incredible performance boost would be enough enticement for more and more Angular developers to learn how to think reactively, which would then bring the other benefits of reactivity to more and more Angular codebases: No more race conditions or inconsistent state, improved code organization, reduced page load times, simpler state management and better function names.

But this future seemed a long time away, because I kept having to fight both NgRx and Angular when writing reactive code.

For example, if you had to hit 3 services in series to aggregate data for a page, you could do this with RxJS:

data1$ = this.http.get(...);

data2$ = this.data1$.pipe(switchMap(data1 => this.http.get(...));

data3$ = this.data2$.pipe(switchMap(data2 => this.http.get(...));

The benefit of this is that each data source is declarative, so it stands on its own, agnostic to how it may be used to define other state or features. This is extremely flexible, and has all the benefits of FRP I've already mentioned twice.

But if you want to put this data in NgRx/Store, the recommended solution is not very reactive, so it doesn't come with the full benefits of FRP. I ultimately came up with a way to wrap the NgRx API (dispatch & select) inside RxJS so I could structure my code exactly the same way I could with pure RxJS, and here is how it compared to the recommended pattern with NgRx/Effects:

I used this RxJS-first approach to rewrite a feature that was using effects heavily and reduced code by 25+% and the page load + render time by 90+%.

It took pro-reactivity Angular devs longer to outgrow NgRx than it took anti-reactivity devs to reject it. But we now have some RxJS-first libaries like RxAngular and StateAdapt, which are both state management libraries that enable maximum reactivity in Angular.

So, although both NgRx and Angular introduced developers to RxJS, they were both designed in ways that made full reactivity difficult. I mentioned one issue with NgRx, but Angular had a lot more.

Angular is not reactive enough

It is obvious that RxJS was sort of an afterthought in the design of Angular. It was used to represent event streams, such as component outputs. But it was also used for route parameters, which are states changing over time. But then component inputs, which are also states that change over time, were not represented as observables. RxJS in Angular is basically a really inconsistent experience.

When I hear some Angular developers complain about how cumbersome it is to use RxJS in Angular, I can actually empathize with them. But they should be blaming Angular, not RxJS. Some things that take 4 lines of code with RxJS + Angular only take a single character with RxJS + Svelte. Angular is the only major framework for which most component libraries require dialogs to be opened imperatively, which means the async pipe can't be used, requiring manual subscription management instead. Which is itself much easier in other frameworks.

I could go into a lot more detail, and I have before, but the main idea is this: Even after all the wrapper components and utilities I can create, I still can't fix Angular's core APIs.

You turned them against me!

I have waited a long time for Angular to improve its integration with RxJS. This issue, which was one of the all-time most upvoted Angular issues, was created in December 2015! The first hope it would be worked on was when the Ivy compiler was finally finished in 2019, but after another 2 years of relative silence, the issue was closed entirely! The reason? The Angular team said, "Turning inputs into Observables would more tightly couple Angular with RxJS, and we don't want to further couple with RxJS."

What???

The last comment on that issue before it was closed was by Minko Gechev, who started by reiterating the community split over RxJS: "As we've discussed in the past, the community is very split when it comes to using less or more RxJS with Angular." At the end of the comment he said, "We will share our plans for more ergonomic RxJS APIs when we prioritize that project." For someone who had already waited for 5 years for better Angular APIs, this was very frustrating, as he gave no timeframe at all. Not only that, but the primary reason given was that many Angular developers dislike RxJS, and I strongly believe that the primary reason for this is Angular's obnoxious integration with RxJS.

Then I saw that a member of the Angular team was exploring a different reactive primitive altogether. If Angular developers don't like reactivity, why would they prefer another reactive primitive over RxJS? If they don't like Angular's integration with RxJS, how would using a different reactive primitive help at all? None of it made sense to me.

Ryan Carniato

Another thing that has been bothering me has been Ryan Carniato's insistence that RxJS isn't fine-grained reactivity. I know that RxJS can be used to update the DOM in fine-grained ways, and it turns out Ryan knows it too, because he built a previous version of SolidJS with RxJS. I've been pestering him in the comment section of his YouTube streams for a few weeks now, and he finally gave me an explanation that caused something inside my head to click.

Ryan told me that the reason he calls RxJS "course-grained" reactivity is because, while you technically can perform fine-grained updates with it, people tend to combineLatest with streams instead. Is it fair to say that RxJS isn't fine-grained because people tend not to use it in fine-grained ways? I don't think so, but Ryan's main point was actually interesting. He caused me to make a mental connection that I had never made before.

Oh yeah, RxJS actually sucks at that

When I first used NgRx, I wanted to use RxJS for everything, so I relied heavily on the map operator for derived state. But nowadays, derived state is completely implemented with selectors in pretty much all NgRx projects. So, whereas modern NgRx will combine state from multiple reducers like this:

const selectItems = createSelector(state => state.items);
const selectFilters = createSelector(state => state.filters);

const selectFilteredItems = createSelector(
  selectItems,
  selectFilters,
  (items, filters) => items.filter(filters),
);

Originally I did it like this:

items$ = this.store.select(state => state.items);
filters$ = this.store.select(state => state.filters);

filteredItems$ = combineLatest(
  this.items$,
  this.filters$,
  ([items, filters]) => items.filter(filters),
);

I was pretty happy with this RxJS approach, until my team lead put a console log in the filter function and saw that it was being run 28 times and asked me why. I basically told him, "I have no idea, I swear FPR makes apps more performant."

My first idea was to use distinctUntilChanged. That reduced some of the reruns.

Then I realized that every single observable that chained off of filteredItems$ caused the filter function to run again. The solution? shareReplay(), except actually publishReplay(), refCount() because of some weird RxJS issue. That also reduced some of the reruns.

Then I realized that whenever both items and filters were changed at the same time, the combineLatest would run twice, once per input observable. This was inefficient, but also caused errors in some states, because it was annoying to handle the intermediate situations where one input had an updated value but the other didn't.

I really wanted to get RxJS to work with this. I was only a junior developer at the time, but I spent hours and hours trying to think a way around this problem with RxJS, and came to the conclusion that it had to involve schedulers, but I didn't understand how to actually make it work.

At that point, I began to question my goal. Look at all the work I've had to go through, and it still feels awkward. Do we really want to create custom operators to make nice syntax for all of this? Why doesn't RxJS make handling derived states easier? Would it be so bad just to use selectors?

There were a lot of other Angular developers struggling with this stuff at the same time I was, and all of us concluded that selectors were the way to handle derived state in NgRx.

Selectors

Every time I see a new state management library pop up, I check to see if they use selectors, or if they require you to use distinctUntilChanged, publishReplay, refCount, combineLatest and debounceTime. Most of them do, or you have to be okay with inefficient code. RxAngular is an exception with not requiring the debounceTime, since it gives you coalesceWith, which is awesome.

I never liked the syntax of selectors, but they seemed necessary to me. So when I designed my own state management library, StateAdapt, I wanted to find a better syntax for selectors. This is what I came up with:

// NgRx:
const selectItems = createSelector(state => state.items);
const selectFilters = createSelector(state => state.filters);

const selectFilteredItems = createSelector(
  selectItems,
  selectFilters,
  (items, filters) => items.filter(filters),
);

// StateAdapt:
const adapter = buildAdapter<State>()({})({
  items: s => s.state.items,
  filters: s => s.state.filters,
})({
  filteredItems: s => s.items.filter(s.filters),
})();

I used a proxy object s (stands for both state and selectors) that watches for the selector you're accessing and creates a more efficient memoization than createSelector.

I've been very happy with this approach. I have thought that nothing more was needed in Angular than RxJS for events and async logic, and selectors for synchronous, derived state.

But it turns out that selectors aren't perfect either.

Colocation

There are 3 types of selectors.

State selectors

These are selectors that simply select from a state object:

const selectItems = createSelector(state => state.items);

It makes sense to export these with the reducers that manage the state they're selecting from.

Derived selectors

These are selectors that combine state from multiple reducers/stores and calculate derived state. This is derived state that doesn't belong with the top-level state, and these selectors can contain a lot of business logic.

UI selectors

These take the derived state from the first 2 selectors and change the shape of the data to be convenient for consumption in a template.

For example, let's say I had some state that described a rectangle with a position like { x: 50, y: 200 }. If that needs to be rendered as a div with CSS like style="left: 50px; top: 200px" then we could have a UI selector like this:

itemWithStyle: s => ({ left: `${s.x}px`, top: `${s.y}px` }),

<div [ngStyle]="store.itemWithStyle$ | async"></div>

Then the component can stay lean and you can test this selector as a pure function by directly importing the state adapter and passing values to it. That's really nice. And where is a better place to put a pure function than in a selectors file where it can be tested as a pure function instead of as part of a component? And as part of a state adapter, it's reusable by default, whereas if you put the logic in the component template, you'd have to extract it in order to reuse it.

But after trying out putting UI selectors inside state adapters for a while now, I have decided that managing the same concern across 2 separate files was too awkward for the small benefit of having it in an adapter. It felt like I was polluting the derived selectors file with really boring UI concerns, and those UI concerns were more convenient colocated with the template anyway. Imagine if the template needed to implement this as an SVG. Wouldn't it be convenient to be able to edit this logic in the template instead of in a separate file? Also, in what situation would you want to reuse this UI logic? Probably when you want to reuse the component too, right?

But how do we define efficient derived state in the component? In StateAdapt it's actually not that hard, but it's not super easy either, and it definitely isn't convenient with the NgRx-style syntax.

Component inputs and the diamond problem

Another issue with both RxJS and selectors is the question of how to deal with component inputs.

For a long time, I just wanted component inputs as observables. But it turns out there's a small issue with this: If each component input gets a new value at the same time, each input observable would fire in succession, so if you needed to combine input values inside the component, a combineLatest would fire once for each input observable. Selectors can't help with this, since component inputs aren't part of the global store.

This problem actually has a name: The diamond problem.

But you know what does have really awesome syntax and handles the diamond problem perfectly? A reactive primitive that isn't RxJS: Signals.

SolidJS signal syntax is awesome

Here's a simple SolidJS component:

const CountingComponent = () => {
    const [count, setCount] = createSignal(0);
    const doubleCount = createMemo(() => count() * 2);
    return (
        <div onClick={() => setCount(count() + 1)}>
            Double count value is {doubleCount()}
        </div>
    );
};

Here's the same thing with Angular and RxJS:

@Component({
  selector: 'app-counter',
  template: `
    <div (click)="count$.next(count$.value + 1)">
      Double count value is {{doubleCount$ | async}}
    </div>
  `,
})
export class CounterComponent {
  count$ = new BehaviorSubject(0);
  doubleCount$ = this.count$.pipe(
    map(count => count * 2),
    distinctUntilChanged(),
    publishReplay(),
    refCount(),
  );
}

The SolidJS syntax is better for many reasons:

1. Derived or not?

In Angular you need to know you're going to have derived state in order to have a reason to use BehaviorSubject right off the bat. With SolidJS, all of your state that changes will be signals, and whether they eventually get used to derive other state does not matter. So you never need to rewrite a signal with different syntax after you first create it.

2. Recomputing

By default, SolidJS's signals will not recompute if the state they're derived from doesn't change. No need for distinctUntilChanged.

3. Shared

No matter how many signals are derived from a signal, it will not recalculate for each of them, unlike RxJS which runs a map function for each derived observable, unless you use publishReplay(), refCount().

4. Combining

When combining SolidJS signals, you don't need to define the dependency array up front like you would with NgRx selectors or combineLatest. You can just define it like c = createMemo(() => a() + b()).

And the issue with RxJS's combineLatest running once for each input is not a problem with signals. SolidJS signals wait for each dependency to finish running before they run. SolidJS signals elegantly handle the diamond problem.

Okay, now let's compare SolidJS with some examples using selectors. Here's the SolidJS code again:

const CountingComponent = () => {
    const [count, setCount] = createSignal(0);
    const doubleCount = createMemo(() => count() * 2);
    return (
        <div onClick={() => setCount(count() + 1)}>
            Double count value is {doubleCount()}
        </div>
    );
};

Let's try Angular with StateAdapt:

@Component({
  selector: 'app-counter',
  template: `
    <div (click)="count.increment()">
      Double count value is {{doubleCount$ | async}}
    </div>
  `,
})
export class CounterComponent {
  count = adapt(['count', 0], {
    increment: state => state + 1,
    selectors: {
      double: state => state * 2,
    },
  });
}

That's actually not bad! But it's a little more code than it has to be, as you'll see below.

Angular with NgRx would be too long, but you can imagine defining the selector in the component file:

@Component({
  selector: 'app-counter',
  template: `
    <div (click)="increment()">
      Double count value is {{doubleCount$ | async}}
    </div>
  `,
})
export class CounterComponent {
  selectDoubleCount = createSelector(
    selectCount,
    count => count * 2,
  );
  doubleCount$ = this.store.select(this.selectDoubleCount);

  constructor(private store: Store) {}
  //...
}

Basically, selectors get the job done efficiently, but I've never seen a way to use them with as little code as signals require.

Wouldn't it be nice to have a reactive primitive in Angular that's efficient by default, with minimal syntax?

What I want

How about this:

@Component({
  selector: 'app-counter',
  template: `
    <div (click)="count.set(count.get() + 1)">
      Double count value is {{doubleCount.get()}}
    </div>
  `,
})
export class CounterComponent {
  count = signal(0);
  doubleCount = memo(() => this.count.get() * 2);
}

SolidJS's tuple syntax isn't available, since we're assigning class properties here, but this is pretty good too.

And of course there should be a way to specify Angular inputs as signals:

@InputSignal: count!: Signal<number>;

RxJS compatibility is still necessary

Signals are great for synchronizing derived state, but RxJS is still necessary for asynchronous reactivity. If you have any nontrivial amount of experience using RxJS it should be obvious why, but I explain a lot more in this article.

So, it would be cool if the Angular team found a way to make converting from signals to observables extremely convenient:

export class CounterComponent {
  count = signal(0);
  doubleCount = memo(() => this.count.get() * 2);
  delayedCount$ = this.count.pipe(delay(1000));
}

The pipe would convert the signal to an observable and pass the arguments to the new observable's pipe method.

Since we're accessing an observable, hiding that pipe() logic behind a lazy import could be possible, and that would allow the RxJS code to not be loaded until it was needed.

Or Angular could copy how SolidJS does it:

const CountingComponent = () => {
    const [count, setCount] = createSignal(0);

    // signal to observable (`from` imported from 'rxjs'):
    const count$ = from(observable(count)); 

    // observable to signal (`from` imported from 'solid-js'):
    const countAgain = from(count$);
};

Summary and conclusion

I have some strong opinions, but I also seem to change my mind a lot. But it's not like I just love moving from each JavaScript fad to the next every month. It has taken a lot of experience and pain to form my opinions, and everything I learn adds onto them.

First I thought RxJS was just a slight improvement over promises.

Then I learned about the benefits of thinking reactively, and wanted to use RxJS everywhere.

Then I learned that synchronizing state was better done with memoized selectors than with RxJS. But for asynchronous logic, RxJS was amazing, and I wanted better APIs than what Angular and NgRx provided out of the box.

Then I encountered Ryan Carniato's version of fine-grained synchronous reactivity, as well as his streams about colocation in Marko 6, and lastly people's comments on the old Angular issue describing the diamond problem for component inputs. All of this was swimming around my head until my conversation with Ryan about RxJS's problems. That's when it all fell into place and I realized there was an important role for a reactive primitive that wasn't RxJS or selectors.

So,

RxJS is necessary for asynchronous reactivity.
Selectors are necessary for reusing state management patterns with state adapters.
A simple reactive primitive is necessary for simple, local, reactive state synchronization.

As I work to improve StateAdapt, I will need to figure out how the new reactive primitive fits into the state management picture. I will probably start by exploring how it can be used most easily with SolidJS.

We all have different pieces of the puzzle, and I have faith that the web development community will eventually find beautiful, declarative syntax and ways of efficiently training developers with the right mindset to take advantage of reactive programming, and our industry will become increasingly productive and enjoyable to work in.

Thanks for reading!

I'd love to hear your own personal experience with anything I've shared in this article.

Cover photo by Casia Charlie: https://www.pexels.com/photo/sea-dawn-landscape-nature-2433467/

5 reasons to avoid imperative code

Mike Pearson — Mon, 28 Nov 2022 10:30:03 +0000

YouTube

1. Inconsistent state

In an imperative app, events trigger event handlers, which are containers of imperative code. This imperative code is burdened with the responsibility of understanding and controlling features that often have nothing to do with the original event. Imperative code is written outside the context of the state it's controlling and all the other code that controls that state, which is scattered across other event handlers. This often results in naive update logic that fails to consider the whole picture or account for other downstream effects. This usually causes bugs from inconsistent state.

For example: This is a movies app with a search bar in the header. When you enter a search in, it calls an API and takes you to a page with the search results returned from the API.

Many of you are already in the habit of programming this reactively: Just change the URL and let the search results page contain its own logic that reacts to the URL by fetching the search results requested.

But this feature was structured more imperatively, with the search submit handler being responsible for both fetching the results and redirecting.

This caused a bug where if you were on the search results page and refreshed, there would be no search results, because that feature was unable to react to the URL correctly by itself.

Imperative code is buggy by default: If any unforeseen event triggers a state change, downstream state will remain stale and inconsistent.

On the other hand, when downstream state is reactive, it doesn't matter what caused the state change above it. It will always react.

If you think setting the URL first and handling the API request on the route page is a special case, you simply haven't noticed yet that imperative code is the cause of almost all inconsistent state. Hunt down the origin of every bug and you'll find that imperative code can account for as much as 40% of the bugs.

2. State elevation

The movie search feature illustrates another problem with imperative code: State has to be elevated to a level where the imperative code from other features can control it. If event handlers need access to state from other features, that state cannot be local; it has to be global.

This is where the original developer used NgRx/Component-Store. He created a global service/store that movie search submit handler could access and store the results of the API call.

The first issue with this is that it decoupled the search results state from the lifecycle of the component. If the search results observable was only used in the component that needed to react to it with the async pipe, it would have unsubscribed from that observable when navigating away. This would have either canceled the API request, or when revisiting the route it would have created a new request.

Instead, there had to be extra logic to reset the search results, and in-flight requests were just left un-cancelled.

The second issue with this is that state accessible to every feature is potentially being changed by every feature, and you won't know until you check.

3. Large bundles

The rule of reactivity is that everything that can be downstream should be downstream. This is naturally lazy behavior.

The only framework I know of that makes taking advantage of this easy is Qwik. But even in Angular, it's easy to take advantage of code that's reactive to URL changes, because routes are very easy to lazy-load.

Unless you're using Qwik, every lazy-loaded code bundle probably contains the code of all of its event handlers. Since event handlers are often busy referencing and changing other features, this means those other features need to be included in this bundle too.

So, if you can, try to have event handlers change the URL and have everything else react to that.

4. Unnecessary complexity

State that's controlled externally by callback functions relies on those functions to control it in every scenario. This decentralization of control creates duplicated control. In this diagram from earlier, you can see that every new event will require 2 more arrows:

Every arrow that causes State Change 1 must be duplicated for State Change 2. This bloats the codebase.

But does the imperative code really have to be this way? Maybe we can improve it. Let's look at an example and try to make it DRY.

In this example, we'll have carModel as our State 1, and various derived states. We could create a central function for updating carModel called changeCarModel that includes an update to the derived states.

  changeCarModel(newCarModel: CarModel) {
    this.carModel = newCarModel;
    this.zeroToSixtyTime = this.zeroToSixtyTimes[newCarModel];
    this.price = this.prices[newCarModel];
    this.electricRange = this.ranges[newCarModel];
    this.canDriveLaToFresno = this.electricRange > 270 ? 'Yes' : 'No';
  }

One of the benefits of reactive code is that the update logic is next to the state it's relevant to. Can we achieve this with imperative code too? We already have a function for changing carModel right next to it, so can't we just extract the downstream state change logic to individual functions that live next to those other states themselves too? Then we can just invoke those functions from the end of changeCarModel. Let's define the update functions as arrow functions so we can put them right next to their states:

  carModel = 'Chevy Volt' as CarModel;
  changeCarModel = (newCarModel: CarModel) => {
    this.carModel = newCarModel;
    this.changeZeroToSixtyTime(newCarModel);
    this.changePrice(newCarModel);
    this.changeElectricRange(newCarModel);
  };

  changeZeroToSixtyTime = (newCarModel: CarModel) => {
    this.zeroToSixtyTime = this.zeroToSixtyTimes[newCarModel];
  };
  zeroToSixtyTime = this.zeroToSixtyTimes[this.carModel];

  changePrice = (newCarModel: CarModel) => {
    this.price = this.prices[newCarModel];
  };
  price = this.prices[this.carModel];

  changeElectricRange = (newCarModel: CarModel) => {
    const newElectricRange = this.ranges[newCarModel];
    this.electricRange = newElectricRange;
    this.changeCanDriveLaToFresno(newElectricRange);
  };
  electricRange = this.ranges[this.carModel];

  changeCanDriveLaToFresno = (newElectricRange: number) => {
    this.canDriveLaToFresno = newElectricRange > 270 ? 'Yes' : 'No';
  };
  canDriveLaToFresno = this.electricRange > 270 ? 'Yes' : 'No';

Look at that! changeCarModel no longer needs to worry about canDriveLaToFresno, because changeElectricRange calls that update function on its own! And this is all imperative code! Everything follows this pattern:

updateDerivedState = (aboveState: AboveState) => {
  // Update this.derivedState
  // Call update functions for states that derive from this state
}
derivedState = initialDerivedState;

But you know what, there's sort of a circular dependency going on here. The derived state has to know about the state it's derived from, because it wouldn't exist in the first place if it weren't for the state it uses to derive itself. But the top-level state function needs to know about and directly call the derived state update functions below. What can we do about this?

Derived state knowing about state it's derived from reflects the natural relationship between the state and derived state. It's similar to how vanilla JavaScript works when you declare initial values for variables:

const a = 5;
const b = a * 10;
// Notice that `a`'s declaration includes nothing about `b`.

So it seems like the odd part of the circular dependency we've created is that our top-level state has to reference the state change functions below it. Can we get rid of that?

What if we came up with a generic mechanism the top-level state could use to update its derived states without actually referencing them? We could define an empty array that derived states can add their update functions to. The central changeCarModel function could just loop through the array, calling each function with its new value for carModel. This would allow any derived state to just add its update function to that array and have it get called whenever changeCarModel runs. Here's what that looks like:

  carModel = 'Chevy Volt' as CarModel;
  carModelUpdates = [] as ((newCarModel: CarModel) => void)[];
  changeCarModel = (newCarModel: CarModel) => {
    this.carModel = newCarModel;
    this.carModelUpdates.forEach((update) => update(newCarModel));
  };

 // Assign dummy property just so we can run this code here
  dummyProp1 = this.carModelUpdates.push((newCarModel: CarModel) => {
    this.zeroToSixtyTime = this.zeroToSixtyTimes[newCarModel];
  });
  zeroToSixtyTime = this.zeroToSixtyTimes[this.carModel];

  // etc...

Guess what? We basically just invented observables. Those update functions are like observers in RxJS.

Let's refactor completely to observables and compare it with what we just came up with:

Pretty similar, but RxJS abstracted away the subscription mechanisms so all that's left is our business logic. And it's even more DRY now that initial values aren't treated as a special case.

So how did we get here?

Make imperative code more DRY by centralizing state change code next to state
Achieve the same thing for derived state while also improving separation of concerns, by moving derived state's update logic next to the derived state
Remove pseudo-circular dependencies between state and derived state and improve separation of concerns further by making state agnostic about state that is derived from it
Make code even more DRY by using RxJS

Every step that improves imperative code moves it closer to reactivity. This means the only way to fundamentally improve imperative code is to have less of it.

Let's review the basic rule of reactivity again: Everything that can be downstream should be downstream. This goal is the exact same as that 4-step process we just went through, and it is the best way to get as minimal and simple state management as possible. Downstreaming improves code at every stage.

And since reactive code is located next to the feature it controls, logically similar code will be grouped together, so it's easy to find opportunities to condense repeated logic. This is much harder with scattered, imperative code. In the app I refactored, the first event handler had these two imperative commands next to each other in an event handler:

    this.store.switchFlag(false);
    this.router.navigate(['/']);

At first I had no way of knowing that switchFlag was only ever called at the same time.

After I had refactored to reactivity, it became obvious that store.flag was downstream from the app's URL; it was a flag to determine whether the app was supposed to be on a certain route. You might think this is a ridiculous example, but it's real code that was written, and I really couldn't see how to simplify it until I made it reactive.

Clean code is reactive code.

Here's the repository for the example in this section. And for fun, here's the diff when I convert the RxJS version to StateAdapt, the state management library I created:

Bad function names

Functions are things that do stuff. That's what they are. So their names should reflect that, right? But if you saw this in a template, could you tell me what it does?

(click)="onClick()"

No. Rather than being named for what it is, this event handler, like most tend to be, is named for how or when it is called.

I know this is extremely common, so at this point I'll cite an authority that might trump tradition. From the classic and extremely authoritative book Clean Code:

Methods should have verb or verb phrase names like postPayment, deletePage or save.

Is onClick a verb? Does it describe what the function is or does? No. It describes an instance in time, when a thing is clicked. All you know when you see a function called onClick is that it is called... on click.

Wouldn't a function name like this be easier to understand?

(click)="refreshData()"

Hopefully you agree with me that that is a better name than onClick.

Alright. Can you help me come up with a better name for this function than onSubmit?

This is color-coded according to what state is being affected.

Can you come up with a single name that describes what this function does? Here's my best attempt:

ifValidDeleteMoviesFetchAndSaveMoviesAndSaveSearchHeaderFlagAndNavigateElseShowAlert() {
  // ...
}

That is a function name that almost describes everything happening in the function. But it's long. Maybe we can shorten it by extracting commonality from multiple steps and describing the common effect instead of every detail:

validateAndClearSearchAndSaveNewSearchDataAndNavigate() {
  // ...
}

Now we could become philosophers and eventually come up with something that describes the overall essence of what's happening, but that would take a lot of time. So it's easy to understand why we're always naming event handlers by when they get called instead of by what they do.

Another technique I've seen is to just pick our favorite behavior from the function and simply ignore everything else:

  navigateBack() {
    this.store.deleteMovies();
    this.store.switchFlag(false);
    this.router.navigate(['/']);
  }

navigateBack? There seems to be more going on there.

Again, this isn't the original developer's fault.

The problem is that all these things need to be done, but they have little in common with each other.

The problem is imperative code.

In an imperative app, events trigger event handlers, which are containers of imperative code. This imperative code is burdened with the responsibility of understanding and controlling features that often have nothing to do with the original event. The event handler requires an umbrella name that covers everything inside it. This can be so difficult that the best name for the function truly is something hollow, like onSubmit.

Reactive code doesn't have this problem.

I refactored that onSubmit code to be reactive and here is what some of the code became:

Do you know how hard it was to come up with the name url$? Not hard at all. Because that's what it is. It might change over time, and it might be derived using other observables, but it still is just an observable of the URL.

Reactive code is declarative, meaning, it declares all its own behavior instead of relying on other code to control it. When no code is reliant on other code to control it, everything can just be concerned with itself only. Nothing is burdened with downstream effects or concerns, so you never have to come up with names that include downstream effects or concerns.

Conclusion

There are many reasons to program reactively. This is why the history of web development has followed an overall trend towards more and more reactivity.

But it's taking a long time. Most developers are still confused about what reactivity even is. Some think that synchronous reactivity covers reactivity completely, forgetting that asynchronous code can also be reactive with tools like RxJS and React Query.

So why is it taking developers so long to get on board with fully reactive programming?

I think it's because JavaScript developers are trained to code with an imperative mindset, because JavaScript 101 includes almost exclusively imperative APIs. I used to think all new developers should start with JavaScript 101, but I'm having second thoughts about that... What would a reactivity-first tutorial look like?

I also think it's hard to stray too far from the dominant style in the ecosystem you work in. For example, if you're using Angular Material and you notice that RxJS is tricky to work with whenever you use a dialog component, you might mistakenly blame RxJS for the bad experience instead of the outdated API for MatDialog.

For most developers, programming reactively will require a big shift in mindset. It will also require some tools and wrapper components.

But every feature I've refactored to reactivity has become simpler, less buggy and more performant.

So I think it's worth it.

How to refactor to reactivity

Mike Pearson — Mon, 21 Nov 2022 10:28:20 +0000

I just finished rewriting an app from imperative code to completely reactive code. Here's the process I followed.

1. The first event handler

I started with a single event and removed its handler. The handler was modifying the URL and 2 pieces of state in the global NgRx/Component-Store. So, I changed the (click)to a [routerLink] and had the state changes react to the URL change:

    const urlFromMovieDetailToHome$ = this.router.events.pipe(
      filter((event): event is NavigationEnd => event instanceof NavigationEnd),
      pairwise(),
      filter(
        ([before, after]) =>
          before.url === '/movie' && ['/home', '/'].includes(after.url)
      ),
    );

    // ...

    this.react<AppStore>(this, {
      deleteMovies: urlFromMovieDetailToHome$.pipe(map(() => undefined)),
      switchFlag: urlFromMovieDetailToHome$.pipe(map(() => false)),
    });

This react method turned out to be unnecessary... I missed the part in NgRx/Component-Store's documentation that says updates can take in observables. So it could have been this:

    this.deleteMovies(urlFromMovieDetailToHome$.pipe(map(() => undefined)));
    this.switchFlag(urlFromMovieDetailToHome$.pipe(map(() => false)));

Anyway.

Do you see that weird URL code I wrote? It's totally fine, and it worked. But maybe it should have been an early sign that the state reacting to the URL should have been in the route itself and not in a global store. But I didn't do anything with that, because there were still other event handlers modifying it from other components. And it was totally fine working the way it was.

2. More event handlers

I went from from component to component converting them to reactivity, but each component happened to only have one event handler, so it ended up being the same as moving from handler to handler. I actually think it would be better in general to move from handler to handler and worry about the rest of the component code later.

After I converted a couple of event handlers to have state react on its own instead, I noticed there was nothing preventing me from moving some state out of the global store and colocating it with the feature that was using it. I also noticed that multiple pieces of state would always react to the same things, and some of it could be turned into derived state, which is downstream from (reacts to) other state. This is easy to see when all the code that controls state is colocated with the state.

At this point the code began to simplify a lot.

After I converted the last component to reactivity, I realized that the global store wasn't even necessary. So I moved state into the related features, and it ended up being 32% less code in total.

Although there are probably many ways to approach this process, this is what I like:

Find an event handler
Delete it
Have the event make a single change instead
Get the next state changes to react to that immediate, single change
Find the state with the fewest remaining event handlers changing it, move to one of them and repeat steps 2-4
If all of a state's old handlers are gone, move it as close as possible to the features that use it
Repeat steps 1-6 for the features using the state that is now completely reactive until all its features are reactive

3. Wrapping imperative APIs

Some features have imperative APIs. In order to completely get rid of imperative code, you need to wrap these APIs with declarative APIs.

In the first 2 articles in this series I described how I wrapped 2 imperative APIs with declarative ones.

The first was router.navigate. I created a wrapper component that can be used like this:

<app-navigate [url]="url$ | async"></app-navigate>

The second was a Sweet Alerts wrapper component that can be used like this:

<app-swal
  [options]="{}"
  [show]="alertIsVisible$ | async"
  (close)="alertClosed$.next()"
></app-swal>

There was a 3rd imperative API I haven't described yet: The image carousel. It used to be controlled like this:

  @ViewChild('carousel', { static: true }) carousel!: NgbCarousel;
// ...
  togglePaused() {
    if (this.paused) {
      this.carousel.cycle();
    } else {
      this.carousel.pause();
    }
    this.paused = !this.paused;
  }

I realized I could just change the interval it was looping by instead (got the idea originally from Josh Moroney actually; I think it's great):

  pausedAdapter = buildAdapter<boolean>()(booleanAdapter)({
    interval: (s) => (s.state ? 9999999 : this.config.interval),
  })();

This is StateAdapt syntax by the way. interval becomes available as an observable on the store that uses pausedAdapter. Here's that store:

  paused = adapt(['carousel.paused', false, this.pausedAdapter], {
    setFalse: this.arrow$,
    setTrue: this.indicator$,
  });

And here I'm using it in the template:

  [interval]="(paused.interval$ | async) || config.interval"

Using declarative APIs for these features was extremely nice. I'm so sick of interrupting my nice, clean RxJS streams with manual subscriptions for imperative APIs. Let's do something about it!

Diagrams

Here are diagrams that show the data flow before and after I refactored the app. To see me walk through these in detail, watch the YouTube video below the diagrams.

Thanks for reading! Please give StateAdapt a look if you haven't yet. Version 1.0 is coming out within a month!

Pushing Angular's Reactive Limits: Event Context & Toasts/Dialogs

Mike Pearson — Wed, 16 Nov 2022 16:38:25 +0000

YouTube

In an imperative app, events trigger event handlers, which are containers of imperative code. This seems to be the most common approach in Angular apps, unfortunately. A typical app might have a function like this:

  onSubmit() {
    if (this.form.valid) {
      this.store.deleteMovies();
      this.headerService
        .searchMovies(this.form.value)
        .subscribe((data: any) => {
          // ...
          this.store.saveSearch(data.results);
          this.store.saveSearchHeader(this.form.value);
          this.store.switchFlag(true);
          this.router.navigate(['/search']);
        });
    } else {
      swal({ // toast
        title: 'Incorrecto',
        // ...
      });
    }
  }
}

That event callback is controlling 5 pieces of state:

store.search
store.header
store.flag
the app's URL
the invalid toast

This isn't great separation of concerns, because logic that controls each of those 5 pieces of state is scattered across many callbacks such as onSubmit, so to understand why anything is the way it is at a given time, you have to refer to many locations across the codebase. Basically, you need "Find All References", which can get really annoying.

So getting rid of event handlers/callbacks seems like a good potential place to start refactoring to more reactivity.

And what would the reactive version look like?

A simple rule for reactivity is this: Every user event in the template pushes the most minimal change to a single place in our TypeScript, then everything else reacts to that. Here's a diagram of that:

Not only is the code immediately downstream from the event source much simpler, but everything that can be downstream from something else is. This maximizes reactivity. In general, diagrams of reactive data flows will be taller and skinnier than diagrams of imperative data flows. You can actually see the improved separation of concerns.

(I haven't looked into this yet, but I suspect that even store.header and store.flag might be downstream from store.searchResults.)

The logic that controls each piece of state has been moved next to the state it controls. This makes it easier to avoid bugs, since we can easily refer to similar logic when writing new logic to control state.

Reactive Implementation

First, let's say we create a subject to represent the form submission:

search$ = new Subject<[boolean, string]>();

        <input
          type="submit"
          value="Buscar"
          class="submit"
          (click)="search$.next([form.valid, form.value.search])"
        />

Why did I give it a payload whereas the previous event handler onSubmit took no parameters?

Event Context

The Reason to pass the form data into the search$ event is flexibility: The previous event handler actually needed form.valid and form.value; it was just implicitly referenced. This makes it require refactoring if a developer wanted to move it to a service or something.

One problem people often have with reactive state management like StateAdapt or NgRx is that state is siloed into independent slices (or reducers, or stores). Sometimes in order to calculate a state change, you need to know the state of another state reducer/store. So what do you do? Refactor everything into one giant reducer/store?

The simple answer is to provide context with the event that is causing the state change.

Navigation

We now have 2 pieces of state immediately downstream from search$:

Like in the previous component, we need to split our stream into 2 pieces again. Again, I'll just use filter instead of partition.

Also... It's much more convenient to pass in a URL string and have app-navigate just react to that. In the last article I was thinking through this for the first time, and I believe I came up with an API that is less than ideal. So, rather than having a separate observable to trigger the router.navigate call, the mindset will be state-centric: The job of the router wrapper component is to ensure that the browser URL is in sync with the url input passed into it.

First, here's how I define the observables that chain off of search$:

  search$ = new Subject<[boolean, string]>();

  searchIsInvalid$ = this.search$.pipe(map(([valid]) => !valid));
  url$ = this.search$.pipe(
    filter(([valid]) => valid),
    map(([, search]) => `search/${search}`)
  );

Now I can feed url$ into the app-navigate component:

<app-navigate [url]="url$ | async"></app-navigate>

Also, here's the new source code for that component:

import { Component, Input, SimpleChanges } from '@angular/core';
import { Router, RouterModule } from '@angular/router';

@Component({
  standalone: true,
  selector: 'app-navigate',
  template: '',
  imports: [RouterModule],
})
export class NavigateComponent {
  @Input() url: string | null = null;

  constructor(private router: Router) {}

  ngOnChanges(changes: SimpleChanges) {
    const urlChange = changes['url'];
    const newUrl = urlChange?.currentValue;
    if (newUrl) {
      this.router.navigate([newUrl]);
    }
  }
}

That's actually smaller and simpler than it used to be. I like it.

Now I'll refactor the component from the last article to map to a URL instead of selectedMovieNull$:

  url$ = this.store.movieSelected$.pipe(
    filter((movie) => movie == null),
    map(() => '/')
  );

I added a route parameter to the search route, since search is being tracked there now.

And I just discovered that the store.header state was the search query string. So apparently I have merged it in with the URL, and I can get rid of it in the store. It actually was never being used anywhere anyway, it turns out. I love refactoring random projects from GitHub :)

Toasts

I'm only now realizing that swal actually means "Sweet Alert" and this is a modal being opened, not a toast. But it doesn't matter. Everything in the UI should be declarative, and this might as well be a toast.

So let's make a wrapper component we can pass into a swal function call:

import { Component, Input, SimpleChanges } from '@angular/core';
import { SwalParams } from 'sweetalert/typings/core';
import swal from 'sweetalert';

@Component({
  standalone: true,
  selector: 'app-swal',
  template: '',
})
export class SwalComponent {
  @Input() show: boolean | null = false;
  @Input() options: SwalParams[0] = {};

  ngOnChanges(changes: SimpleChanges) {
    const showChange = changes['show'];
    const newShow = showChange?.currentValue;
    if (newShow) {
      swal(this.options);
    }
  }
}

This could evolve over time, but this is good enough for our purposes.

Now I can use it in the template and the search/header component is completely converted to reactivity:

        <app-swal
          [options]="{
            title: 'Incorrecto',
            text: 'Debes ingresar al menos dos caracteres para hacer una búsqueda..',
            icon: 'warning',
            dangerMode: true
          }"
          [show]="searchIsInvalid$ | async"
        ></app-swal>

This has a bug apparently. It only opens once, then never opens again. This is because we are not resetting the state we're passing into the swal wrapper component, so ngOnChanges is not reacting to it.

In order for this to work correctly, we'd need to handle a callback function from the swal alert and have it update an observable to be merged back into its input so a false value would be passed in.

I decided to go ahead and implement this. Here's the new swal wrapper component:

import {
  Component,
  EventEmitter,
  Input,
  Output,
  SimpleChanges,
} from '@angular/core';
import { SwalParams } from 'sweetalert/typings/core';
import swal from 'sweetalert';

@Component({
  standalone: true,
  selector: 'app-swal',
  template: '',
})
export class SwalComponent {
  @Input() show: boolean | null = false;
  @Input() options: SwalParams[0] = {};
  @Output() close = new EventEmitter<any>();

  ngOnChanges(changes: SimpleChanges) {
    const showChange = changes['show'];
    const newShow = showChange?.currentValue;
    if (newShow) {
      swal(this.options).then((value) => this.close.emit(value));
    }
  }
}

Now we need to change the state we pass in to always reflect the state of whether that alert is open.

In this case, the simplest way of tracking the dialog state I can think of is using StateAdapt. This is because it needs to react to an observable searchIsInvalid$ but also be able to be set directly from the template. Remember, from the template, something imperative always needs to happen anyway, so we might as well be direct with it.

To use StateAdapt, we first need this in our AppModule:

import { defaultStoreProvider } from '@state-adapt/angular';
// ...
  providers: [defaultStoreProvider],

Now we can use it in the component like this:

import { booleanAdapter } from '@state-adapt/core/adapters';
import { toSource } from '@state-adapt/rxjs';
import { adapt } from '@state-adapt/angular';

// ...

  searchIsInvalid$ = this.search$.pipe(
    map(([valid]) => !valid),
    toSource('searchIsInvalid$')
  );
  invalidAlertOpen = adapt(
    ['invalidAlertOpen', false, booleanAdapter],
    this.searchIsInvalid$
  );

        <app-swal
          [options]="{
            title: 'Incorrecto',
            text: 'Debes ingresar al menos dos caracteres para hacer una búsqueda..',
            icon: 'warning',
            dangerMode: true
          }"
          [show]="invalidAlertOpen.state$ | async"
          (close)="invalidAlertOpen.setFalse()"
        ></app-swal>

And as an added benefit, we get this state tracked in Redux Devtools:

How weird is that? The first state tracked in Redux Devtools in this entire app is an alert dialog, and it wasn't even managed as state before.

Downstream NgRx/Component-Store Changes

Alright, the component is working great, now we need to move on to the next level downstream:

This is all going to be defined in app.store.ts, because that's what it affects.

First let's trigger deleteMovies when the route is first entered. There's some logic we previously defined that I'm going to split out so we can reuse it. Here's what I have now:

    // New
    const urlAfterNav$ = this.router.events.pipe(
      filter((event): event is NavigationEnd => event instanceof NavigationEnd),
      map((event) => event.url)
    );

    // From before:
    const urlFromMovieDetailToHome$ = urlAfterNav$.pipe(
      pairwise(),
      filter(
        ([before, after]) =>
          before === '/movie' && ['/home', '/'].includes(after)
      )
    );

    // New
    const searchRoute$ = urlAfterNav$.pipe(
      filter((url) => url.startsWith('/search'))
    );

Nice.

I'm getting a bug as well. It turns out switchFlag needs to be called immediately too. So, I'm going to trigger both state reactions with this new observable:

    this.react<AppStore>(this, {
      deleteMovies: merge(urlFromMovieDetailToHome$, searchRoute$).pipe(
        map(() => undefined)
      ),
      switchFlag: merge(
        urlFromMovieDetailToHome$.pipe(map(() => false)),
        searchRoute$.pipe(map(() => true))
      ),
    });

If you're confused about this block of code, see the last article where I explained react. Hopefully it's somewhat self-explanatory, but just know that the keys of the object passed in are names of state change functions in this NgRx/Component-Store, and they get called and passed the values emitted from the observables on the right-hand side.

Now we just need to define the results$ observable as chaining off of the search term in the URL:

    const searchResults$ = searchRoute$.pipe(
      switchMap((url) => {
        const [, search] = url.split('/search/');
        return this.headerService.searchMovies({ search });
      }),
      map((res: any) =>
        res.results.map((movie: any) => ({
          ...movie,
          poster_path:
            movie.poster_path !== null
              ? `${environment.imageUrl}${movie.poster_path}`
              : 'assets/no-image.png',
        }))
      )
    );

This takes the URL, grabs the search query from it, passes it to the MovieService and loops through the results giving each movie a default poster image. This logic existed already, including those unfortunate any types. I don't feel like fixing that right now.

And we can plug this observable into the react method now:

saveSearch: searchResults$,

saveSearch should probably be named receiveSearchResults, but I'm going to ignore that for now too.

Conclusion

Everything works again! And it's reactive now! Here's the final commit.

The main takeaway from this is the lesson I learned from creating the SwalComponent and refactoring the AppNavigateComponent: Angular inputs should represent state, not events. This is more declarative anyway, so I'm happy with the way these wrapper components are now.

Yes, it does take work to create these wrapper components and integrate them properly. But it enables a much more flexible data flow with better separation of concerns.

Previously, there were 11 imperative statements, and lots of mixed concerns, as you can see from this screenshot:

The new reactive implementation only has 2 imperative statements, both from the template, so, unavoidable. But the reactive data flow introduced better separation of concerns, as you can see:

Notice here that we now have multiple sources of state changes in one place, including the state changes we added when refactoring the first component. At the end of this refactor project, maybe I should come up with a way to show visually how across multiple files, state change logic became centralized next to the state it was changing. That might be cool.

Another thing to notice is that I'm not showing all the code I created while refactoring. That is because it is represented in the variable name instead. If you look at just this line:

      saveSearch: searchResults$,

You know that the state will change as described by saveSearch when searchResults$ emits. The name searchResults$ tells you what you need to know, and if you want to know more details, you can use "Click to Definition" and look at it.

Everything that will cause search results to be updated will be right here. So far this is the only one. But if we add another, it might look like

      saveSearch: merge(searchResults$, moreSearchResults$),

On the other hand, the only way to know why search results changed in an imperative project would be to use Find All References on the saveSearch method. You don't even know the names of the callback functions that are controlling it until you do that.

Not only that, but a callback function like onSubmit gives you no clue what it actually does or what state it modifies. It's a bad name for a function; ideally you could have something in the template like (submit)="saveToServer()", but what if that's not the only thing that has to happen? With callback functions, which are containers of imperative code, you can only give it the name of the commonality of all of its effects. It happens to be that quite often the only name people can come up with is the circumstance or context in which the callback function is called. This violates Clean Code's advice for good function names, which says that functions should be named for what they do.

Good names come more easily with declarative programming, because the things you have to name are only concerned with themselves.

So, how much code was that? git diff --stat says 79 insertions and 62 deletions.

I'm beginning to doubt that this will be less code by the end. I increased the lines of code a lot when I changed

      swal({
        title: 'Incorrecto',
        text: 'Debes ingresar al menos dos caracteres para hacer una búsqueda..',
        icon: 'warning',
        dangerMode: true,
      });

  searchIsInvalid$ = this.search$.pipe(
    map(([valid]) => !valid),
    toSource('searchIsInvalid$')
  );
  invalidAlertOpen = adapt(
    ['invalidAlertOpen', false, booleanAdapter],
    this.searchIsInvalid$
  );

and

        <app-swal
          [options]="{
            title: 'Incorrecto',
            text: 'Debes ingresar al menos dos caracteres para hacer una búsqueda..',
            icon: 'warning',
            dangerMode: true
          }"
          [show]="invalidAlertOpen.state$ | async"
          (close)="invalidAlertOpen.setFalse()"
        ></app-swal>

That's going from 6 to 18 lines of code. That's most of the difference, actually.

But since we now have something in Redux Devtools, and we separated the concern of the dialog from the other updates that onSubmit was burdened with, I think this was worth it.

I guess we'll see how things compare in the end! There are still 2-3 components to refactor.

Pushing Angular's Reactive Limits: Router and Component Store

Mike Pearson — Mon, 14 Nov 2022 19:26:16 +0000

YouTube

  navigateBack() {
    this.store.deleteMovies();
    this.store.switchFlag(false);
    this.router.navigate(['/']);
  }

That event callback is controlling 3 pieces of state: store.movies, store.flag and the app's URL.

This isn't great separation of concerns, because logic that controls what store.flag and store.movies are is scattered across many callbacks such as navigateBack, so to understand why anything is the way it is at a given time, you have to refer to many locations across the codebase. Basically, you need "Find All References", which can get really annoying.

So getting rid of event handlers/callbacks seems like a good potential place to start refactoring to more reactivity.

And what would the reactive version look like?

As you can see, the logic that controls each piece of state has been moved next to the state it controls. This makes it easier to avoid bugs, since we can easily refer to similar logic when writing new logic to control state.

Reactive Implementation

Now the question is how to implement this in code.

First, let's say we create a subject to represent the clicks on the back button:

backClick$ = new Subject<void>();

Now that we have an observable, what do we do with all these methods from the imperative click handler?

    this.store.deleteMovies();
    this.store.switchFlag(false);
    this.router.navigate(['/']);

The particular app I'm working on is using NgRx/Component-Store, which, unfortunately, does not give us a way to update state reactively; there's nowhere to plug in our click source observable, so we have to call methods on a class.

We have 3 options that I know of: Create a custom wrapper around NgRx/Component-Store that lets us plug in observables; migrate to RxAngular/State; or migrate to StateAdapt, which isn't even on version 1.0 yet. I think the obvious choice is going to be StateAdapt, since I made it and I love it 😀 (btw: 1.0 is coming within a month 🤞)

Edit: NgRx/Component-Store actually can take in observables to update state, but I like the override I created for select because it passes subscriptions through to the update observables, just like StateAdapt.

Router State

But wait. What do we do about the router? There's no reactive alternative to this method:

    this.router.navigate(['/']);

In my series on progressive reactivity in Angular, I wrote an article called Wrapping Imperative APIs in Angular. I complained about the Angular ecosystem lacking a lot of declarative APIs. For example, Angular is the only front-end framework out of the 9 most popular where every component library I've seen uses imperative APIs for opening and closing dialogs:

Framework	Library 1	Library 2	Library 3
Vue	✅ Declarative	✅ Declarative	✅ Declarative
React	✅ Declarative	✅ Declarative	✅ Declarative
Svelte	✅ Declarative	✅ Declarative	✅ Declarative
Preact	✅ Declarative	✅ Declarative	✅ Declarative
Ember	✅ Declarative	✅ Declarative	✅ Declarative
Lit	✅ Declarative	✅ Declarative	✅ Declarative
SolidJS	✅ Declarative	✅ Declarative	---
Alpine	✅ Declarative	---	---
Angular	❌ Imperative	❌ Imperative	❌ Imperative

We shouldn't just accept this because this is how things have always been in Angular. Instead, we should create wrapper components that can be used declaratively in templates and abstract away the imperative this.dialog.open() method calls.

But what about router state?

I'm not aware of any front-end framework that has a way to have the URL react to application state. That doesn't itself mean it's a terrible idea, but maybe it is.

I've thought quite a bit about this and can't decide what to do. So let's think through this more now.

First of all, it's not a good idea to have a central place where all sources of navigation events from the entire app are directly imported and combined into a stream and passed into a declarative API. The reason is because many features need to be lazy-loaded, and importing the entire app in one place would undermine that.

Instead, something like the way declarative dialogs work might be a good idea: Yes, there is something central being controlled (the global modal element & backdrop), but it is easy to provide a wrapper component that can be used in any component, and pretend the modal is being opened right in the component triggering it:

<h1>Some Component Template</h1>
<dialog [open]="dialogIsOpen$ | async">
  <app-dialog-content-component></app-dialog-content-component>
</dialog>

Could we do something like that for navigation? How's this:

<h1>Some Component Template</h1>
<button (click)="backClick$.next()">Back</button>
<app-navigate url="/" when="backClick$"></app-navigate>

You know what... That reminds me of something:

<a routerLink="/">Back</a>

So it turns out it is okay to navigate declaratively in the template! It's just that whenever we do it typically, there's a tight, closed loop from the click to the navigation. Is it okay to loosen that loop a little bit with that app-navigate component?

Let's imagine we load a route, and then for some reason the app navigates away from it. Would it be easier to figure out why if the navigate method was being called in the component class rather than by a component in the template?

Well, any component in the template might be calling the navigate method internally anyway, since the router can be injected anywhere... And the fact that the wrapper component's selector would be app-navigate makes it pretty obvious what's happening, doesn't it?

So, I am going to create this wrapper component and see how it goes. Here's the source code for it:

import { CommonModule } from '@angular/common';
import { Component, Input } from '@angular/core';
import { Router, RouterModule } from '@angular/router';
import {
  BehaviorSubject,
  filter,
  Observable,
  of,
  switchAll,
  tap,
  withLatestFrom,
} from 'rxjs';

@Component({
  standalone: true,
  selector: 'app-navigate',
  template: '<ng-container *ngIf="navigate$ | async"></ng-container>',
  imports: [RouterModule, CommonModule],
})
export class NavigateComponent {
  @Input() set to(val: string) {
    this.toInput$.next(val);
  }
  toInput$ = new BehaviorSubject<string>('');

  @Input() set when(val: Observable<any>) {
    this.whenInput$.next(val);
  }
  whenInput$ = new BehaviorSubject<Observable<any>>(of(null));

  when$ = this.whenInput$.pipe(switchAll());
  navigate$ = this.when$.pipe(
    withLatestFrom(this.toInput$),
    filter(([, url]) => url !== ''),
    tap(([, url]) => this.router.navigate([url]))
  );

  constructor(private router: Router) {}
}

However, for this specific case, I don't see any reason I have to use this component. Instead of this data flow:

Why don't I just turn that back button into a link and have the data flow go like this?

Instead of reacting to backClick$, we can have the other two methods react the the URL changing back to home.

So how do we get those store methods to react?

NgRx/Component-Store

Our 2 store methods need to react to an observable, so we have 2 choices: Either we can convert the whole store to StateAdapt right now, or we could try a more incremental approach by implementing the reactive utilities I explained in this article first.

Let's do this incrementally.

You can see the source code for the reactive wrapper class I made here, but what matters is that it allows us to do this:

    this.react<AppStore>(this, {
      deleteMovies: urlFromMovieDetailToHome$.pipe(map(() => undefined)),
      switchFlag: urlFromMovieDetailToHome$.pipe(map(() => false)),
    });

This is made possible by directly importing ReactiveStore and extending that class instead of ComponentStore. Now, whenever urlFromMovieDetailToHome$ emits, it will trigger the methods on the left-hand side, and pass the emitted value into them.

In order to define urlFromMovieDetailToHome$, I injected the router into the Component Store class and listened to the events for a specific transition:

    const urlFromMovieDetailToHome$ = this.router.events.pipe(
      filter((event): event is NavigationEnd => event instanceof NavigationEnd),
      pairwise(),
      filter(
        ([before, after]) =>
          before.url === '/movie' && ['/home', '/'].includes(after.url)
      ),
    );

It's a bit complicated, but this will simplify a bit when we swap in StateAdapt.

But we now have update logic right in the store next to the state it's updating! Now, if we're ever wondering why movies were deleted, we can just look in the class and see how urlFromMovieDetailToHome$ is defined! Declarative code is nice. Granted, these update methods are technically imperative, but I think of the class as being one, self-contained thing, so this is close enough to declarative for me.

Takeaways from Event #1

Even though we only refactored one event to reactivity, it feels like we accomplished a lot already. So far, we have decided to

navigate reactively by using a wrapper component for router.navigate
incrementally move NgRx/Component-Store to more reactive syntax

Finishing up the component

The remainder of the component is just a bunch of downstream RxJS stuff. As it's written, we have subscriptions inside subscriptions, and a lot of imperative statements:

  cast!: any[];
  movie!: MovieModel;

  // ...

  ngOnInit(): void {
    this.store.state$.subscribe((res) => {
      let movie = res.movieSelected;
      if (movie == null) {
        this.router.navigate(['/']);
      } else {
        this.singleMovie.getMovieDetails(movie.id).subscribe((data: any) => {
          this.movie = data;
          this.movie.poster_path = `${environment.imageUrl}${this.movie.poster_path}`;
        });
        this.singleMovie.getCast(movie.id).subscribe((data: any) => {
          this.cast = Array.from(data.cast);
          this.cast = this.cast.filter((c) => c.profile_path != null);
          this.cast.forEach((c) => {
            c.profile_path = `${environment.imageUrl}${c.profile_path}`;
          });
        });
      }
    });
  }

Now that we have a declarative way to navigate, this doesn't look hard at all!

I found an observable on the store called movieSelected$, so, I'll define two observables chaining off of that:

  movieSelectedNull$ = this.store.movieSelected$.pipe(
    filter((movie) => movie == null)
  );
  movieNotNull$ = this.store.movieSelected$.pipe(
    filter((movie) => movie != null)
  ) as Observable<MovieModel>;

We'll feed movieSelectedNull$ into the template to trigger the navigation to home:

<app-navigate to="/" [when]="movieSelectedNull$"></app-navigate>

Now we can use the non-null movie observable to define movie$, the reactive replacement for the movie property from the imperative implementation:

  movie$ = this.movieNotNull$.pipe(
    switchMap((movie) => this.singleMovie.getMovieDetails(movie.id)),
    map((data: any) => ({
      ...data,
      poster_path: `${environment.imageUrl}${data.poster_path}`,
    }))
  );

Finally, we can define cast$, the reactive replacement for the cast property from the imperative implementation:

  cast$ = this.movie$.pipe(
    switchMap((movie) =>
      this.singleMovie.getCast(movie.id).pipe(
        map((data: any) =>
          (Array.from(data.cast) as any[])
            .filter((c) => c.profile_path != null)
            .map((c) => ({
              ...c,
              profile_path: `${environment.imageUrl}${c.profile_path}`,
            }))
        )
      )
    )
  );

And then we update the template, and we're done!

Here's the full commit.

Conclusion

So far this process of starting with events and working downstream is going pretty smoothly.

Previously, there were 13 imperative statements, and lots of mixed concerns, as you can see from this color-coded screenshot:

A little bit of this was generic cleanup, but for the most part, reactivity simplified it a lot with better separation of concerns, and 0 imperative statements:

This looks like a lot less code, but remember that we moved a bunch over to the store, and added a little to the template. In total, the reactive implementation was actually 5 lines of code more. git stat said the commit had 63 insertions and 58 deletions.

But the better separation of concerns is definitely worth it! And by the end of refactoring this app to reactivity, I suspect that the reactive implementation will actually be less code.

We'll see!

In the meantime, check out StateAdapt!

DEV Community: Mike Pearson

10 Tips for Scaling Signals

1. computed can be inefficient by default

2. Reuse logic, not state

3. Signal update timing can break e2e tests

4. The auto-signal pattern is awesome

5. The reactive variation of auto-signals is cleaner

1. Method

2. Subject

6. State changes and events should be separate

7. Base connection$ observables should be Observable<any>

8. Some HTTP utilities are useful

9. resetOnRefCountZero can smooth transitions

10. Accessing route data in services is a pain

Bonus Tip: Type object literal returns

Conclusion

Introducing the auto-signal pattern

The Problem

1. Automatic cleanup

2. Reset and re-fetch

3. Automatic cancel

4. Automatic defer

Don't share signals?

Real-world example

The Solution

Conclusion

RxJS can save your codebase

Implementations

RxJS

Signals

Lines of Code

Level of Abstraction

Debugging

Declarative Code

Declarative Code Definition

Examples of Declarative vs Non-Declarative Code

UI

Variables

State

Effect Events

UI Events

Benefits of declarative code

Focus

Debugging with Context

Avoiding Bugs with Context

Comprehensibility

Declarativeness in RxJS vs Signals Only

Signal Operators

Conclusion

Signals make Angular MUCH easier

How about selectors?

Signals

Problems with signals

Why your folder structure sucks

1. Folder straddling

HTML + JavaScript + CSS

State

Types

This will always happen

2. Hard-to-find files

Becoming familiar with a project

Debugging an issue

3. Reusability confusion

4. Slow load times

5. Slow build times

6. Huge folders

Organizing by routes

Directory trees are inherently limited

Conclusion

How to not regret useState

1. Simple Local State

2. Complex State Changes

2. Complex State Changes: Imperative

2. Complex State Changes: Declarative with useReducer

2. Complex State Changes: Declarative with StateAdapt

3. Derived State

4. Global State

5. Reusable State Logic

6. Global Events/Actions

6. Global Events/Actions: Imperative

1. `computed` can be inefficient by default

7. Base `connection$` observables should be `Observable<any>`

9. `resetOnRefCountZero` can smooth transitions

2. Complex State Changes: Declarative with `useReducer`