DEV Community: Konrad Lisiczyński

Automatic Rollback Data in Optimistic Updates: A surprising benefit of Normalized Data

Konrad Lisiczyński — Fri, 20 Jun 2025 11:56:09 +0000

When building modern web applications, optimistic updates are a crucial pattern for creating responsive user experiences. Instead of waiting for server responses, we update the UI immediately while the actual operation happens in the background. However, this pattern comes with a challenge: what happens when things go wrong?

Traditionally, handling failed optimistic updates requires manually tracking and storing the previous state for rollback. This can be error-prone and often leads to complex, boilerplate-heavy code.

Interestingly, in recent years I worked on normalization library. The interesting thing is, that my reasons were mostly to store data in normalized store to allow uutomatic data updates. If you know how Apollo handles mutations and automatically updates queries based on mutation responses, you exactly know what I am talking about. The funny thing is, that recently I realized, that having normalized store allows other benefits, for example, we could automate entire process of reverting data after error after optimistic updates!

The Traditional Approach

Let's look at how optimistic updates are typically handled, let's use @tanstack/react-query as example:

const updateTodoMutation = useMutation({
  mutationFn,
  onMutate: async newTodoPartial => {
    // 1. Manually snapshot the previous value
    const previousTodo = queryClient.getQueryData(['todos', '1']);

    // 2. Optimistically update
    queryClient.setQueryData(['todos', '1'], old => ({...old, ...newTodoPartial });

    // 3. Return rollback data
    return { previousTodo };
  },
  onError: (err, newTodoPartial, context) => {
    // 4. On error, rollback to the previous value
    queryClient.setQueryData(['todos', '1'], context.previousTodo);
  },
});

This approach has several issues:

You need to manually track what data might be affected, updated object can live in numerous queries!
Handling nested relationships is complex
If you are interested only in updating part of an object, you need to still get full current value of this object to update it
You need to provide data to rollback manually

Enter normalized data

Data normalization is typically associated with reducing data duplication and maintaining consistency. This allows us to simplify the above code like this:

const updateTodoMutation = useMutation({
  mutationFn,
  onMutate: async newTodoPartial => ({
    optimisticData: newTodoPartial,
  }),
});

That's it! All you need to do is passing object with updated values as optimisticData and you are covered! When having data normalized, all you need is some partial object, like { id: 1, name: 'Todo updated name' }. The rest can be figured out automatically, including reverting to previous object in case of an error.

The key insight is that with normalized data:

We have a single source of truth for each entity
We can use the structure of the optimistic update to find the current state
The normalized store maintains all relationships between entities

When an optimistic update comes in, we:

Look at the structure of the optimistic data
Find those same objects in our normalized store
Create a perfect snapshot of the current state
Store it as rollback data automatically

The Benefits

This approach provides several advantages:

Zero Manual Tracking: No need to manually figure out what data needs to be saved for rollback
Perfect Structural Matching: The rollback data will always match the structure of the optimistic update
Handles Complex Relationships: Because the data is normalized, we automatically handle nested relationships
Reduced Boilerplate: Your mutation code becomes much simpler:

How Does It Work?

The above snippet works thanks to addon, which adds automatic normalization and data updates to fetching libraries, like react-query. In this case, you can see related snippet from this library, which implements this feature:

queryClient.getMutationCache().subscribe(event => {
  if (
    event.type === 'updated' &&
    event.action.type === 'success' &&
    event.action.data &&
    shouldBeNormalized(normalize, event.mutation.meta?.normalize)
  ) {
    updateQueriesFromMutationData(
      event.action.data as Data,
      normalizer,
      queryClient,
    );
  } else if (
    event.type === 'updated' &&
    event.action.type === 'pending' &&
    (event.mutation.state?.context as { optimisticData?: Data })?.optimisticData
  ) {
    const context = event.mutation.state.context as {
      optimisticData: Data;
      rollbackData?: Data;
    };

    if (!context.rollbackData) {
      const rollbackDataToInject = normalizer.getCurrentData(
        context.optimisticData,
      );

      normalizer.log(
        'calculated automatically rollbackData:',
        rollbackDataToInject,
      );
      context.rollbackData = rollbackDataToInject;
    }

    updateQueriesFromMutationData(
      context.optimisticData,
      normalizer,
      queryClient,
    );
  } else if (
    event.type === 'updated' &&
    event.action.type === 'error' &&
    (event.mutation.state?.context as { rollbackData?: Data })?.rollbackData
  ) {
    updateQueriesFromMutationData(
      (event.mutation.state.context as { rollbackData: Data }).rollbackData,
      normalizer,
      queryClient,
    );
  }
});

Conclusion

Data normalization isn't just about maintaining consistency and reducing duplication. It can also provide powerful abstractions that simplify complex operations like optimistic updates and rollbacks.

By leveraging the structure of our normalized data, we can automate what was previously a manual, error-prone process. This not only reduces code complexity but also makes our applications more robust and easier to maintain.

The next time you're considering whether to normalize your application's data, remember this hidden superpower – it might just make your life a lot easier!

And... I even wonder, what comes next? Maybe there are even other benefits which are about to discover?

Want to try this out? Check out Normy - a library that implements these patterns and more!

React suspense from a practical point of view

Konrad Lisiczyński — Fri, 15 Jan 2021 14:03:15 +0000

One of the hottest topic in React world is suspense. Officially it supports lazy components for now, but in the future it could be used for more things, like data fetching, which, as you can find in the docs, you could test in experimental React version.

But the truth is, you can use suspense for anything already, right now, with standard and official React version!

What React suspense is?

Before we go on though, let's explain what exactly suspense is. Well, like the name suggests, this is a way to... suspend rendering of components, until something happens, after which rendering could be continued. That's it!

How does it work in practice? After taking example from React docs:

import React, { Suspense } from 'react';

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

you can see that OtherComponent uses React.lazy, which triggers suspense on loading. You need to catch this with a dedicated Suspense component, which could render fallback component to show loading state.

What's interesting, Suspence component is similar to catching errors, it is like catching pending state from the top.

Ok, we know how suspence works now, but how to use it with other context? Let's see how!

Using suspense in any context

I am not sure why this isn't described in React the docs officially, but it turns out, that you can trigger suspense by... throwing a promise! Then, once resolved, React component will continue to render. This approach is already used by some popular libraries, like react-i18next.

How does it work? Extremely simple! Let's create a promised based sleep function which will resolve after a second:

import React, { Suspense } from 'react';

let loaded = false; // this is just for demonstration

const sleep = () => new Promise(resolve => { 
  setTimeout(() => {
    loaded = true;
    resolve();
  }, 1000);
});



function OtherComponent() {
  if (!loaded) {
    throw sleep();
  }

  return <div>Component loaded</div>;
}

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

How will it work? Initially loaded is false, so OtherComponent will throw promise. Then, fallback component will be rendered for 1000ms, after which promise will be resolved and finally Component loaded will be rendered.

This example is for demonstration, but this can be used for more things, like data fetching, or... anything! But there is one thing, which can benefit extremely from suspence - server side rendering!

Suspense based server side rendering

Officially suspense is not yet supported by React on the server side, however there is a nice temporary bridge which allows that - react-async-ssr.

Ok, but why do we care? For people experienced with SSR, you probably know how difficult this topic is. At first glance, it is simple, it is just rendering the very same components on the server. The issue is, that for most apps you make AJAX requests to get data. You need to await those before rendering. Before suspense, there were many strategies for this, like:

double render on the server, with 1st render triggering requests, then, once requests are finished, render 2nd time with data - this causes performance issues
attach static methods to components to make requests before rendering - this is hard to setup, leads to code duplication and issues with data fetching not from top level components

The problem with those methods is, that double rendering is performance problematic, while attaching static methods is like code duplication, not to mention that you needed to somehow describe which components' static methods should be called.

With suspense though, it looks like that:
1) just render on the server
2) once requests are fired, suspense is triggered
3) once requests are finished, rendering continues
4) 2 i 3 can be repeated many times
5) rendering finishes.

