DEV Community: Jon Rimmer

NgRx Sagas

Jon Rimmer — Sat, 05 Oct 2019 17:21:55 +0000

All the code I produced while writing this article can be found here: https://github.com/jonrimmer/ngrx-saga

I find writing effects to be the most complex and error-prone part of building an NgRx app. For all their power, effects can be tricky to get right, especially when the logic flow becomes more complex, combining multiple asynchronous loads, and needing supporting infrastructure to dispatch ancillary actions to do things like show and hide spinners, and notify the user about errors.

Even after using RxJS almost every day for the past few years, I still encounter difficulties writing sophisticated, branching reactive flows. It's easy to get lost in a nest of switchMaps, higher-order functions, and ternary conditions, and you can find yourself yearning for the lost if-else simplicity of a plain imperative programming.

But that's just the way it is, right? Well, perhaps not. The redux-saga project provides an interesting alternative way of writing side effects for the Redux paradigm. Instead of using a reactive flow, the library leverages JavaScript's support for generators.

Check out this basic example from the redux-saga homepage:

// worker Saga: will be fired on USER_FETCH_REQUESTED actions
function* fetchUser(action) {
   try {
      const user = yield call(Api.fetchUser, action.payload.userId);
      yield put({type: "USER_FETCH_SUCCEEDED", user: user});
   } catch (e) {
      yield put({type: "USER_FETCH_FAILED", message: e.message});
   }
}

The use of the yield keyword allows the developer to return a value from the function at any point, which will then be processed by the library. It might be an instruction to dispatch an action, or it might be to make an asynchronous call. When the library has completed the instruction, the saga will continue from the point it left off.

Example: Initial User Load

Let's consider a NgRx scenario where we are trying to load some details about the current user, at app startup, from an API. Our requirements are:

We need to fetch the user's profile.
We need to use the id from the profile to load the user's permissions.
If the user has permissions, we need to load and precache a number of post entities.
We need to show and hide a busy spinner while the above is happening.
We need to catch any load errors and notify the user something went wrong.

For this example, we'll forget about the actual store state. For writing effects, we just need to know the actions. Let's define them:

export const loadUser = createAction('[User] Load user');
export const loadUserSuccess = createAction(
  '[User] Load user success',
  props<{ user: User; permissions: string[] }>()
);
export const loadPostsSuccess = createAction(
  '[Posts] Load posts success',
  props<{ posts: Post[] }>()
);
export const notifyError = createAction(
  '[Notifications] Error',
  props<{ error: any }>()
);
export const showSpinner = createAction('[Spinner] Show spinner');
export const hideSpinner = createAction('[Spinner] Hide spinner');

With our actions defined, we can write an effect to meet our requirements:

initUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUser),
    switchMap(() =>
      concat(
        of(showSpinner()),
        this.usersService.getUser().pipe(
          switchMap(user =>
            this.usersService
              .getPermissions(user.id)
              .pipe(
                switchMap(permissions =>
                  concat(
                    of(loadUserSuccess({ user, permissions })),
                    permissions.includes('posts:read')
                      ? this.postsService
                          .getPosts()
                          .pipe(map(posts => loadPostsSuccess({ posts })))
                      : EMPTY
                  )
                )
              )
          ),
          catchError(error => of(notifyError(error)))
        ),
        of(hideSpinner())
      )
    )
  )
);

Opinions will vary, but despite having written similar effects many times, I didn't find this logic especially easy to code, or to parse when I look back at it.

Perhaps we can simplify things by splitting it up into two effects, with a helper function to show our spinner and catch errors:

function task<T extends Action>(
  work: (a: T) => Observable<Action>
): (a: T) => Observable<Action> {
  return (a: T) =>
    concat(
      of(showSpinner()),
      work(a).pipe(catchError(error => of(notifyError(error)))),
      of(hideSpinner())
    );
}

initUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUser),
    switchMap(
      task(() =>
        this.usersService
          .getUser()
          .pipe(
            switchMap(user =>
              this.usersService
                .getPermissions(user.id)
                .pipe(
                  map(permissions => loadUserSuccess({ user, permissions }))
                )
            )
          )
      )
    )
  )
);

precachePosts$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUserSuccess),
    switchMap(
      task(({ permissions }) =>
        permissions.includes('posts:read')
          ? this.postsService
              .getPosts()
              .pipe(map(posts => loadPostsSuccess({ posts })))
          : EMPTY
      )
    )
  )
);

