DEV Community: Denis Washington

Answering Your App's Questions with Redux Selectors

Denis Washington — Fri, 24 Apr 2020 12:15:27 +0000

Of all concepts in Redux, selectors are the most underestimated. They have recently gained importance by the introduction of React Redux hooks, which make them the primary means of getting data out of Redux into React components. However, I noticed that selectors are often only seen as either "state getters" to hide the Redux state's shape or as performance optimizations for preventing state-derived values from being needlessly recalculated.

In this post, I'll show that selectors can be much more than that. Specifically, I'll demonstrate that they are not only a great tool for accessing Redux state, but also for encapsulating application logic in a way that is easy to reason about, scale, reuse, and test. As we're going to see, all it takes is a shift in perception.

About Selectors

In Redux, a selector is a function that takes the store's current state and returns a value extracted or derived from it. For example, consider a currency converter app whose Redux state looks as follows:

{
  sourceAmount: 123.45,  // the amount of money to convert
  sourceCurrency: 'EUR', // The currency of the source amount
  targetCurrency: 'USD'  // the currency to convert to
}

Given this state shape, we can write the following simple "state getter" selectors for accessing the source amount, source currency, and target currency, respectively:

function selectSourceAmount(state) {
  return state.sourceAmount;
}

function selectSourceCurrency(state) {
  return state.sourceCurrency;
}

function selectTargetCurrency(state) {
  return state.targetCurrency;
}