This works surprisingly well, and according to me, is the best way to render apps on the server. You can write code without thinking about SSR, you can migrate not SSR apps without any code or architectural change, finally truly universal apps!

If you are interested, how this could work in practice, you could check this guide. In recent release of redux-requests, I added suspense-based SSR to the core and it works surprisingly well!

Happy suspending!

Typescript benefits without... using Typescript!

Konrad Lisiczyński — Mon, 09 Nov 2020 12:29:15 +0000

Many developers wonder, whether they should use Javascript or Typescript for their next projects, or perhaps migrate their current projects to Typescript. What I will try to show in this post though is, that this is not necessarily black and white decision, often you can use Typescript partially, often you already do thanks to editors like Visual Studio Code, as most of external libraries ship with TS types, so you already get things like hints and autocomplete, thanks to... Typescript!

Main reason to switch to Typescript

The bigger application is, the more important is to know types for our variables, functions, classes and so on, as well as to have a guarantee that we use those properly. This is exactly what Typescript gives us in the contrast to pure Javascript. What's interesting though is that you can have part of your app written in Javascript and the rest in Typescript, this is no either or decision, let's see how!

`useQuery` type

Look at the top picture of this post, notice that we can see data type despite the fact this file is written in Javascript! In order to see how this could be achieved, let's write a type for useQuery function. Don't worry what it does exactly, this won't be needed to understand this post. If you are curious though, useQuery is a React hook which gets a server response from a Redux store. Anyway, going back to writing useQuery type:

interface Response {
  data: any;
  loading: boolean;
  error: any;
}

function useQuery(props: { type: any }): Response;

Think about it as a prototype for now, this is by no means finished. First of all, type is defined as any, we will fix it soon. But there is more important thing, data is also of type any! But we really cannot define it as a specific type, because useQuery is a reusable function! What should we do then? Typescript generics to the rescue!

`Data` Generic

What are generics? You could think about them as variables for types! Let's add it to useQuery:

interface Response<Data> {
  data: Data;
  loading: boolean;
  error: any;
}

function useQuery<Data>(props: { type: any }): Response<Data>;

Now, we could use it like:

interface User {
  id: string;
  username: string;
}

const {
  data,
  loading,
  error,
} = useQuery<User>({ type: fetchUser });

Ok, but this is different than advertised at the beginning! First of all, we provide User interface to useQuery. Secondly, you can pass generics only in Typescript files! Before we fix that, let's solve type: any in useQuery. What is fetchUser? This is nothing else than Redux action creator! Actually this is a specific Redux action creator, which creates so called RequestAction from redux-requests library. Let's use this information to improve useQuery type:

import { RequestAction } from '@redux-requests/core';

interface Response<Data> {
  data: Data;
  loading: boolean;
  error: any;
}

function useQuery<Data>(props: { type: () => RequestAction }): Response<Data>;

How does it help us with Data generic though? It turns out that RequestAction also has an optional Data generic. This is hard to explain verbally, but Typescript can intelligently deduct that passed generics could be connected, which is related to type inference concept!

Generics type inference

So what we want to achieve is to have data typed without passing Data generic to useQuery. For a start, we need to make Data generic optional then:

import { RequestAction } from '@redux-requests/core';

interface Response<Data> {
  data: Data;
  loading: boolean;
  error: any;
}

function useQuery<Data = any>(props: { type: () => RequestAction }): Response<Data>;

We did it by appending = any to Data generic. Now, let's pass Data generic to RequestAction:

import { RequestAction } from '@redux-requests/core';

interface Response<Data> {
  data: Data;
  loading: boolean;
  error: any;
}

function useQuery<Data = any>(props: {
  type: () => RequestAction<Data>;
}): Response<Data>;

This is where the magic happens! The key here is that useQuery and RequestAction use the very same generic! Now, if a generic is passed to type function, then useQuery will pick it automatically! Let's see this in practice:

import { RequestAction } from '@redux-requests/core';

interface User {
  id: string;
  username: string;
}

export function fetchUser(): RequestAction<User> {
  return { type: 'FETCH_USER' };
}

We don't need to think about fetchUser implementation, all that matters is that it has User generic passed. Now, useQuery could look like that:

import { useQuery } from '@redux-requests/react';

import { fetchUser } from './actions';

const { data } = useQuery({ type: fetchUser });

That's it! This could be even Javascript file and data would have User type anyway! You don't need to pass Data generic to useQuery anymore, because it is automatically taken from fetchUser.

Of course, fetchUser has to be written in Typescript, so you might ask why we would do that. One of the reasons might be that useQuery to get user object could be used in multiple places, while fetchUser had to be declared only once. All of those places would have proper types automatically. Another benefit is that you could have those types even in Javascript files!

All in all, it depends on the use case, but this pattern of reusing generics is definitely worth knowing about. If you are interested in more possible use cases, I recommend you to check Typescript guide of redux-requests library. It takes this concept even further, for example you also get automatic type inference wherever you dispatch request actions! Happy JS and TS mixing!

Killing bad parts of Redux. Say goodbye to boilerplate.

Konrad Lisiczyński — Mon, 05 Oct 2020 11:46:56 +0000

Redux is the most popular state management library in JavaScript ecosystem for Single Page Applications. However, probably it would be much more popular if not infamous statements, like Redux is verbose, Redux boilerplate and so on. In my opinion though, there is only one part of Redux which could be easier to use, namely Redux actions. In this article I will try to point some issues with Redux actions and what we could do to mitigate them.

Not necessarily verbose parts in Redux

Before we begin, let’s talk about two things which could be considered as verbose, but in my view are not.

Separate actions and reducers

There are many complains that in Redux you need to write actions and reducers separately. For me this is a good thing and actually this was done by design. We shouldn’t think that actions and reducers have 1 to 1 relationship. One reducer can react to many separate actions… and many reducers can react to the very same action. This is one of the most powerful features of Redux, often not appreciated.

Switch statements in reducers

Many of us hate switch statements in reducers. This is opinionated though and there are many libraries which allow to write reducers in different ways. We will write such a helper a little later in this article too!

Truly verbose parts in Redux

For me, the most problematic parts of Redux are related to actions, constants and thunks. What’s more, those problems are not only about verbosity, but also about potential bugs, like types collision. Let’s name those issues and try to fix them one by one, until there is nothing left!

Constants

In my head, this was always the most annoying thing in Redux. Writing separate actions and constants is not only verbose, but also error-prone. Moreover, it also introduces some disorder to our imports. For example, you need constants to recognize actions, but you need actions (action creators to be precise, but let me stick with actions shortcut for simplicity) to be able to dispatch them. Often you end up importing an action and a constant related to the very same action! What if we could give up constants altogether without any compromise? Let’s try to write a helper function!

const createAction = (name, action = () => ({})) => {
  const actionCreator = (...params) => ({
    type: name,
    ...action(...params),
  });
  actionCreator.toString = () => name;
  return actionCreator;
};

So, what we just did? Instead of explaining, let’s just try to use it! Imagine we have an action like that:

const INCREMENT_BY_VALUE = 'INCREMENT_BY_VALUE';

const incrementByValue = value => ({
  type: INCREMENT_BY_VALUE,
  value,
)};

We could rewrite it like that now:

const incrementByValue = createAction(
  'INCREMENT_BY_VALUE',
  value => ({ value }),
);

As you can see, we pass INCREMENT_BY_VALUE type as the 1st argument to createAction, which does the rest job for us. But wait a second, we don’t have constants anymore, so how we could use it in reducers for example? The key is actionCreator.toString = () => name line in createAction body, which allows us to get action type constant like incrementByValue.toString(). So, the action is the source of its type at the same time, so no more keeping constants and actions in sync, you need just actions and you are done! As a bonus, sometimes you won’t even need to call toString() manually, see how in the next paragraph!

Avoiding manual `toString` calls in reducers