A little better... perhaps? But not by much. And it's less obvious that the two effects are intended to act in sequence as an initial load phase.

Introducing fromActionGenerator

The task() higher-order projector function in the above example demonstrates how we can take a function that does the work of the effect, mapping from an action to an observable of actions, and wrap it in additional logic. Could we use a similar approach to support a more saga-ish way of writing effects?

Let's define a new function, fromActionGenerator:

function fromActionGenerator<T extends Action>(
  // In TS 3.6 this type will change to AsyncGenerator:
  generator: (action: T) => AsyncIterableIterator<Action>
): (action: T) => Observable<Action> {
  return a1 =>
    new Observable<Action>(sub => {
      let unsubbed = false;

      (async () => {
        try {
          for await (const a of generator(a1)) {
            if (unsubbed) {
              return;
            }

            sub.next(a);
          }
        } catch (error) {
          sub.error(error);
          unsubbed = true;
        }
      })().then(() => {
        if (!unsubbed) {
          sub.complete();
        }
      });

      return () => {
        unsubbed = true;
      };
    });
}

This function accepts a generator parameter, which is a function mapping from a single action to an AsyncIterableIterator<Action>. The latter is just the type that TypeScript gives to asynchronous generator function, like this:

async function* (action: Action) {
  yield someAction();
}

Note: Unfortunately, an async generator of this kind cannot be an arrow function. For whatever reason, the TC39 committee has let the proposal to support them languish in stage 1 since 2016 with no indication it will ever progress further.

The use of async means we will be able use async/await inside our saga to wait on things like promises. This is different from the redux-saga library, where asynchronous actions require yielding a special type of object. In our design, the only thing that will be yield-able will be plain actions.

The body of fromActionGenerator function creates a new observable using the Observable constructor. The subscribe function then does the work of connecting the supplied subscriber to the generator output.

Since the generator function will be async, it must be run from within an async function, which we create and execute immediately. The async function uses for-await-of to asynchronously iterate through all the actions yielded by the function, and emits each one to the subscriber, which will be the NgRx actions observable.

When the generator function finishes, or when the observable is unsubscribed, the asynchronous iteration loop is ended, and the observable completes.

Note: The use of asynchronous generators, relies on some quite recent EcmaScript additions. Make sure to add "es2018" or newer to the lib property of your tsconfig.json file in order to enable support.

Putting it to use

Now let's rewrite our earlier effect using a saga. Because of the aforementioned inability to use an arrow function for async generators, we'll instead define it inside our effect class constructor, to get easy access to the injected services:

class AppEffects {
  constructor(
    private actions$: Actions,
    private usersService: UsersService,
    private postsService: PostsService
  ) {
    async function* loadUserSaga() {
      try {
        yield showSpinner();

        const user = await usersService.getUser().toPromise();
        const permissions = await usersService
          .getPermissions(user.id)
          .toPromise();

        yield loadUserSuccess({ user, permissions });

        if (permissions.includes('posts:read')) {
          yield loadPostsSuccess({
            posts: await postsService.getPosts().toPromise()
          });
        }
      } catch (error) {
        yield notifyError(error);
      } finally {
        yield hideSpinner();
      }
    }

    this.loadUser$ = createEffect(() =>
      this.actions$.pipe(
        ofType(loadUser),
        switchMap(fromActionGenerator(loadUserSaga))
      )
    );
  }
}

Maybe we don't need a generator?

In redux-saga, the way to perform asynchronous work is to yield a special type of value, which the library knows to wait on before re-entering the saga function. In our case, we're using async/await to achieve the same thing. Since all we're yielding is actions, and these will be processed synchronously, it occurs that we don't actually need to use a generator. Instead we could use a regular async function.

Let's define a new higher-order helper function, fromActionAsync:

function fromActionAsync<T extends Action>(
  saga: (a1: T, dispatch: (a2: Action) => void) => Promise<void>
): (action: T) => Observable<Action> {
  return a3 =>
    new Observable<Action>(sub => {
      const dispatch = sub.next.bind(sub);

      saga(a3, dispatch)
        .catch(error => sub.error(error))
        .then(() => {
          sub.complete();
        });
    });
}

This one is a lot simpler. Here we just accept a function that accepts both an action and a dispatch() function, and returns a void promise.

The function still returns a new observable, but in this case, instead of iterating over the result of calling saga(), the subscribe function calls it, passing in the action and a dispatch function, then waits for it to error or complete.