(In this post, I prefix every selector's name with select. Other popular conventions are to start the name with get or end it with Selector.)

As selectors are functions, they don't have to limit themselves to returning values directly from the state. For instance, we can write a selector returning the money amount after currency conversion, building on the basic selectors we defined before:

const conversionRates = {
  'EUR': { 'US': 1.09, /* ... */ },
  // ...
}

function selectConvertedAmount(state) {
  const sourceCurrency = selectSourceCurrency(state);
  const targetCurrency = selectTargetCurrency(state);
  const rate = conversionRates[sourceCurrency][targetCurrency];
  return getSourceAmount(state) * rate;
}

Assuming this is a React app, we can now use these selectors from a component with React Redux:

import React from 'react';
import { useSelector } from 'react-redux';

const ConversionResultView = () => {
  const sourceAmount = useSelector(selectSourceAmount);
  const sourceCurrency = useSelector(selectSourceCurrency);
  const targetCurrency = useSelector(selectTargetCurrency);
  const convertedAmount = useSelector(selectConvertedAmount);

  return (
    <p>
      {sourceAmount} {sourceCurrency} is
      {convertedAmount} {targetCurrency}
    </p>
  );
}

We could have put all the state access and currency conversion code into ConversionResultView directly. Extracting it into standalone selectors has several benefits, however.

Encapsulation

When using a selector, the caller does not need to know how the Redux state is shaped or which of its data is needed by the selector; it simply passes the state as a whole and gets back the desired value. No matter whether this value comes directly from the state or is computed on the fly, the call is the same. This means that if the state's structure changes, only the selectors themselves need to be updated; their callers are unaffected. Said another way, selectors minimize the coupling between the Redux store and its consumers.

Reusability

Once written, a selector can be called from any piece of code with access to the Redux state. This includes not only UI components, but also other selectors: as each selector receives the Redux state as an argument, it has, by definition, all it needs to call any other selector. It is thus easy to reuse existing selectors to compose new ones.

Purity, Testability & Memoization

Selectors are expected to be pure functions: given the same input, they always return the same result, without side effects. This makes them easy to reason about in isolation. It also makes them easy to unit-test: we just need to prepare an input state, call the selector, and compare the return value with what we except, like in the following example (using Jest):

test('selectConvertedAmount()', () => {
  const state = {
    sourceAmount: 100,
    sourceCurrency: 'EUR',
    targetCurrency: 'USD'
  };
  const result = selectConvertedAmount(state);
  const expectedConversionRate = conversionRates['EUR']['USD'];
  expect(result).toBeCloseTo(100 * expectedConversionRate);
})

Purity also enables memoization: because we know that a selector's return value will only change if its input - that is, the Redux state - changes, we can avoid recomputing the same value by caching it, only doing a new computation if the passed state is different from the previous one.

The Reselect library is a well-known implementation of this idea. Using it, we could have written the selectConvertedAmount selector as follows:

import { createSelector } from 'reselect';

const selectConvertedAmount = createSelector(
  // The first argument(s) of createSelector() define the
  // selector's *dependencies*, that is, the other selectors
  // whose values are needed for this one.
  selectSourceAmount,
  selectSourceCurrency,
  selectTargetCurrency,

  // The last argument is the selector's *implementation*,
  // which receives the return values of its dependencies
  // in the order given above. When the selector is first
  // called, its return value is cached, and the implementation
  // function is not re-run until the passed-in state AND at
  // least one of the dependencies' return values changes
  // (at which point the cache is updated).
  (amount, currency, targetCurrency) => {
    const rate = conversionRates[currency][targetCurrency];
    return amount * rate;
  }
);

(Even though I recommend using Reselect for all but the most basic selectors, I won’t use it for the rest of this post to keep things simple.)

Selectors As Little Domain Experts

So far, we have seen that Redux selectors can abstract away the state's shape and avoid redundant computations. But there's more.

To see the full potential of selectors, it helps to reflect on what it means to call one. Intuitively, we might think of it as just fetching or computing a value from the state. However, I realized that it’s much more helpful to see it as asking a question, answered by the selector based on the "facts" (state and rules) of the application’s world.

For instance, when ConversionResultView uses selectConvertedAmount in the example above, it basically asks: "What is the current result of the currency conversion (given the user’s inputs)?" Note that the caller doesn’t even need to know which pieces of information are required to answer the question - all the know-how is in the selector, which just gets what it needs from the application state itself, either by looking it up directly or by asking other selectors.

Seen this way, selectors are like little domain experts for your app, specialized on answering a single question about your app's world, and collaborating with other selectors as needed.

This means that whenever we can frame a piece of app logic as a state-dependent question, we can express the answer as a selector, giving us all of the mentioned encapsulation, reusability, testing and optimization benefits. The following sections highlight some example use cases that illustrate this.

Validation

Validating user inputs is, basically, the act of asking: "Do the user's inputs make sense (given the application's rules)?" This makes validation logic a great match for selectors, as long as you save the data to validate in the Redux state.

For instance, imagine an app for ordering food from a restaurant. The user can only place an order if the order sum is above a particular minimum amount. If we store the currently selected order items in Redux, we can easily write a selector for this rule:

const minimumOrderAmount = 10;

function selectOrderItems(state) {
  return state.order.items;
}

function selectIsOrderValid(state) {
  const items = selectOrderItems(state);
  const price = items.reduce((x, item) => x + item.price, 0);
  return price >= minimumOrderAmount;
}

This approach scales nicely as the logic becomes more complex. If, for instance, it is later decided that drinks and desserts shouldn't count towards the minimum amount, we can do this change locally in the selector without affecting any of its users.

Filtering, Sorting and Aggregation

Selectors are great for processing collections of items using arbitrarily complex rules. For instance, to answer the question "Which tasks have all of the tags selected by the user?", we can write a selector like the following:

function selectAllTasks(state) {
 return state.tasks;
}

function selectSelectedTags(state) {
  return state.filter.tags;
}

function selectFilteredTasks(state) {
  const tasks = selectAllTasks(state);
  const tags = selectSelectedTags(state);

  return tasks.filter((task) =>
    tags.every((tag) => task.tags.includes(tag));
  );
}

As new kinds of filters get added, selectFilteredTasks can be extended to take these into account as well, keeping the rest of the codebase unchanged. Sorting can be handled the same way.

We can also do other types of aggregations using selectors. For example, when writing an online quiz app, a selector for calculating the user's current score could look like this:

function selectCorrectAnswers(state) {
  return state.quiz.answers;
}

function selectGivenAnswers(state) {
    return state.round.answers;
}

function selectScore(state) {
  const correctAnswers = selectCorrectAnswers(state);
  const givenAnswers = selectGivenAnswers(state);

  return givenAnswers.reduce((answer, score, index) => {
    const isCorrect = answer == correctAnswers[index];
    return score + (isCorrect ? 1 : 0);
  }, 0);
}

Separating Logic from Side Effects

Many apps integrate side effects into the Redux flow using thunks, sagas, epics, or similar abstractions. In some cases, especially complex ones, these need to consult the application state to determine which operations to perform or which parameters to pass to them.

Instead of mixing this logic with the side effects (which are usually tedious to test because they require mocking the actual effects), we can extract it into selectors, making the actual side effect code as lean as possible. All of the popular side effect libraries have an easy way to do this; for instance, Redux Saga offers the select effect, which helps us simplify sagas as in the following example:

function selectCurrentStep(state) {
  return state.checkout.currentStep;
}

function selectIsNewUser(state) {
  return state.checkout.isNewUser;
}

function selectNextStep(state) {
  switch (selectCurrentStep(state)) {
    case 'shoppingCart':
      return 'login';
    case 'login':
      return selectIsNewUser(state) ? 'address' : 'summary';
   // ...
  }
}

function* nextStepSaga() {
  const nextStep = yield select(selectNextStep);
  yield call(navigateToStep, nextStep);
}

This makes it easy to test most of the logic independently of the saga, for which we just need to check whether the value returned by the select is correctly forwarded to the navigateToStep effect:

test('nextStepSaga()', () => {
  const generator = nextStepSaga();
  let effect;

  // Run until `yield select()`
  effect = generator.next();
  expect(effect).toEqual(select(selectNextStep));

  // Continue as if the selector returned 'login'
  effect = generator.next('login');
  expect(effect).toEqual(call(navigateToStep, 'login'));
});

The Limits of Selectors

While Redux selectors can do many things, they cannot do all things.

Firstly, selectors only have access to state that is in the Redux store, so their power is limited by how much of the app's state is kept in Redux. They are less useful for apps that use Redux only for small bits of state, for instance because most data is fetched and managed using a GraphQL library. One way to mitigate this problem is to add extra parameters to selectors, allowing non-Redux state to be passed, but that reduces uniformity (making selector composition more difficult) and makes memoization more difficult. Another is to write selector factories, which take all required non-Redux data and return a selector as a result:

function makeSelectTask(taskId) {
  return (state) => state.tasks[taskId];
}

function TaskItem({ taskId }) {
  const selectTask = useMemo(
    () => makeSelectTask(taskId),
    [taskId]
  );
  const task = useSelector(selectTask);
  return <li>{task.title}</li>;
}

Secondly, selectors are pure and synchronous, so they cannot consult external sources such as backend APIs. For cases where this is needed, Redux side effect abstractions like sagas are a better fit. Even then, you can still choose to extract the pure parts of the logic into selectors, as we've seen before.

Lastly, with selectors we can only express "static" logic that depends only on the current application state. For "dynamic" logic that is based on events – state machines, for example – Redux offers reducers.

Conclusion

Viewing Redux selectors as "little domain experts", answering the application's questions by consulting its state, reveals that they can do much more than just hiding the state's shape or caching values. We can use them for filtering and aggregating data, validating user inputs, making control flow decisions for side effects, and many other types of application logic. Because selectors are pure and uniform in how they are called, they make application logic easy to reason about, compose, reuse, and test.

Resources

Introducing Redux Preboiled: TypeScript-friendly Redux helpers

Denis Washington — Wed, 24 Apr 2019 06:53:22 +0000

Both at Futurice and in my spare time, I'm working a lot on apps based on Redux. More often than not, the Redux parts tend to accumulate a good amount of boilerplate code - action type constants, action creator declarations, reducer switch statements with the same default: return state clauses, and so on.

Some codebases have ad-hoc helper functions to reduce the noise, but those are often sparsely documented and not general-purpose enough for reuse across projects. It would be nice if there was an existing library of well-maintained Redux helpers that our projects could rely on instead. However, whenever I looked for such a library, I didn't find anything quite matching my requirements.

Basically, I've been looking for a "Lodash for Redux" - a collection of simple, stand-alone helper functions that I can pick and choose from based on my project's needs, as opposed to an all-in-one framework like Rematch (which is nice, but too opinionated to fit every use case). These helpers need to work well with TypeScript as my work increasingly relies on it - a requirement that a lot of Redux libraries, many of which pre-date TypeScript, struggle with. Lastly, I generally want to avoid the mental overhead of introducing new concepts like models and entities; in most cases, I just need some conveniences on top of the existing Redux concepts.

As I couldn't find an existing solution, I started creating my own. I am happy to announce that I have recently released the result of this effort as Redux Preboiled.

TypeScript-friendly Redux helpers, served á la carte

Redux Preboiled is a library of boilerplate-reducing Redux helper functions, designed to fit together nicely while still being usable individually. It is written in and optimized for TypeScript, while still being a good fit for pure-JavaScript apps. A major goal for Preboiled is simplicity - no fancy new concepts, no reliance on clever "magic" to shave off a few more lines at the expense of understandability, but just small and straight-forward functions that can be easily composed to do greater things.

Let's look an example - in fact, let's look at the example of all examples in the Redux world, good old counter. For extra excitement, we're going to throw in a parameterized multiply action to complement increment. Here is how you might write this in vanilla Redux, assuming you follow the patterns recommended in the Redux documentation:

// Action Types

const INCREMENT = 'increment'
const MULTIPLY = 'multiply'

// Action Creators

const increment = () => ({
  type: INCREMENT
})

const multiply = amount => ({
  type: MULTIPLY,
  payload: amount
})

// Reducer

const counterReducer = (state = 0, action) => {
  switch (action.type) {
    case INCREMENT:
      return state + 1
    case MULTIPLY:
      return state * action.payload
    default:
      return state
  }
}

This is far from terrible, but there is already some fluff here. Note how we had to write two declarations for type of action - an action type constant and a corresponding action creator function. This approach has several benefits, of course, but it's still cumbersome. Also, for every other reducer like counterReducer, we'll need to repeat the switch (action.type) { … } ceremony and make sure not to forget the default: return state clause at the end.

With Redux Preboiled, you could write this instead:

import {
  chainReducers,
  createAction,
  onAction,
  withInitialState
} from 'redux-preboiled'

// Actions

const increment = createAction('increment')
const multiply = createAction('multiply').withPayload()

// Reducer

const counterReducer = chainReducers(
  withInitialState(0),
  onAction(increment, state => state + 1),
  onAction(multiply, (state, action) => state * action.payload)
)

We have reduced the number of lines from 28 to 19, six of which are the import statement. This means that, ignoring imports (which only matter so much here because the example is so small), Preboiled helped us cut the length of the action and reducer definitions in half, thanks to these four helpers:

createAction, which generates an action creator given an action type (optionally with a payload parameter) and makes the action type available as a type property on that action creator (e.g., increment.type), making a separate action type constant unnecessary;
onAction and withInitialState, which let you create sub-reducers that handle specific action types or provide an initial state, respectively;
and chainReducers, which pulls our sub-reducers together by arranging them to a pipeline (or "call chain").

As can be seen above, these helpers are designed to fit well with each other. For example, onAction allowed us to specify the action type by passing one of the action creators we generated with createAction (e.g., increment), instead of having to explicitly pass the corresponding action type (increment.type or 'increment'). The latter option is also available - and makes onAction usable stand-alone - but the former offers additional convenience if you use both helpers together.

Goes well with TypeScript

From the start, Redux Preboiled was designed with TypeScript in mind. The helpers' function signatures lend themselves well to precise static typing, and I tried exploit opportunities for automatic type inference wherever possible.

As an example, let's look at onAction again. As mentioned before, it accepts an createAction action creator in place of of an action type. I added this option not only for convenience, but also for typing reasons: because the action creator's static type includes the shape of the actions it produces, TypeScript's compiler can infer the type of the state update function's action argument without you having to specify it. It will also give you an error if you explicitly specify an argument type that is not compatible with the inferred one.

// TypeScript

import { createAction, onAction } from 'redux-preboiled'

const multiply = createAction('multiply').withPayload<number>()

const onMultiply1 = onAction(multiply, (state: number, action) => {
  // `action` is inferred to be of type
  // PayloadAction<number, 'multiply'>.
  return state + action.payload
})

const onMultiply1 = onAction(
  multiply,
    (state, action: PayloadAction<string>) => {
    // ERROR: Argument of type
    // 'PayloadActionCreator<number, "multiply">'
    // is not assignable to parameter of type
    // 'TypedActionCreator<string, any>'.
  }
)

Note how in the snippet above, createAction(…).withPayload() allows us to specify the type of the payload using a type parameter - another way in which Preboiled helps you keep your code type-safe.

What about Redux Starter Kit?

About a year ago, Redux core maintainer Mark Erikson released Redux Starter Kit, a library that makes it easy to get productive in Redux. It is similar to Redux Preboiled in that it also includes a bunch of helper functions, including a createAction function that inspired the Preboiled equivalent. In fact, before I started Preboiled, I helped porting Redux Starter Kit to TypeScript.

However, the two libraries differ somewhat in their approach. The vision behind Redux Starter Kit is to become a "create-react-app of Redux" - an opinionated plug-and-play Redux setup that lets you hit the ground running without wasting time on menial tasks like integrating Dev Tools or deciding on a side effects library (Redux Thunk is pre-configured). The flip side, of course, is that you might get things that are more than, or different from, what you want; for instance, Redux Starter Kit's createReducer helper pulls in Immer for simplified immutable updates, even if you have no interest in leveraging that integration.

Redux Preboiled, on the other hand, takes more of a toolkit approach. It doesn't help with setting up your Redux store or choosing your middleware. Instead, it just gives you set of useful tools, each of which you can use or ignore as needed. This flexibility results in a bit less convenience, but makes the libary useful to a wider set of Redux projects.

Ulimately, Redux Starter Kit and Preboiled are not really conflicting choices. You may well use the latter on top of a store set up with the former. I also believe there is a lot of room for cross-pollination, and I can see myself contributing bits of Preboiled to Starter Kit as well if they are good fits.

Ready for Serving

Version 0.1.0 of Redux Preboiled is now available on NPM and GitHub. The current set of helpers is still very small, but should grow over time to cover more sources of Redux boilerplate.

To get started, check out the documentation, which includes several guides and also detailed API docs for all of the helpers. Enjoy!