Before we solve this issue, see how a reducer reacting to incrementByValue action could look like:

const valueReducer = (state = 0, action) => {
  switch (action.type) {
    case incrementByValue.toString():
      return state + action.value;
    default:
      return state;
  }
};

It uses the standard switch statement, which some people love and some people hate, the only issue in comparison to normal reducers is this nasty incrementByValue.toString(), which is needed to get the proper INCREMENT_BY_VALUE type. Fortunately for switch and toString haters, there is a solution, let’s create a reducer helper function:

const createReducer = (handlers, defaultState) => {
  return (state, action) => {
    if (state === undefined) {
      return defaultState;
    }

    const handler = handlers[action.type];

    if (handler) {
      return handler(state, action);
    }

    return state;
  };
};

Now, we could refactor valueReducer as:

const valueReducer = createReducer({
  [incrementByValue]: (state, action) => state + action.value,
}, 0);

As you can see, no switch or toString anymore! Because we replaced switch with handlers object, we can use computed property [incrementByValue], which calls toString automatically!

Thunks

For many developers thunks are used to create side-effects, often as an alternative to redux-saga library. For me they are something more though. Often I need an argument in my actions, but such an argument which is already present in Redux store. Again, there are many opinions about this, but for me passing to action something already present in the store is an antipattern. Why? Imagine you use Redux with React and you dispatch an action from React. Imagine that this action needs to be passed something already kept in the store. What would you do? You would read this value by useSelector, connect or something similar first, just to pass it to the action. Often this component wouldn’t even need to do that, because this value could be only action’s dependency, not React component’s directly! If Redux action could read the state directly, this React component could be much simpler! So… thunks to the rescue! Let’s write one!

const incrementStoredValueByOne = () => (dispatch, getState) => {
  const { value } = getState(); // we could use selector here
  return dispatch({
    type: 'INCREMENT_STORED_VALUE_BY_ONE',
    newValue: value + 1,
  });
};

Before we continue, of course this example might to too naive, we could solve this problem by a proper logic in reducer, it is just to illustrate the problem. Anyway, notice, that this thunk reads current value from the store instead of getting it as an argument. Problem solved then! Not so quick! Again, what about types? If you need to refactor an action to thunk just to read state from Redux directly, you will end up with the constants issue we already solved by createAction again. So what should we do? Do something similar but just for thunks!

const createThunk = (name, thunk) => {
  const thunkCreator = (...params) => (dispatch, getState) => {
    const actionToDispatch = thunk(...params)(dispatch, getState);
    return dispatch({ type: name, ...actionToDispatch });
  };

  thunkCreator.toString = () => name;
  return thunkCreator;
};

Now, we could refactor our thunk like that:

const incrementStoredValueByOne = createThunk(
  'INCREMENT_STORED_VALUE_BY_ONE',
  () => (dispatch, getState) => {
    const { value } = getState(); // we could use selector here
    return { newValue: value + 1 };
  },
};

Again, no constants! incrementStoredValueByOne.toString() will return INCREMENT_STORED_VALUE_BY_ONE, so you could even listen to this thunk in your reducers directly!

Introducing `redux-smart-actions` library

Let me introduce redux-smart-actions library, the fastest way to write Redux actions!

This library provides all the utilities like createAction, createThunk, createReducer, and at the same time solves all mentioned issues not covered in this article. Points 1 and 2 are solved by the optional babel-plugin-redux-smart-actions. Point 3 is solved as Typescript types are included in the library. And point 4… is solved by any library anyway, including this one ;)

Basically with its help you could transform your code like that:

+ import {
+   createSmartAction,
+   createSmartThunk,
+   createReducer,
+   joinTypes,
+ } from 'redux-smart-actions';
+
- const RESET_VALUE = 'RESET_VALUE';
- const SET_VALUE = 'SET_VALUE';
- const INCREMENT_IF_POSITIVE = 'INCREMENT_IF_POSITIVE';
-
- const resetValue = () => ({ type: RESET_VALUE });
+ const resetValue = createSmartAction();

- const setValue = value => ({ type: SET_VALUE, value });
+ const setValue = createSmartAction(value => ({ value }));

- const incrementIfPositive = () => (dispatch, getState) => {
+ const incrementIfPositive = createSmartThunk(() => (dispatch, getState) => {
    const currentValue = getState().value;

    if (currentValue <= 0) {
      return null;
    }

-   return dispatch({
-     type: INCREMENT_IF_POSITIVE,
-     value: currentValue + 1,
-   });
+   return { value: currentValue + 1 });
- };
+ });

- const valueReducer = (state = 0, action) => {
-   switch (action.type) {
-     case RESET_VALUE:
-       return 0;
-     case SET_VALUE:
-     case INCREMENT_IF_POSITIVE:
-       return action.value;
-     default:
-       return state;
-   }
- }
+ const valueReducer = createReducer({
+   [resetValue]: () => 0,
+   [joinTypes(setValue, incrementIfPositive)]: (state, action) => action.value;
+ }, 0);

Don’t be afraid that this library is new, I use it in several very big projects already without any issues, so I very recommend you to at least try it! If you happen to like it, any token of appreciation like giving a star to the github repo is very much welcome!

Taming network with redux-requests, part 10 - Server side rendering and the future

Konrad Lisiczyński — Tue, 04 Aug 2020 12:49:38 +0000

In the previous part of this series we discussed using redux-requests with external libraries and promises.

In this part we will cover how redux-requests can help you to achieve truly universal code for server side rendering.

What is server side rendering?

Like its name suggests, it is just a way to render you app on the server side. Why would you do that for single page application? There are many reasons, like SEO, improving performance in some cases, static rendering like in Gatsby and probably many others.

Anyway server side rendering is a very complex topic and there are many ways how to go about it. Many people use the strategy around React components, for instance they attach static methods to components which make requests and return promises with responses, then they wrap them in Promise.all. I don't recommend this strategy when using Redux, because this requires additional code and potentially double rendering on server, but if you really want to do it, it is possible as dispatched request actions return promise resolved with response.

However, this guide won't be for introducing server side rendering, it will show alternative strategies for SSR with the help of this library. You don't need to use any of them, but you might want to check them out as they could potentially simplify your SSR apps.

Prerequisites

Before we begin, be advised that this strategy requires to dispatch request actions on Redux level, at least those which have to be fired on application load. So for instance you cannot dispatch them inside React componentDidMount or in useEffect. The obvious place to dispatch them is in the place you create store, like store.dispatch(fetchBooks()). However, what if your app has multiple routes, and each route has to send different requests? Well, you need to make Redux aware of current route. I recommend to use a router with first class support for Redux, namely redux-first-router. If you use react-router though, it is fine too, you just need to integrate it with Redux with connected-react-router or
redux-first-history. Then you could listen to route change actions and dispatch proper request actions, for example from middleware, sagas, just whatever you use.

Basic setup

On the server you need to pass ssr: 'server' to handleRequests when running on the server (to resolve/reject requestsPromise in the right time) and ssr: 'client' on the client (not to repeat requests again on the client which we run on the server) option to handleRequests. Here you can see a possible implementation:

import { createStore, applyMiddleware, combineReducers } from 'redux';
import axios from 'axios';
import { handleRequests } from '@redux-requests/core';
import { createDriver } from '@redux-requests/axios';

import { fetchBooks } from './actions';

export const configureStore = (initialState = undefined) => {
  const ssr = !initialState; // if initialState is not passed, it means we run it on server

  const {
    requestsReducer,
    requestsMiddleware,
    requestsPromise,
  } = handleRequests({
    driver: createDriver(
      axios.create({
        baseURL: 'http://localhost:3000',
      }),
    ),
    ssr: ssr ? 'server' : 'client',
  });

  const reducers = combineReducers({
    requests: requestsReducer,
  });

  const store = createStore(
    reducers,
    initialState,
    applyMiddleware(...requestsMiddleware),
  );

  store.dispatch(fetchBooks());
  return { store, requestsPromise };
};