We could then use fromActionAsync to define an effect as follows:

public initUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUser),
    switchMap(
      fromActionAsync(async (_, dispatch) => {
        try {
          dispatch(showSpinner());

          const user = await this.usersService.getUser().toPromise();
          const permissions = await this.usersService
            .getPermissions(user.id)
            .toPromise();

          dispatch(loadUserSuccess({ user, permissions }));

          if (permissions.includes('posts:read')) {
            dispatch(
              loadPostsSuccess({
                posts: await this.postsService.getPosts().toPromise()
              })
            );
          }
        } catch (error) {
          dispatch(notifyError(error));
        } finally {
          dispatch(hideSpinner());
        }
      })
    )
  )
);

Our approach is now starting to look more like redux-thunk that redux-saga.

The logic here is so simple that's almost not worth having the fromActionAsync. We could just create and return an observable directly:

public initUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUser),
    switchMap(
      () =>
        new Observable<Action>(sub => {
          (async () => {
            sub.next(showSpinner());

            const user = await this.usersService.getUser().toPromise();
            const permissions = await this.usersService
              .getPermissions(user.id)
              .toPromise();

            sub.next(loadUserSuccess({ user, permissions }));

            if (permissions.includes('posts:read')) {
              sub.next(
                loadPostsSuccess({
                  posts: await this.postsService.getPosts().toPromise()
                })
              );
            }
          })()
            .catch(error => sub.next(notifyError(error)))
            .finally(() => sub.next(hideSpinner()));
        })
    )
  )
);