// on the server
import React from 'react';
import { renderToString } from 'react-dom/server';
import { Provider } from 'react-redux';

// in an express/another server handler
const { store, requestsPromise } = configureStore();

requestsPromise
  .then(() => {
    const html = renderToString(
      <Provider store={store}>
        <App />
      </Provider>,
    );

    res.render('index', {
      html,
      initialState: JSON.stringify(store.getState()),
    });
  })
  .catch(e => {
    console.log('error', e);
    res.status(400).send('something went wrong');
    // you can also render React too, like for 404 error
  });

As you can see, compared to what you would normally do in SSR for redux app, you only need to pass the extra ssr option to handleRequests and wait for requestsPromise to be resolved.

How does it work?

But how does it work? The logic is based on an internal counter. Initially it is set to 0 and is increased by 1 after each request is initialized. Then, after each response it is decreased by 1. So, initially after a first request it gets positive and after all requests are finished, its value is again set back to 0. And this is the moment which means that all requests are finished and requestsPromise is resolved (with all success actions).

In case of any request error, requestsPromise will be rejected with object { errorActions: [], successActions: [] }.

There is also more complex case. Imagine you have a request x, after which you would like to dispatch another y. You cannot do it immediately because y requires some information from x response. Above algorythm would not wait for y to be finished, because on x response counter would be already reset to 0. There are two action.meta attributes to help here:

dependentRequestsNumber - a positive integer, a number of requests which will be fired after this one, in above example we would put dependentRequestsNumber: 1 to x action, because only y depends on x
isDependentRequest - mark a request as isDependentRequest: true when it depends on another request, in our example we would put isDependentRequest: true to y, because it depends on x

You could even have a more complicated situation, in which you would need to dispatch z after y. Then you would also add dependentRequestsNumber: 1 to y and isDependentRequest: true to z. Yes, a request can have both of those attibutes at the same time! Anyway, how does it work? Easy, just a request with dependentRequestsNumber: 2 would increase counter by 3 on request and decrease by 1 on response, while an action with isDependentRequest: true would increase counter on request by 1 as usual but decrease it on response by 2. So, the counter will be reset to 0 after all requests are finished, also dependent ones.

What's next?

Actually this is the last part of this series, at least for now. If you would like to learn more, I recommend to try redux-requests in real apps, read the official docs, see the official examples.

Anyway, what about the future? Actually having all requests standardized by one convention opens many new ideas to extend this library even more! Some of the ideas I have:

more drivers, maybe local driver which could allow using this library for local state too?
more effects, like takeLeading
declarative persistent cache
offline mutations leading to true offline apps
subscriptions
graphql driver addons, like subscriptions, client directives and generally keeping on par with apollo server features
selectors creators like mapQuery, mergeQueries
React suspense integration
debounce/throthling
pooling
automatic normalisation garbage collection based on reference
getNodeById selectors when using normalisation which would work similarly to graphql fragments

However, this requires a huge amount of work and because I am doing this library in my free-time, I will be grateful for any help!

So, if you like this library and you would like to help, you could:

star the repo
contribute to the library
like this post series, tweet it and so on
financially contribute on open collective

For now thanks for keeping up with this series! If you have any questions, go ahead and write some comments, I will happily answer! In the meantime, stay tuned!

Taming network with redux-requests, part 9 - External libraries and promises

Konrad Lisiczyński — Mon, 03 Aug 2020 11:36:51 +0000

In the previous part of this series we discussed mocking and how to use multiple drivers at the same time within one app.

In this part we will cover how to integrate redux-requests with external libraries or if you would like to use it with promises directly.

External API libraries

Sometimes, as a front-end developer you will just get a ready to use library which handles connection with server. Then, you won't be able to use axios or fetch API driver, you need something else. If the library you received is promised based, which is usually the case, then you could use promise driver.

Using `promise` driver

To install it, just run:

npm install @redux-requests/promise

Then, as for any driver, you must pass it to handleRequests:

import { createDriver } from '@redux-requests/promise';

handleRequests({
  driver: createDriver({
    AbortController: window.AbortController,
    processResponse: response =>  ({ data: response }),
  }),
});

AbortController is optional, by default it will use AbortController if available, with fallback to DummyAbortController which does nothing. If your environment doesn't support AbortController, you could pass a polyfill.
If you don't, requests aborts won't work (but the app will still work, you will just lose the possibility to use automatic aborts feature).

processResponse is also optional, the default is response => ({ data: response }), it is useful if your promises resolve to more things than data, then you could for instance use response => ({ data: response.data }), or even response => ({ data: response.data, headers: response.headers })

Once you have done that, you can use promises in request actions:

const fetchPhoto = id => ({
  type: FETCH_PHOTO,
  request: {
    promise: axios.get(`/photos/${id}`),
  },
});

Also note, that just like for mock driver, for mutations you need to pass meta.asMutation: true in your request actions, so the core library could know whether a request is a query or a mutation. For many drivers like axios, fetch and graphql it is not usually necessary as the library can deduct whether something is a query or a mutation by looking at request config, like GET request method will be typically a query while POST a mutation.

What's next?

In the next part we will discuss server side rendering, SSR in short and how redux-requests can help you writing truly universal code between client and server.

Taming network with redux-requests, part 8 - Mocking and multiple drivers

Konrad Lisiczyński — Thu, 30 Jul 2020 14:06:31 +0000

In the previous part of this series we discussed caching.

In this part we will cover mocking and a possibility to use multiple drivers in one app.

What is mocking and when it is useful?

Mocking is like faking. Sometimes, usually as front-end developer you happen to be in a position when you need to work on a feature but this feature requires to integrate with back-end. Often back-end could be not ready yet or just buggy. Not always you can afford to wait, what to do then? The answer is mocking. You can mock some server responses and start working before API is finished, and then, once it is, you can replace mocked responses with real ones. In real life this happens so often that it would be great to make this process as easy as possible. Fortunately redux-requests has a dedicated driver for such a situation!

Using `mock` driver

As you probably noticed, redux-requests supports drivers concept. You can use it with axios, Fetch API, GraphQL, anything! You can write your own drivers. You can even use multiple at the same time. One of those drivers is mock driver. Let's see how to use it and how it could help us when we don't have back-end finished and we want to start working.

To install the package, just run:

$ npm install @redux-requests/mock

Then, as always, pass it to handleRequests first:

import { handleRequests } from '@redux-requests/core';
import { createDriver } from '@redux-requests/mock';

handleRequests({
  driver: createDriver({
    // optional, in ms, defining how much time mock request would take, useful for testing spinners
    timeout: 1000,
  }),
});

Then, start using it inside your request actions:

const fetchPhoto = id => ({
  type: FETCH_PHOTO,
  request: {
    response: {
      data: {
        id,
        title: 'accusamus beatae ad facilis cum similique qui sunt',
      },
    },
  },
});

const fetchPhotoWhichWillFail = id => ({
  type: FETCH_PHOTO_WHICH_WILL_FAIL,
  request: {
    error: { status: 404 },
  },
});

Also note, that for mutations you need to pass meta.asMutation: true in your request actions, so the core library could know whether a request is a query or a mutation. For many drivers like axios, fetch and graphql it is not usually necessary as the library can deduct whether something is a query or a mutation by looking at request config, like GET request method will be typically a query while POST a mutation.

Anyway, this is all there is to it! Then, once part/all of mocked endpoints are finished, all you need to do is to replace mock driver with something else, like axios. All other things will become unchanged. This is one of the reasons why driver approach could be handy.

Ok, but there is one last thing. Usually you won't mock everything. So how to use mock driver for some actions and another like axios in others? For that you need to use multiple drivers.

Using multiple drivers

Multiple drivers are useful especially for mocking scenario. But it could be also great if for instance you use multiple ways to communicate with server/servers, like axios together with graphql. In could be also useful when you would like to switch from axios to Fetch API for instance without refactoring everything at the same time, but gradually. Anyway, let's see how to do it with axios and mock drivers together:

import axios from 'axios';
import { handleRequests } from '@redux-requests/core';
import { createDriver as createAxiosDriver } from '@redux-requests/axios';
import { createDriver as createMockDriver } from '@redux-requests/mock';

handleRequests({
  driver: {
    default: createAxiosDriver(axios),
    mock: createMockDriver({ timeout: 1000 }),
  },
});

As you can see, the default driver is axios, so how to mark a request to be run by mock driver? Just pass the key you assigned to mock driver (mock in our case) in action.meta.driver, for instance:

const fetchPhoto = id => ({
  type: FETCH_PHOTO,
  request: {
    response: {
      data: {
        id,
        title: 'accusamus beatae ad facilis cum similique qui sunt',
      },
    },
  },
  meta: { driver: 'mock' },
});

Then, once fetchPhoto is ready on the back-end, you could refactor it to something like that:

const fetchPhoto = id => ({
  type: FETCH_PHOTO,
  request: {
    url: `/photo/${id}`,
  },
});

With such an approach, you could really surprise your team, you could easily integrate your app with a new and shiny back-end in minutes!

What's next?

In the next part we will cover using redux-requests with promise based libraries.

Taming network with redux-requests, part 7 - Caching

Konrad Lisiczyński — Wed, 29 Jul 2020 11:14:07 +0000

In the previous part of this series we discussed optimistic updates and how to avoid some traps when using them.

In this part we will cover caching.

What is caching?

Caching is a way to improve performance of an operation by saving its result somewhere, which can be retrieved later when needed instead of repeating the same operation again. One of such operation can be AJAX request, which is worth caching if possible, because with caching we can decrease communication with server. This not only could make our app much more responsive, especially on mobile devices, but also would decrease our server load.

When to cache?

Of course you cannot usually cache everything. Sometimes you cannot afford to do it, because you might need a fresh data from your server all the time. But if data is static, or relatively static and you could consider caching something even for a small period of time, if might be worth it, especially for slow networks or endpoints, or if a request could be repeated many times in a short period of time.

Caching with `redux-requests`

To activate it, just pass cache: true to handleRequests:

import { handleRequests } from '@redux-requests/core';

handleRequests({
  ...otherOptions,
  cache: true,
});

After this, you can use meta.cache in request actions:

const fetchBooks = () => ({
  type: FETCH_BOOKS,
  request: { url: '/books'},
  meta: {
    cache: 10, // in seconds, or true to cache forever
  },
});

What will happen now is that after a succesfull book fetch (to be specific after FETCH_BOOKS_SUCCESS is dispatched), any FETCH_BOOKS actions for 10 seconds won't trigger any AJAX calls and the following FETCH_BOOKS_SUCCESS will contain previously cached server response. You could also use cache: true to cache forever.

Cache with `cacheKey`

Sometimes you would like to invalidate your cache based on a key, so if a key is changed, then you would bypass the cache and network would be hit. You can use meta.cacheKey for that:

const fetchBooks = language => ({
  type: FETCH_BOOKS,
  request: { url: '/books', params: { language } },
  meta: {
    cache: 10,
    cacheKey: language, // if language changes, cache won't be hit and request will be made
  },
});

Cache with `requestKey`

Another use case is that you might want to keep a separate cache for the same request action based on a key. Then, like for usual not cached queries, you could use meta.RequestKey. For example:

const fetchBook = id => ({
  type: FETCH_BOOK,
  request: { url: `/books/${id}`},
  meta: {
    cache: true,
    requestKey: id,
  },
});

/* then, you will achieve the following behaviour:
- GET /books/1 - make request, cache /books/1
- GET /books/1 - cache hit
- GET /books/2 - make request, cache /books/2
- GET /books/2 - cache hit
- GET /books/1 - cache hit
*/

`cacheKey` and `requestKey` together

You can also use cacheKey and requestKey at the same time, then different cacheKey will be able to invalidate cache for each requestKey individually, like:

const fetchBook = (id, language) => ({
  type: FETCH_BOOK,
  request: { url: `/books/${id}`, params: { language } },
  meta: {
    cache: true,
    cacheKey: language,
    requestKey: id,
  },
});

/* then, you will achieve the following behaviour:
- GET /books/1?language=en - make request, cache /books/1
- GET /books/1?language=en - cache hit
- GET /books/2?language=de - make request, cache /books/2
- GET /books/2?language=en - make request, cache /books/2 again due to changed language
- GET /books/2?language=en - cache hit
*/

There is an interesting requestKey and cacheKey relation. Passing the same requestKey and cacheKey is the same like passing only requestKey, because requests are stored separately for each requestKey, so cache invalidation with the same cacheKey could never happen.

Cache with `requestCapacity`

When you use cache with requestKey, like without caching you can be worried about storing too many queries in state. You can use requestsCapacity to prevent that:

const fetchBook = id => ({
  type: FETCH_BOOK,
  request: { url: `/books/${id}`},
  meta: {
    cache: true,
    requestKey: id,
    requestsCapacity: 2,
  },
});

/* then, you will achieve the following behaviour:
- GET /books/1 - make request, cache /books/1
- GET /books/1 - cache hit
- GET /books/2 - make request, cache /books/2
- GET /books/2 - cache hit
- GET /books/1 - cache hit
- GET /books/3 - make request, cache /books/3, invalidate /books/1 cache
- GET /books/1 - make request, cache /books/1, invalidate /books/2 cache
*/

Manual cache clearing

If you need to clear the cache manually for some reason, you can use clearRequestsCache action:

import { clearRequestsCache } from '@redux-requests/core';

// clear the whole cache
dispatch(clearRequestsCache());

// clear only FETCH_BOOKS cache
dispatch(clearRequestsCache([FETCH_BOOKS]));

// clear only FETCH_BOOKS and FETCH_AUTHORS cache
dispatch(clearRequestsCache([FETCH_BOOKS, FETCH_AUTHORS]));

Note however, that clearRequestsCache won't remove any query state, it will just remove cache timeout so that the next time a request of a given type is dispatched, AJAX request will hit your server. So it is like cache invalidation operation. To remove also data you can use resetRequests action.

What's next?

In the next part we will touch imperfect world in which we live, when frontend developer is expected to start working on a feature even if backend is not yet ready.

Taming network with redux-requests, part 6 - Optimistic updates

Konrad Lisiczyński — Mon, 27 Jul 2020 22:31:42 +0000

In the previous part of this series we discussed the usage with GraphQL.

In this part we will cover optimistic updates and how redux-requests can make them reliable and avoid some common traps.

What are optimistic updates?

Sometimes you don't want to wait for a mutation response to update your data. If you can predict in advance how data will be updated, you might want to update it immediately even before the server response. This can improve perceived performance of your app and is known as optimistic update.

Optimistic update example

Let's write a normal mutation first:

const likeBook = book => ({
  type: LIKE_BOOK,
  request: {
    url: `/book/${book.id}/like`,
    method: 'put',
  },
  meta: {
    mutations: {
      FETCH_BOOKS: (data, mutationData) => 
        data.map(v => book.id === v.id ? mutationData : v),
    },
  },
});

How to refactor it to optimistic update? Let's assume that books have id and numberOfLikes attributes, for instance { id: '1', numberOfLikes: 10 }. You can do it like that:

const likeBook = book => ({
  type: LIKE_BOOK,
  request: {
    url: `/book/${book.id}/like`,
    method: 'put',
  },
  meta: {
    mutations: {
      FETCH_BOOKS: {
        updateDataOptimistic: data => 
          data.map(v => book.id === v.id ? book : v),
      },
    },
  },
});

So, above we have a mutation action with optimistic update for FETCH_BOOKS query. updateDataOptimistic is called right away after LIKE_BOOK action is dispatched, so not on success like for normal mutations.

Error handling