At this point, we've boiled things down to pretty idiomatic RxJS. The drawbacks are that we've gradually lost something of the elegant simplicity of the generator approach, where the effect's core logic was almost entirely unencumbered, and that we've lost the ability to end the saga early if the observable is unsubscribed (e.g. due to a new action arriving at the switchMap. For these reasons, I still prefer the generator-based approach.

Conclusion

The above is intended as more of an exploration/experiment than a definite proposal for something you should do in your codebase. At the very least, it's rather non-standard, and any advantage you gain in personal understandability might be offset by unfamiliarity on the part of your coworkers and collaborators.

I'm not sure I would use the above in Angular code I wrote for an employer just yet, but it's definitely something I'll look to experiment more with in personal projects.

Megaproject Mismanagement

Jon Rimmer — Sun, 07 Jul 2019 14:06:06 +0000

What follows is a summary of What You Should Know About Megaprojects, and Why by Professor Bent Flyvbjerg, an analysis into the difficulties faced by very large projects. Many of these problems will be all-too familiar to those whose careers in tech have involved working on big IT projects. All insights are those of Flyvbjerg and his sources and collaborators. Any errors are mine.

The Good

"Megaprojects" are extremely large, complex projects, with budgets of billions or more, and years-long delivery timescales. Their size makes them different from regular projects, and they require a different approach to manage successfully. Typical megaprojects are very large buildings, bridges, public transportation systems and space missions.

The popularity of megaprojects has increased in the public and private sector, and a conservative estimate of their market size is $6-9 trillion a year. They possess four "sublimes" that makes them attractive a to different type of decision maker:

Engineers – their technical ambition and boundary-pushing.
Politicians – as a monument to them and their causes.
Businesses and unions – the amount of money and jobs they provide.
Designers and design enthusiasts – their beauty and iconic scale.

Policy makers in general favour megaprojects due to their apparent benefits in terms of greater employment, domestic consumption, better services, and potential for environmental improvement.

The Bad

Despite their supposed benefits, megaprojects have an awful performance history. Their size makes them inherently risky and difficult to properly plan or lead over the long term. Optimism bias infects projections of costs and likely benefits, and they are almost always wrong. Actual cost and timescales overrun and demand is lower than expected. ICT megaprojects are particularly bad.

Only one in a thousand megaprojects is delivered on budget, time and benefits. So few that there isn't enough of them to do proper statistical analysis on why they succeeded where most failed. The ratio of successful to unsuccessful projects does not seem to be improving over time.

Most megaprojects follow a "break-fix" model. Implementors don't know how to succeed, but carry on anyway until a moment of crisis, the "break", when reality hits home. At this point there is usually a pause to "fix" the project through reorganisation and refinancing.

Some argue that mis-planning is a necessary evil to help valuable projects get started. This idea is commonly expressed by insiders but rarely on the record. Hirschman argued underestimation of problems can be matched by underestimation of ability to creatively solve the same problems. He called this the "Hiding Hand" principle.

These theories have proved popular, especially amongst those with a vested interest in seeing megaprojects happen. This has enabled a culture of strategic misrepresentation, where promoters willingly engage in overoptimistic projections in order to get projects started.

The Ugly

However, these theories are flawed. The research underpinning them is based on insufficient and biased data. In fact, optimism bias applies at all levels, to cost and benefits, and problems tend to stick around to impair projects, rather than being creatively solved.

Deceptive promotion of megaprojects leads to Pareto inefficiency, misallocating resources that could have been better spent elsewhere. It is also unethical and sometimes illegal for individuals in the public or private sector to knowingly mislead others in their efforts to promote projects.

In fact, very large projects can have a positive benefit to cost ratio, but the problem is distinguishing these from the majority of bad proposals, something made harder by rampant dishonesty. There is a "survival of the unfittest" whereby those projects that are most unrealistic about their benefits and costs on paper are most likely to get selected, even though this same dishonesty leads to bigger problems down the line.

The Future

There are some positive signs. For example, the willingness of the Obama administration to call out problems in US public procurement. Also, projects are now so big that a single one can bring down an executive or a whole corporation, giving an incentive for better oversight.

The UK government established the Major Projects Authority in an attempt to get control of project overrun, and some other countries have followed suit with similar schemes, in a general trend towards stronger governance following corporate scandals like Enron. Greater involvement of private finance from capital and pension funds has also lead to somewhat better oversight through more independent auditing of project projections.

Finally, research into megaproject management has improved, stemming from a better understanding of how optimism bias and strategic misrepresentation cause them to go awry in the first place. Outcomes from this research have begun to impact practice. Although it is too early to tell if reforms will be successful.

Typesafe Mocking in TypeScript

Jon Rimmer — Mon, 27 May 2019 14:24:53 +0000

Say I have an Angular service TodosApiService with the following shape:

@Injectable()
class TodosApiService {
  constructor(private http: HttpClient) {}
  getTodo(id: number): Observable<Todo> {}
  getTodos(): Observable<Todo[]> {}
  createTodo(todo: Todo): Observable<number> {}
  updateTodo(todo: Todo): Observable<void> {}
  deleteTodo(id: number): Observable<void> {}
  private checkCache(id: number): Todo | null
}

Now say I want to code a class MockTodosApiService that can be used in place of TodosApiService and which returns mock data instead of making actual network requests. This might be useful for situations like testing or developing components in isolation in a system like Storybook.

How can I ensure that my mock class provides the same interface as TodoApisService? I.e. that I am implementing all the public methods from the service, and that I am returning the correct types? And that if somebody comes along and adds a method bulkUpdateTodos() to TodosApiService that they get a compile error unless they also add it to MockTodosApiService?

One way would be to create a TypeScript interface that both TodosApiService and MockTodosApiService implement:

interface TodosApi {
  getTodo(id: number): Observable<Todo> {}
  getTodos(): Observable<Todo[]> {}
  createTodo(todo: Todo): Observable<number> {}
  updateTodo(todo: Todo): Observable<void> {}
  deleteTodo(id: number): Observable<void> {}
}

class TodosApiService implements TodosApi { }
class MockTodosApiService implements TodosApi { }

In languages like C# or Java that would be my only real option, but it's kind of a pain. I now have three places to make changes keep in sync with each other.

However, the dynamic nature of JS and TypeScript's expressiveness provide a different option. I can instead use mapped types to tell the compiler that I want my mock class to provide the same public interface as the "real" service. It's as simple as this:

class MockTodosApiService implements Pick<TodosApiService, keyof TodosApiService> { }

TypeScript will now complain if I implement MockTodosApiService in a way that is incompatible with the public interface of TodosApiService. However, it will not complain about my not replicating the constructor, or the private checkCache() method and http field.

This works because keyof returns the names of every public field and method of a type. We then use the Pick<> mapped type, which returns a subset of a type's properties. The result is a type that contains only those properties from TodosApiService that are returned by keyof TodosApiService. And by saying that MockTodosService implements that type, I get compile-time checking that I'm doing so correctly.

A React hook to handle state with dependencies

Jon Rimmer — Sat, 02 Feb 2019 23:54:07 +0000

In order to experiment with React's new hooks API, I've been building an app called Fretfull, which lets you explore different ways to play chords on guitar. The app's source code uses hooks throughout for context and state.

While building the app, I created something I call a "dependent state" custom hook. It's useful when you have a piece of state with a range of valid values that are calculated based on one or more dependencies. If a dependency changes, the state's current value may no longer be valid, and will need to be checked and possibly reset.

To make that more concrete, consider the following situation:

An app receives a list of product categories from the server.
The app displays the list of categories in the UI.
The user selects a category.
The app receives an updated list of categories from the server.

At this point, the selected category may or may not be valid, depending on whether it still exists in the list of updated categories. Therefore, the app needs to be smart about how it applies the update. If the category no longer exists, keeping it selected will result an inconsistent and invalid application state. However, automatically resetting it will result in a poor user experience if the category is still valid. The code will need to check the updated list and reset the selection only if the selection is not found.

Let's consider how we might implement this scenario using React hooks.

function Categories({ apiData }: { apiData: CategoriesApiResult }) {
  const categories = useMemo(() => {
    return apiData.data.map(cat => cat.name);
  }, [apiData]);

  const [category, setCategory] = useState(categories[0]);

  return <OptionList
    options={categories}
    selected={category}
    onSelect={e => setCategory(e.value)}
  />;
}

Here the Categories component creates the list of category options by mapping over the data from an API call received as a prop. We memoize the calculation so it is only executed when the API data changes. We also store the selected category as a piece of state, defaulting it to the first category in the list.

However, this code has a bug: If categories changes, the value of category may no longer be valid. We need to check that it's still valid, and optionally reset it. We can do this as follows:

let [category, setCategory] = useState(null);

const categories = useMemo(() => {
  const result = apiData.data.map(cat => cat.name);

  if (!result.includes(category) {
    setCategory(category = result[0]);
  }
}, [apiData]);

Now we avoid the bug, but at the expense of muddying up our render logic. We have to make category reassignable, define it before categories, and include a side effect in our categories memoization function that resets category.

We can make this approach cleaner and more reusable by implementing a custom hook, that we'll call useDependentState:

function useDependentState<S>(
  factory: (prevState?: S) => S,
  inputs: ReadonlyArray<any>,
): [S, Dispatch<SetStateAction<S>>] {
  let [state, setState] = useState<S>(factory());

  useMemo(() => {
    const newState = factory(state);

    if (newState !== state) {  
      setState(state = newState);
    }
  }, inputs);

  return [state, setState];
}

This hook captures the essence of the above logic in a generic form. It defines a piece of state and run a memoized function that runs only when the dependencies change. This memoized function delegates to a factory function that we must provide, and which is responsible for either generating the initial value or changing the current value if it's no longer valid. Let's see how we could use it in the previous example:

const categories = useMemo(() => {
  return apiData.data.map(cat => cat.name);
}, [apiData]);

const [category, setCategory] = useDependentState(prevState => {
  return (prevState && categories.includes(prevState)) ?
    prevState
    :
    categories[0];
}, [categories]);

Our custom hook means we can keep category as a const, keep the original definition order, and the only logic we have to implement is the check as to whether the prevState value is still valid.

Conclusion

Hopefully this custom hook may prove useful to anyone facing a similar issue with state whose validity depends on some dependencies.

The only downside I see to this custom hook is that it has to call setState to update the state value when it changes, which will result in a second render. But I can't see any way to avoid this. I have submitted a React feature suggestion with the idea of enhancing the regular setState hook with the ability to provide dependencies that cause it to be re-initialised in a similar manner to this custom hook. If implemented, this would eliminate the need for the additional render, as the prevState value would not have "leaked", because the check logic would occur within the useState call.

Thoughts on AlphaStar

Jon Rimmer — Fri, 25 Jan 2019 18:24:19 +0000

Deepmind's presentation of its Starcraft 2 playing AI AlphaStar is fascinating, and I highly recommend watching it if you haven't. Even as somebody who hasn't played any real-time strategy games since Warcraft 2 and isn't a AI expert, I found it easy to follow and very entertaining. They do a great job of communicating the excitement and achievement of building an AI capable of beating the best human players in the world at something as complex as Starcraft 2.

However, (spoilers for the video if you haven't watched it) there's a twist in the tale. Throughout the video Deepmind's researchers stress that they've tried to make the competition between AlphaStar and the human player as fair as possible. The AI doesn't have superhuman reaction times, nor does it make, numerically speaking, an exceptionally high number of inputs. But one advantage is does have is that it receives input on the entire playfield simultaneously. Whereas a human player must move the camera around the map, only being able to see what's happening in one spot at a time, AlphaStar has access to data on every unit (albeit constrained by the "fog of war" effect that hides enemy units when there isn't a friendly unit nearby).

While the Deepmind researchers explain that AlphaStar has evolved an attention-like mechanism, whereby it chooses to spend more time focussing on different areas of the map, it sounds like a flimsy excuse for what is a clear advantage relative to humans. This seems to be confirmed at the end of the video, when the team have MaNa, the pro Starcraft 2 player the AI previously beat 5-0, play a live exhibition match against a new, prototype version of the AI, which does have to interface with the game through a camera-like mechanism.

While the researchers insist that, based on their internal estimates, the prototype AlphaStar is as strong as the previous version, the result of the match is rather different. MaNa plays a smart game, making sure to plant scouting units with visibility of the enemy's base, letting him tailor his strategy to whatever is doing. Later, he guarantees victory when the AI makes a mistake all too typical of non-human video game opponents. MaNa keeps an airborne unit just outside of the AlphaStar's main base, flying it in to harass some of the buildings, then flying it out to safety just before the enemy's forces can arrive to destroy it.

Each time MaNa employs this harassment strategy, AlphaStar dumbly turns around its entire army and sends it backwards, hopelessly trying to catch the airborne attacker before it disappears again, then sends them all away again. Anyone who's ever baited a programmed AI opponent in a game will recognise this situation. The AI is falling back on a pattern of behaviour without the meta-cognition necessary to recognise that it is making a mistake, that its opponent is exploiting its behaviour, and that it must formulate a new strategy.

In the aftermath of the video's release, there have been other concerns raised about the fairness of the of competition. For example, while the Deepmind researchers stressed that AlphaStar had an average number of "actions per minute" equivalent to or less than the pro human players, it isn't just the quantity but the quality of these actions that counts. Pro human players tend to spam inputs just to keep their fingers warm and moving, and are still limited by the laws of physics and biology in how quickly and accurately they can move and click the mouse.

AlphaStar, on the other hand, can make inputs with pixel perfect precision, for a huge number of separate units at any given moment. And while the AI's average actions-per-minute was low, it did spike up to near a thousand at key moments, when it was engaging in a large scale battle. This was most obvious in the second of the presented games between MaNa and AlphaStar, when the AI overwhelmed its opponent with a huge army of relatively low powered units, which it marshalled into an unstoppable three pronged attack from all sides. The opposing, human-controlled army was more powerful on paper, but even a pro of MaNa's ability couldn't exercise the precise control necessary to repel this kind of assault.

The hosts called AlphaStar's play during this battle, and at other points, "superhuman", and they were correct. But it was telling that didn't consider it to be displaying superhuman intelligence or strategy, just "microing" — the micro-scale control of individual units. More often they were confused and critical of elements of AlphaStar's play where, while engaging in some pro-level strategies, it also seemed to neglect others that would have made it stronger. The only major strategic novelty it displayed was consistently building more harvesting worker units than is considered optimal amongst pro players. Hardly revolutionary.

So, what conclusion can we draw from Deepmind's presentation? Well, they have definitely created an impressive system for training Starcraft 2 AI players, and this has resulted in the strongest bots ever seen. It seems likely that, with more data and more training, the agents they produce will probably be able to beat any human player most of the time. However, I think there are big questions remaining as to whether the agents produced by Deepmind's system so far possess much genuine intelligence, and whether any kind of fair competition is possible between the agents and human players. Right now, even if AlphaStar was capable of acting with a human level of intelligence, its superior level of control might mean it often wouldn't need to in order to win.

It's possible to imagine producing a new version of Deepmind's training system that more accurately replicates the limits on human player. As well as a camera system, agents could required to perform their inputs via a simulated cursor that would constrain them to an action rate and an accuracy equivalent to a pro player. But does it make sense to do so?

The thing is, one of the key reasons we use computers and other machines to perform tasks is that they can be faster and stronger and react more quickly than any human being. Perhaps the reasons animals evolved intelligence in the first place was to compensate for the limitations of biology. It would be ironic if, in order to produce artificial intelligence, we also need to artificially constrain machines from using most of the abilities that make them so powerful. After all, the concept of "fairness" is relative. From the machine's perspective, if it has one, it's doing nothing wrong in using its strengths against the weaknesses of its human opponents.

If, in order to win at Starcraft, it's more useful to exercise ultra-precise control of hundreds of units than to be smart, then maybe that's just how it is. And maybe the question isn't how we constrain the agent to play "fairly", but whether Starcraft is truly a good choice to train strong artificial intelligence.

Photo by Drew Graham on Unsplash

Where to initiate data load in NgRx

Jon Rimmer — Tue, 22 Jan 2019 23:35:50 +0000

In NgRx, loading data from a data source, such as a REST API or a DB, is done using an effect. However, something has to dispatch the action that triggers the effect in the first place. I've seen a few different suggestions / approaches to doing this.

In our example, we'll be loading a collection of Order entities from a service. We'll introduce two actions: LoadOrdersRequested and LoadOrders. The first of these will initiate the data load, then an effect will perform the load and dispatch a LoadOrders action, which will put the loaded data into the store.

The effect to handle LoadOrdersRequested will look like this:

@Effect()
loadOrdersRequested$ = this.actions$.pipe(
  ofType<LoadOrdersRequested>(ActionTypes.LoadOrdersRequested),
  // Don't load if we've already loaded.
  withLatestFrom(this.store.select(getAllOrdersLoaded)),
  filter(([_, loaded]) => !loaded),
  // Don't handle more than one load request at a time.
  exhaustMap(() => this.ordersService.fetchAllOrders().pipe(
    map(result => new LoadOrders(result))
  ))
);

Now, in order to initiate the data load, we need to dispatch the LoadOrdersRequested action from somewhere. There are four main options:

When the app starts.
When a container component is initialised.
When the app navigates to a route.
When the user performs an action.

The fourth of these might be when the user clicks a button to explicitly load or reload some data. For this article we'll concentrate on the first three.

When the app starts

Pros:

The data is guaranteed to load.

Cons:

Memory / performance concerns if there's a lot of data to load.

In your AppComponent

The simplest way is to dispatch the LoadOrdersRequested action from your AppComponent's init lifecycle method:

export class AppComponent implements OnInit  {
  constructor(private store: Store<AppState>) {}

  ngOnInit() {
    this.store.dispatch(new LoadOrdersRequested());
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-app-component

In an effect

NgRx provides an INIT action that is dispatched when the app starts. This seems like a good place to initiate our data load, but there's a problem. The INIT action is dispatched before the effects are subscribed to, so this won't work:

@Effect()
init$ = this.actions$.pipe(
  ofType(INIT),
  map(() => new LoadOrdersRequested())
);

Instead, the NgRx team has recommended using the defer RxJS operator instead:

@Effect()
init$ = defer(() => new LoadOrdersRequested());

However, if we want to have our effect potentially trigger other effects, this approach will not work. This is because, while defer delays the creation of the LoadOrdersRequested action until the init$ observable is subscribed to (during the effects module initialisation), the action will then be dispatched before the initialisation is complete. As such, our effect that is looking for LoadOrdersRequested may not be registered yet, depending on the order in which the effects system has subscribed to the different effects.

We can perhaps mitigate this problem by re-ordering out effects, but a better solution is to use the asyncScheduler to delay to dispatch of the LoadOrdersRequested action:


import { asyncScheduler, of } from 'rxjs';

...

@Effect()
$init = of(new LoadOrdersRequested, asyncScheduler);

Although INIT does not work, there is also a built-in action we can use: ROOT_EFFECTS_INIT:

@Effect()
$init = this.actions$.pipe(
  ofType(ROOT_EFFECTS_INIT),
  map(() => new LoadOrdersRequested())
);

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-init

APP_INITIALIZER

Angular provides APP_INITIALIZER as a way to run code at app startup, and you can dispatch actions from there:

@NgModule({
  ...
  providers: [
    {
      provide: APP_INITIALIZER,
      useFactory: (store: Store<AppState>) => {
        return () => {
          store.dispatch(new LoadOrdersRequested());
        };
      },
      multi: true,
      deps: [Store]
    }
  ]
})

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-app-initializer

When a container component is initialised

Pros:

You only load data as and when it's needed.
It's clear from looking at the component what data it's relying on.

Cons:

You either need lots of actions, or to dispatch the same action in several places.
The component is less pure, as it has the side effect of loading data.
You might forget to dispatch the action from a component that needs the data. This bug could be obscured if you normally reach the component through another component that does initiate the data load. E.g. you normally open a list page before opening a details page. Then, one day, you navigate directly to the details page and it breaks.

@Component({ ... })
export class OrdersComponent implements OnInit {
  order$: Observable<Order>;

  constructor(private store: Store<AppState>) {
    this.order$ = this.store.select(getOrder);
  }

  ngOnInit() {
    this.store.dispatch(new LoadOrdersRequested());
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-in-component

When the app navigates to a route

Pros:

Less duplication. A single guard at the root of a route hierarchy can load the data for all child routes, even if they're navigated to directly.
Components are more pure, as they only map from selected state to their template output.

Cons:

Quite blunt: A guard will trigger data load for any child route, even if its component doesn't need it.
Less obvious from looking at a component what data it needs to work. If it gets moved somewhere else in the router hierarchy, it'll break.
Less useful if routes requiring some particular data are spread out throughout the router hierarchy, as you'll need to include the guard in different places.

Router Guard

@Injectable()
export class OrdersGuard implements CanActivate {
  constructor(private store: Store<AppState>) {}

  canActivate(): Observable<boolean> {
    return this.store.pipe(
      select(getAllOrdersLoaded),
      tap(loaded => {
        if (!loaded) {
          this.store.dispatch(new LoadOrdersRequested());
        }
      }),
      filter(loaded => loaded),
      first()
    );
  }
}


const ROUTES: Route[] = [
  {
    path: 'orders',
    component: OrdersList,
    canActivate: [OrdersGuard],
    children: [
      ...
    ]
  }
]

https://stackblitz.com/edit/angular-ngrx-initiate-load-router-guard

A basic guard could just dispatch the LoadOrdersRequested action, relying on the effect to filter out unnecessary load requests. However, by checking the condition of allOrdersLoaded, the guard can delay the navigation until the load is completed.

Router Resolver

@Injectable()
export class OrdersResolver implements Resolve<boolean> {
  constructor(private store: Store<DatasetsState>) { }

  resolve(): Observable<boolean> {
    return this.store.pipe(
      select(allDatasetsLoaded),
      tap(loaded => {
        if (!loaded) {
          this.store.dispatch(new AllDatasetsRequested());
        }
      }),
      filter(loaded => loaded),
      first()
    );
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-router-resolve

Using a resolver works very similarly to a guard. The main difference is that a resolve is run under somewhat different circumstances to a guard, and is supposed to return an object to be merged into the activated route's data. However, we should not do this, as components should be retrieving the data from the store, not from the activated route. As such, the resolve should simply return a boolean.

Router Action Effect

@Effect()
loadOrders$ = this.actions$.pipe(
  ofType<RouterNavigationAction>(ROUTER_NAVIGATION),
  withLatestFrom(this.store.select(allOrdersLoaded)),
  filter(([action, loaded]) => 
    action.payload.routerState.url.includes('/orders') && !loaded
  ),
  map(() => new LoadOrdersRequested())
);

Pros:

Keeps things within NgRx, so feels more idiomatic.

Cons:

Requires you check if the new route matches, rather than relying on the router itself to do this as the guard approach does. This could cause loading bugs if someone changes a path in your router config, but forgets to do so in your effects.

Dispatch an action from a check inside a selector

export function getAllOrders(store: Store<AppState>) { 
  return createSelector(
    getOrders,
    state => {
      if (!state.allOrdersLoaded) {
        store.dispatch(new LoadOrdersRequested());
      }

      return state.orders;
    }
  );
}

I've not actually seen this done in the wild, but it's an approach that occurred to me.

Pros:

Guarantees to load the data if and only if it's been queried for use.

Cons:

Violates principle that selectors should be pure functions.
If you're not rigorous about reusing and combining your selectors, you could end up with some that trigger the load and some that don't because they defer to the selector that triggers the load.

Future possibilities

It sounds as if Angular Ivy may open up the possibility of using meta-programming on components to configure things like store dependencies in a more declarative way.

Conclusion

I'm not sure any one of these approaches obviously wins over all the others in all situations. You are probably best choosing an approach based on the number of data sources you need to load, the volume of data, and the complexity and layout of your router tree.

E.g. if you have a small, simple app, with a low data volume, eagerly loading everything at INIT is probably the best idea.

However, if you have a large app, split into different features, with each feature needing to load data from a separate source, it might be best to use a guard at the root of each feature's route hierarchy to dispatch the load action for its requirements.

If you have a complex app, with various containers having partially overlapping data requirements, it might be best to have each container dispatch the actions to load what they need.