There is one problem though, what if our optimism is... too optimistic? Any request can potentially fail. With normal mutation, we can just handle error and of course we won't update data. But here we do without even knowing whether the mutation will succeed. Because of that, we need to tell the library how to revert optimistic update. We can use revertData for that:

const likeBook = book => ({
  type: LIKE_BOOK,
  request: {
    url: `/book/${book.id}/like`,
    method: 'put',
  },
  meta: {
    mutations: {
      FETCH_BOOKS: {
        updateDataOptimistic: data =>
          data.map(v => (book.id === v.id ? book : v)),
        revertData: data =>
          data.map(v =>
            book.id === v.id ? { ...v, numberOfLikes: v.numberOfLikes - 1 } : v,
          ),
      },
    },
  },
});

revertData is called on LIKE_BOOK_ERROR, so you can amend the data and revert deletion in case of an error.

You might ask, why revertData is even needed, cannot this be figured out automatically? Indeed there are some libraries, even very famous ones, which use a different approach. They copy state before optimistic updates and revert it back for you. Let's simulate this:

We have { id: '1', numberOfLikes: 10 } book
We optimistically update it to { id: '1', numberOfLikes: 11 }, make AJAX request and copy previous state { id: '1', numberOfLikes: 10 } just in case.
The request failed, we update book back to { id: '1', numberOfLikes: 10 }

So far so good. But this simplified approach doesn't take race conditions and concurrent requests at all into account. Imagine another scenario:

We have { id: '1', numberOfLikes: 10 } book
We optimistically update it to { id: '1', numberOfLikes: 11 }, make AJAX request and copy previous state { id: '1', numberOfLikes: 10 } just in case.
Before above mutation is finished, the user is super quick and executes this mutation once more (we assume one person can like a book many times)
So, we optimistically update book to { id: '1', numberOfLikes: 12 }, make another AJAX request and copy previous state { id: '1', numberOfLikes: 11 } just in case.
Now, many combinations will be problematic, but imagine the simplest one, both requests will fail, in the order they were sent.
We receive error for the first mutation, so book is reverted to { id: '1', numberOfLikes: 10 } - this is wrong, it should be 11, update of 2nd mutation is gone
We receive error for the second mutation, so book is reverted to { id: '1', numberOfLikes: 11 } - this is again wrong, it should be 10, the initial value.

Imagine other scenarios, like combined successes with errors, responses received in different order than requests, many things could go wrong with the automated solution.

Updating data after server response

Even when using optimistic update, at the very same time you can still use updateData to further update data on success response. This might be useful if you cannot predict data update fully. For example you might want to do optimistic update to add an item with random id and amend it to a proper
id value once mutation response is delivered.

What's next?

In the next part of the series we will cover caching.

Taming network with redux-requests, part 5 - GraphQL

Konrad Lisiczyński — Thu, 23 Jul 2020 15:12:17 +0000

In the previous part of this series we discussed data normalisation and how this process could be automated even in REST world.

In this part we will cover redux-requests usage with GraphQL.

Redux and GraphQL combination

Before analyzing the usage, let's answer one question first, why GraphQL with Redux? Didn't GraphQL killed Redux? Why should we bother if we have Apollo and Relay?

The short answer is, because comparing Redux and GraphQL is like comparing apples and oranges. GraphQL is the alternative way to communicate with servers (mainly to REST) and Redux is just state management library. If using Redux with REST is valid, it is also for GraphQL.

The longer answer is, why server communication should totally change the way we write frontend? Why refactoring Redux/React application should involve rewriting of everything to Apollo/Relay? Is this really justified to rewrite everything just because network communication changed? What if something new will appear, will we do this again?

Don't get me wrong now, I very like Apollo for example and inspired a lot from them, but personally I still prefer Redux. I like the concept of separating business logic from view layer and I like Redux simplicity. So, I don't want to start any war now, I will just say why some people might still use Redux even with GraphQL, keeping big appreciation for apollo client and relay:

like previously mentioned, UI separation from business logic is important in my view, for a start it makes for instance React components much cleaner, secondly replacing UI framework to something else won't involve business logic rewriting, also unit testing is much easier due to this separation
technology changes, we had REST hype, now we have GraphQL hype, tomorrow we will have something else, I favour driver approach, encapsulating network communication protocol somehow, so when you switch to something else, you don't need to rewrite most of the app but only the communication layer
Apollo and Relay advocates having fetching logic inside React components, while it might be convenient to do this sometimes, often it is problematic, for instance I had issues with refetching on resize event because component with useQuery rerendered and I had caching disabled
fetching logic connected with rendering is not always the most convenient, a resent blog post from React docs shows different problems and some strategies to improve performance for example, looking at these I asked myself, would they have those problems if they fetched queries on Redux layer in the first place? Then rendering phase would be independent so we wouldn't even need to think about such issues as they wouldnt't even exist

Probably there are more reasons for my preference, but the bottom line is this, people have different opinions and preferences. Some still prefer Redux, some prefer dedicated GraphQL clients, giving up Redux alltogether. I recommend you to see below examples, actually the way of writing is quite similar, the most important reason is keeping business logic on UI level vs Redux level.

Setup of GraphQL driver

First, you need to install the graphql driver:

$ npm install @redux-requests/graphql

Then, to use this driver, just import it and pass to handleRequests, like you would do with other drivers:

import { handleRequests } from '@redux-requests/core';
import { createDriver } from '@redux-requests/graphql';

handleRequests({
  driver: createDriver({ url: 'http://localhost:3000/graphql' }),
});

Basic usage of GraphQL driver

Let's assume we have the following GraphQL schema:

type Book {
  id: ID!
  title: String!
  author: String!
  liked: Boolean!
}

type File {
  filename: String!
  mimetype: String!
  encoding: String!
}

type Query {
  books: [Book!]!
  book(id: ID!): Book
}

type Mutation {
  editBook(book: Book!): Book
  singleUpload(file: Upload!): File!
  multipleUpload(files: [Upload!]!): [File!]!
}

In order to send a query, just do it in a similar fashion to other drivers. The only one thing really specific to GraphQL is a way you define your actions. Let's create an action to fetch books:

import { gql } from '@redux-requests/graphql';

const fetchBooks = () => ({
  type: 'FETCH_BOOKS',
  request: {
    query: gql`
      {
        books {
          id
          title
          author
          liked
        }
      }
    `,
    headers: {
      SOMEHEADER: 'SOMEHEADER',
    },
  },
});

As you see, there is nothing fancy here, you just write GraphQL. Notice we wrap it in gql tag. Currently it only trims queries, but in the future it could do other stuff, so it is recommended to wrap all your queries in gql, especially that it will hint most of code editors to properly highlight them. Also notice that it is possible to pass headers, which could be useful for authentication for instance.

Passing variables

Now, let's fetch a specific book, which requires using variables:

const fetchBook = id => ({
  type: 'FETCH_BOOK',
  request: {
    query: gql`
      query($id: ID!) {
        book(id: $id) {
          id
          title
          author
          liked
        }
      }
    `,
    variables: { id },
  },
});

Using GraphQL fragments

Notice Book properties repeated across those two queries. As you probably know, the answer for this problem is GraphQL fragment, which you can create like this:

const bookFragment = gql`
  fragment BookFragment on Book {
    id
    title
    author
    liked
  }
`;

const fetchBook = id => ({
  type: 'FETCH_BOOK',
  request: {
    query: gql`
      query($id: ID!) {
        book(id: $id) {
          ...BookFragment
        }
      }
      ${bookFragment}
    `,
    variables: { id },
  },
});

Mutations

Mutations are done like queries, just use GraphQL language:

const editBook = book => ({
  type: 'EDIT_BOOK',
  request: {
    query: gql`
      mutation($book: Book!) {
        editBook(book: $book) {
          id
          title
          author
          liked
        }
      }
    `,
    variables: { book },
  },
  meta: {
    mutations: {
      FETCH_BOOKS: data => ({
        books: data.books.map(v => (v.id === book.id ? book : v)),
      }),
      FETCH_BOOK: data => ({
        book: data.book && data.book.id === book.id ? book : data.book,
      }),
    },
  },
});

File uploads

Upload files according to GraphQL multipart request specification, which is also used by other GraphQL clients and servers, like Apollo, is also supported.

So, to upload a single file:

const uploadFile = file => ({
  type: 'UPLOAD_FILE',
  request: {
    query: gql`
      mutation($file: Upload!) {
        singleUpload(file: $file) {
          filename
          mimetype
          encoding
        }
      }
    `,
    variables: { file },
  },
});

... or, to upload multiple files:

const uploadFiles = files => ({
  type: 'UPLOAD_FILES',
  request: {
    query: gql`
      mutation($files: [Upload!]!) {
        multipleUpload(files: $files) {
          filename
          mimetype
          encoding
        }
      }
    `,
    variables: { files },
  },
});

So, you can do it exactly in the same way like other libraries supporting GraphQL multipart request specification.

Normalisation with GraphQL

Because normalisation is the core feature in redux-requests, you could use automatic normalisation for GraphQL too. For instance, assumming that book queries are normalized, you could refactor editBook like that

const editBook = book => ({
  type: 'EDIT_BOOK',
  request: {
    query: gql`
      mutation($book: Book!) {
        editBook(book: $book) {
          id
          title
          author
          liked
        }
      }
    `,
    variables: { book },
  },
  meta: {
    normalize: true,
  },
});

So, we replaced meta.mutations with meta.normalize. Actually if you have experience with apollo, you will notice that from user perspective normalisation works in the very same way!

What's next?

In the next part, we will cover optimistic updates.

Taming network with redux-requests, part 5 - GraphQL

Konrad Lisiczyński — Thu, 23 Jul 2020 14:45:59 +0000

In the previous part of this series we discussed data normalisation and how this process could be automated even in REST world.

In this part we will cover redux-requests usage with GraphQL.

Redux and GraphQL combination

Before analyzing the usage, let's answer one question first, why GraphQL with Redux? Didn't GraphQL killed Redux? Why should we bother if we have Apollo and Relay?

like previously mentioned, UI separation from business logic is important in my view, for a start it makes for instance React components much cleaner, secondly replacing UI framework to something else won't involve business logic rewriting, also unit testing is much easier due to this separation
technology changes, we had REST hype, now we have GraphQL hype, tomorrow we will have something else, I favour driver approach, encapsulating network communication protocol somehow, so when you switch to something else, you don't need to rewrite most of the app but only the communication layer
Apollo and Relay advocates having fetching logic inside React components, while it might be convenient to do this sometimes, often it is problematic, for instance I had issues with refetching on resize event because component with useQuery rerendered and I had caching disabled
fetching logic connected with rendering is not always the most convenient, a resent blog post from React docs shows different problems and some strategies to improve performance for example, looking at these I asked myself, would they have those problems if they fetched queries on Redux layer in the first place? Then rendering phase would be independent so we wouldn't even need to think about such issues as they wouldnt't even exist

Setup of GraphQL driver

First, you need to install the graphql driver:

$ npm install @redux-requests/graphql

Then, to use this driver, just import it and pass to handleRequests, like you would do
with other drivers:

import { handleRequests } from '@redux-requests/core';
import { createDriver } from '@redux-requests/graphql';

handleRequests({
  driver: createDriver({ url: 'http://localhost:3000/graphql' }),
});

Basic usage of GraphQL driver

Let's assume we have the following GraphQL schema:

type Book {
  id: ID!
  title: String!
  author: String!
  liked: Boolean!
}

type File {
  filename: String!
  mimetype: String!
  encoding: String!
}

type Query {
  books: [Book!]!
  book(id: ID!): Book
}

type Mutation {
  editBook(id: ID!): Book
  singleUpload(file: Upload!): File!
  multipleUpload(files: [Upload!]!): [File!]!
}

In order to send a query, just do it in a similar fashion to other drivers. The only one thing really specific to GraphQL is a way you define your actions. Let's create an action
to fetch books:

import { gql } from '@redux-requests/graphql';

const fetchBooks = () => ({
  type: 'FETCH_BOOKS',
  request: {
    query: gql`
      {
        books {
          id
          title
          author
          liked
        }
      }
    `,
    headers: {
      SOMEHEADER: 'SOMEHEADER',
    },
  },
});

As you see, there is nothing fancy here, you just write GraphQL. Notice we wrap it in gql tag. Currently it only trims queries, but in the future it could do other stuff,
so it is recommended to wrap all your queries in gql, especially that it will hint most of code editors to properly highlight them. Also notice that it is possible to pass headers, which could be useful for authentication for instance.

Passing variables

Now, let's fetch a specific book, which requires using variables:

const fetchBook = id => ({
  type: 'FETCH_BOOK',
  request: {
    query: gql`
      query($id: ID!) {
        book(id: $id) {
          id
          title
          author
          liked
        }
      }
    `,
    variables: { id },
  },
});

Using GraphQL fragments

Notice Book properties repeated across those two queries. As you probably know, the answer for this problem is GraphQL fragment, which you can create like this:

const bookFragment = gql`
  fragment BookFragment on Book {
    id
    title
    author
    liked
  }
`;

const editBook = id => ({
  type: 'EDIT_BOOK',
  request: {
    query: gql`
      query($id: ID!) {
        book(id: $id) {
          ...BookFragment
        }
      }
      ${bookFragment}
    `,
    variables: { id },
  },
  meta: {
    mutations: {

    },
  },
});

Mutations

Mutations are done like queries, just use GraphQL language:

const deleteBook = id => ({
  type: 'DELETE_BOOK',
  request: {
    query: gql`
      mutation($id: ID!) {
        deleteBook(id: $id) {
          id
        }
      }
    `,
    variables: { id },
  },

});

File uploads

Upload files according to GraphQL multipart request specification, which is also used by other GraphQL clients and servers, like Apollo, is also supported.

So, to upload a single file:

const uploadFile = file => ({
  type: 'UPLOAD_FILE',
  request: {
    query: gql`
      mutation($file: Upload!) {
        singleUpload(file: $file) {
          filename
          mimetype
          encoding
        }
      }
    `,
    variables: { file },
  },
});

... or, to upload multiple files:

const uploadFiles = files => ({
  type: 'UPLOAD_FILES',
  request: {
    query: gql`
      mutation($files: [Upload!]!) {
        multipleUpload(files: $files) {
          filename
          mimetype
          encoding
        }
      }
    `,
    variables: { files },
  },
});

So, you can do it exactly in the same way like other libraries supporting GraphQL multipart request specification.

Normalisation with GraphQL

const deleteBook = id => ({
  type: 'DELETE_BOOK',
  request: {
    query: gql`
      mutation($id: ID!) {
        deleteBook(id: $id) {
          id
        }
      }
    `,
    variables: { id },
  },
});

Taming network with redux-requests, part 4 - Automatic normalisation

Konrad Lisiczyński — Wed, 22 Jul 2020 14:14:36 +0000

In the previous part of this series we discussed the problem of race conditions and how requests aborts can prevent them.

In this part we will cover the normalisation concept and how it could be automated with redux-requests.

What is normalisation?

Normalisation is a way to store data in such a way, that information are not duplicated. So, in case of edition, you need to update them only in one place, which doesn't require any synchronisation. For instance this is the way commonly used in SQL databases like PostgreSQL.

The opposite concept is denormalisation, which stores data in a way already convenient to consume, which could improve reading performance, at the cost of information duplication. It is commonly used in noSQL databases like Mongo or Cassandra.

Normalisation in Redux

Normalisation is not only relevant to databases. It can be used in any data context, including stores in Redux apps. But why would we do that? Imagine you have many API endpoints, like /books, /favourite-books, /books/{id}, /author/{id}/books and so on. Now, imagine you use those endpoints at the same time and they contain books with the same ids. What would you do to update a book title? You would need to update it in all relevant places, which would be time-consuming and error-prone. This is because of mentioned duplicated information when data is denormalized.

So what could we do? Well, we could normalize your data! How? The most common way in Redux world is to use normalizr, to normalize data before saving in reducer and denormalizing it back inside selectors. The problem is, that this has to be done manually. What if there is another way, an automated way? It turns out that there are already ways to have your data normalized automatically. In GraphQL world, projects like Apollo client or Relay support automatic normalisation, utilizing static typings of queries and mutations. But what about REST and other ways to communicate with servers? Why only GraphQL developers should have this luxury? Well, not anymore!

Automatic normalisation in `redux-requests`

If it is possible for GraphQL, why not for other ways to communicate with servers? We don't have static types for REST, but why not to utilize dynamic types? When you fetch something for the first time from a REST endpoint, you can remember the structure and compute types yourself! This is approach used in redux-requests and actually the outcome is identical to apollo or relay.

Now, imagine with have two queries:

const fetchBooks = () => ({
  type: FETCH_BOOKS,
  request: { url: '/books' },
  meta: { normalize: true },
});

const fetchBook = id => ({
  type: FETCH_BOOK,
  request: { url: `/books/${id}` },
  meta: { normalize: true },
})

and getQuery returns the following data:

import { getQuery } from '@redux-requests/core';

const booksQuery = getQuery(state, { type: 'FETCH_BOOKS' });
// booksQuery.data is [{ id: '1', title: 'title 1'}, { id: '2', title: 'title 2'}]

const bookDetailQuery = getQuery(state, { type: 'FETCH_BOOK' });
// bookDetailQuery.data is { id: '1', title: 'title 1'}

Now, imagine you have a mutation to update a book title. Normally you would need to do something like that:

const updateBookTitle = (id, newTitle) => ({
  type: UPDATE_BOOK_TITLE,
  request: { url: `books/${id}`, method: 'PATCH', data: { newTitle } },
  meta: {
    mutations: {
      FETCH_BOOKS: (data, mutationData) => data.map(v => v.id === id ? mutationData : v),
      FETCH_BOOK: (data, mutationData) => data.id === id ? mutationData : data,
    },
  },
})

assuming mutationData is equal to the book with updated title.

Now, because we have queries normalized, we can also use normalization in mutation:

const updateBookTitle = (id, newTitle) => ({
  type: 'UPDATE_BOOK_TITLE',
  request: { url: `books/${id}`, method: 'PATCH', data: { newTitle } },
  meta: { normalize: true },
})

No manual mutations! How does it work? By default all objects with id key are organized by their ids. Now, if you use normalize: true, any object with key id will be normalized, which simply means stored by id. If there is already a matching object with the same id, new one will be deeply merged with the one already in state. So, if only server response data from UPDATE_BOOK_TITLE is { id: '1', title: 'new title' }, this library will automatically figure it out to update title for object with id: '1'.

It also works with nested objects with ids, no matter how deep. If an object with id has other objects with ids, then those will be normalized separately and parent object will have just reference to those nested objects.

Required conditions

In GraphQL world, automatic normalisation in Apollo and Relay just works due to enforced static types. In order to make automatic normalisation work for REST for example, the following conditions must be meet:

you must have a standardized way to identify your objects, usually this is just id key
ids must be unique across the whole app, not only across object types, if not, you will need to append something to them, the same has to be done in GraphQL world, usually adding _typename
objects with the same ids should have consistent structure, if an object like book in one query has title key, it should be title in others, not name out of a sudden

Two functions which can be passed to handleRequest can help to meet those requirements, shouldObjectBeNormalized and getNormalisationObjectKey.

shouldObjectBeNormalized can help you with 1st point, if for instance you identify objects differently, for instance by _id key, then you can pass shouldObjectBeNormalized: obj => obj._id !== undefined to handleRequest.

getNormalisationObjectKey allows you to pass 2nd requirement. For example, if your ids are unique, but not across the whole app, but within object types, you could use
getNormalisationObjectKey: obj => obj.id + obj.type or something similar. If that is not possible, then you could just compute a suffix yourself, for example:

const getType = obj => {
  if (obj.bookTitle) {
    return 'book';
  }

  if (obj.surname) {
    return 'user';
  }

  throw 'we support only book and user object';
}

{
  getNormalisationObjectKey: obj => obj.id + getType(obj),
}

Point 3 should always be met, if not, your really should ask your backend developers to keep things standardized and consistent. As a last resort, you can amend response with meta.getData.

Normalisation of arrays

Unfortunately it does not mean you will never use meta.mutations. Some updates still need to be done manually like usually, namely adding and removing items from array. Why? Imagine REMOVE_BOOK mutation. This book could be present in many queries, library cannot know from which query
you would like to remove it. The same applies for ADD_BOOK, library cannot know to which query a book should be added, or even as which array index. The same thing for action like SORT_BOOKS. This problem affects only top level arrays though. For instance, if you have a book with some id and another key like likedByUsers, then if you return new book with updated list in likedByUsers, this will work again automatically.

Should we normalize all data?

Of course it doesn't mean we should normalize all data, this just depends. For example, if you have some objects which will be never be updated, them normalisation won't give you anything so so perhaps it would be better to keep them denormalized.

What next?

In the next tutorial we will cover GraphQL usage together with redux-requests. We will also check how normalisation works for GraphQL too and you will see that indeed it used just like in apollo.

DEV Community: Konrad Lisiczyński

Automatic Rollback Data in Optimistic Updates: A surprising benefit of Normalized Data

The Traditional Approach

Enter normalized data

The Benefits

How Does It Work?

Conclusion

React suspense from a practical point of view

What React suspense is?

Using suspense in any context

Suspense based server side rendering

Typescript benefits without... using Typescript!

Main reason to switch to Typescript

useQuery type

Data Generic

Generics type inference

Killing bad parts of Redux. Say goodbye to boilerplate.

Not necessarily verbose parts in Redux

Separate actions and reducers

Switch statements in reducers

Truly verbose parts in Redux

Constants

Avoiding manual toString calls in reducers

Thunks

Other problems

Introducing redux-smart-actions library

Taming network with redux-requests, part 10 - Server side rendering and the future

What is server side rendering?

Prerequisites

Basic setup

How does it work?

What's next?

Taming network with redux-requests, part 9 - External libraries and promises

External API libraries

Using promise driver

What's next?

Taming network with redux-requests, part 8 - Mocking and multiple drivers

What is mocking and when it is useful?

Using mock driver

Using multiple drivers

What's next?

Taming network with redux-requests, part 7 - Caching

What is caching?

When to cache?

Caching with redux-requests

Cache with cacheKey

Cache with requestKey

cacheKey and requestKey together

Cache with requestCapacity

Manual cache clearing

What's next?

Taming network with redux-requests, part 6 - Optimistic updates

What are optimistic updates?

Optimistic update example

Error handling

Updating data after server response

What's next?

Taming network with redux-requests, part 5 - GraphQL

Redux and GraphQL combination

Setup of GraphQL driver

Basic usage of GraphQL driver

Passing variables

Using GraphQL fragments

Mutations

File uploads

Normalisation with GraphQL

What's next?

Taming network with redux-requests, part 5 - GraphQL

Redux and GraphQL combination

Setup of GraphQL driver

Basic usage of GraphQL driver

Passing variables

Using GraphQL fragments

Mutations

File uploads

Normalisation with GraphQL

Taming network with redux-requests, part 4 - Automatic normalisation

What is normalisation?

Normalisation in Redux

Automatic normalisation in redux-requests

`useQuery` type

`Data` Generic

Avoiding manual `toString` calls in reducers

Introducing `redux-smart-actions` library

Using `promise` driver

Using `mock` driver

Caching with `redux-requests`

Cache with `cacheKey`

Cache with `requestKey`

`cacheKey` and `requestKey` together

Cache with `requestCapacity`

Automatic normalisation in `redux-requests`