Search by Algolia
Easily integrate Algolia into native apps with FlutterFlow
engineering

Easily integrate Algolia into native apps with FlutterFlow

Algolia's advanced search capabilities pair seamlessly with iOS or Android Apps when using FlutterFlow. App development and search design ...

Chuck Meyer

Sr. Developer Relations Engineer

Algolia's search propels 1,000s of retailers to Black Friday success
e-commerce

Algolia's search propels 1,000s of retailers to Black Friday success

In the midst of the Black Friday shopping frenzy, Algolia soared to new heights, setting new records and delivering an ...

Bernadette Nixon

Chief Executive Officer and Board Member at Algolia

Generative AI’s impact on the ecommerce industry
ai

Generative AI’s impact on the ecommerce industry

When was your last online shopping trip, and how did it go? For consumers, it’s becoming arguably tougher to ...

Vincent Caruana

Senior Digital Marketing Manager, SEO

What’s the average ecommerce conversion rate and how does yours compare?
e-commerce

What’s the average ecommerce conversion rate and how does yours compare?

Have you put your blood, sweat, and tears into perfecting your online store, only to see your conversion rates stuck ...

Vincent Caruana

Senior Digital Marketing Manager, SEO

What are AI chatbots, how do they work, and how have they impacted ecommerce?
ai

What are AI chatbots, how do they work, and how have they impacted ecommerce?

“Hello, how can I help you today?”  This has to be the most tired, but nevertheless tried-and-true ...

Catherine Dee

Search and Discovery writer

Algolia named a leader in IDC MarketScape
algolia

Algolia named a leader in IDC MarketScape

We are proud to announce that Algolia was named a leader in the IDC Marketscape in the Worldwide General-Purpose ...

John Stewart

VP Corporate Marketing

Mastering the channel shift: How leading distributors provide excellent online buying experiences
e-commerce

Mastering the channel shift: How leading distributors provide excellent online buying experiences

Twice a year, B2B Online brings together America’s leading manufacturers and distributors to uncover learnings and industry trends. This ...

Jack Moberger

Director, Sales Enablement & B2B Practice Leader

Large language models (LLMs) vs generative AI: what’s the difference?
ai

Large language models (LLMs) vs generative AI: what’s the difference?

Generative AI and large language models (LLMs). These two cutting-edge AI technologies sound like totally different, incomparable things. One ...

Catherine Dee

Search and Discovery writer

What is generative AI and how does it work?
ai

What is generative AI and how does it work?

ChatGPT, Bing, Bard, YouChat, DALL-E, Jasper…chances are good you’re leveraging some version of generative artificial intelligence on ...

Catherine Dee

Search and Discovery writer

Feature Spotlight: Query Suggestions
product

Feature Spotlight: Query Suggestions

Your users are spoiled. They’re used to Google’s refined and convenient search interface, so they have high expectations ...

Jaden Baptista

Technical Writer

What does it take to build and train a large language model? An introduction
ai

What does it take to build and train a large language model? An introduction

Imagine if, as your final exam for a computer science class, you had to create a real-world large language ...

Vincent Caruana

Sr. SEO Web Digital Marketing Manager

The pros and cons of AI language models
ai

The pros and cons of AI language models

What do you think of the OpenAI ChatGPT app and AI language models? There’s lots going on: GPT-3 ...

Catherine Dee

Search and Discovery writer

How AI is transforming merchandising from reactive to proactive
e-commerce

How AI is transforming merchandising from reactive to proactive

In the fast-paced and dynamic realm of digital merchandising, being reactive to customer trends has been the norm. In ...

Lorna Rivera

Staff User Researcher

Top examples of some of the best large language models out there
ai

Top examples of some of the best large language models out there

You’re at a dinner party when the conversation takes a computer-science-y turn. Have you tried ChatGPT? What ...

Vincent Caruana

Sr. SEO Web Digital Marketing Manager

What are large language models?
ai

What are large language models?

It’s the era of Big Data, and super-sized language models are the latest stars. When it comes to ...

Catherine Dee

Search and Discovery writer

Mobile search done right: Common pitfalls and best practices
ux

Mobile search done right: Common pitfalls and best practices

Did you know that 86% of the global population uses a smartphone? The 7 billion devices connected to the Internet ...

Alexandre Collin

Staff SME Business & Optimization - UI/UX

Cloud Native meetup: Observability & Sustainability
engineering

Cloud Native meetup: Observability & Sustainability

The Cloud Native Foundation is known for being the organization behind Kubernetes and many other Cloud Native tools. To foster ...

Tim Carry

Algolia DocSearch is now free for all docs sites
product

Algolia DocSearch is now free for all docs sites

TL;DR Revamp your technical documentation search experience with DocSearch! Previously only available to open-source projects, we're excited ...

Shane Afsar

Senior Engineering Manager

Looking for something?

facebookfacebooklinkedinlinkedintwittertwittermailmail

At Algolia, we do a lot of front-end JavaScript, because for us UX and UI are key components of a great search – we want the search experience to be perfect across the entire stack.

Recently, we’ve been playing quite a lot with React in our projects, especially in Instantsearch.js, an open source library for building complex search UI widgets. So far our experience has been very positive; it was so good that we eventually decided to introduce React onto our dashboard, along with Redux to handle shared state across components.

We’re really happy with the benefits that both have brought to our stack; in particular, we found that Redux brought quite a few cool things to the table:

  • Testability: Because view components essentially hold no logic, it is very easy to test them – just provide them with data and spy functions, and check that it renders the way you want;
  • Simplicity: We noticed that using Redux led us to write very clean and elegant code: no obscure features or leaky abstractions means that we always know what’s going on and virtually never run into cryptic, framework specific errors like some of AngularJS’s errors;
  • Developer experience: There are great developers tools (i.e. check out Redux Devtools, it’s awesome!) out there which allows you to easily inspect Actions and State mutations; on top of that you can also rely on very cool features such as hot reload and, even better, time travel: fixing bugs it’s just a matter of rewinding / forwarding a set of actions, find the state change which caused the error, fix it and finally replay the actions.

If you are not familiar with React or Redux as yet, there are many great resources available online for both.

React and Redux give you great powers, but also great responsibilities ! You are free to handle many things exactly the way you want. However, to really harness their combined potential, we’ve found that setting up and enforcing conventions is crucial.

Organising your single page application

We’re using the following fractal directory structure. Each page is an almost self contained app, asynchronously loading its own subpages.

- routes
 - page1
   - actions
   - components
   - containers
   - routes
     - subpage1
       ...

There’s nothing particularly controversial here, with the exception of one convention we’ve chosen to impose: To collocate Redux action creators and reducers in the same files, following the Ducks proposal. Our “actions” files look something like this:

export default function reducer(state, action) { ... };
export function actionCreator1() { ... }
export function actionCreator2() { ... }

This allows us to use default imports for the purpose of creating the combined reducer when creating the store, while still being able to used named imports in containers to import just the actions that are needed.

Reducing boilerplate in …reducers

We found that whenever we were writing reducers and action creators, we were often writing duplicate action creators and reducers, doing little more than updating a subset of the reducer’s state, for instance:

const initialState = {value: false};

export default function reducer(state = initialState, action) {
  switch(action.type) {
    case TOGGLE_VALUE:
      return {...state, value: payload};
      break;
   
  }
};

export function toggleValue(value) {
  return {type: TOGGLE_VALUE, payload: value};
}

Strictly speaking, action creators are not required since components can directly dispatch actions by themselves. However, we found that working with the more abstract action creators, allowed us to write more modular components, which would literally need no knowledge of how the reducers work or which action types are used. Instead, we simply need to pass them data and (wrapped) action creators.

Therefore, we looked into how we could simplify the reducer side of things, instead of the action creators. After a few iterations, we ended up with redux-updeep, a strongly opinionated createReducer implementation which assumes that the majority of the actions will result in deep updates of the reducer’s state. It allowed us to write the following code:

const initialState = {value: false};
const namespace = 'REDUCER_NAME';

export default function createReducer(namespace, initialState);
// That's all you need !

export function toggleValue(value) {
  return {type: `${NAMESPACE}/TOGGLE`, payload: {value}};
}

How does it work ? As mentioned before, it handles all unspecified action types in the same way, using updeep to immutably merge the action’s payload into the reducer’s current state. While it is still possible to explicitly specify action types and reducers, we still haven’t felt the need to do so!

Granted, when using redux-updeep, it becomes more complicated to compose reducers, which is idiomatic Redux. However, we’ve made it such that it is very easy to write factories that allow us to parameterize the action type’s namespaces as well as the path at which the update is merged:

export function createToggleValue(namespace, path = []) {
  return {
    toggleValue(value) {
      return {
        type: `${namespace}/TOGGLE`,
        payload: {value},
        path
      };
    }
  };
}

Then, it becomes possible to use the initial action creator deeper into a reducer state:

const initialState = {
  my: {
    deep: {
      value: false
    }
  }
}

const toggleValue = createToggleValue('OTHER_REDUCER', ['my', 'deep']);

export function toggleDeepValue(value) {
  return toggleValue(value);
}

We’re pretty happy with our current set up, so we thought that we would share it with the world. In fact, we’ve just open sourced it ! Find it on GitHub.

Handling asynchronous actions – and reducing more boilerplate

Using thunks ?

By default, Redux does not care how you handle asynchronous actions. The redux-thunk middleware is available but enforces no rules: it simply enables you to dispatch multiple actions from a single action creator. Using it, you can for instance easily dispatch loading/success/error actions in response to a Promise:

const initialState = {
  data: {},
  isPending: false,
  isError: false
};

export default createReducer('REDUCER_NAME', initialState);

export default loadData() {
  return (dispatch) => {
    dispatch({
      type: 'REDUCER_NAME/LOADING',
      payload: {isPending: true, isError: false}
    });

    get('/data').then(
      (data) => dispatch({
        type: 'REDUCER_NAME/SUCCESS',
        payload: {data, isPending: false}
      }),
      (err) => dispatch({
        type: 'REDUCER_NAME/ERROR',
        payload: {isPending: false, isError: true}
      });
    );
  }
}

This is a great start, but the code still relies on a lot of boilerplate. If you have as many simultaneous asynchronous actions as we do, and want to handle them all in the same way (e.g. how to keep track of the pending state, how to handle errors), it rapidly becomes a tedious task.

Less boilerplate, more magic!

There is a lot of middlewares in the Redux ecosystem designed to handle asynchronous actions and/or promises, but we couldn’t find one that would handle a few conventions that we had initially defined for handling asynchronous actions and asynchronous data in the components:

  • Reducer states can have several keys that will ultimately be assigned a value (let’s call those “eventual values”);
  • We want to be able to enquire whether a particular value is ready or not, without resorting to isXXX boolean flags;
  • We wanted to be able to dispatch eventual values like normal values in action creators.

So we decided to create one, the redux-magic-async-middleware, and we’ve just open sourced it! It is optimised to work with redux-updeep, and enables dispatching promises in payloads like synchronous values:

export function loadData() {
  return {
    type: 'REDUCER_NAME',
    payload: {
      value: get('/data')
    }
  }
}

The middleware will automatically extract the promises from the payload, and replaces them with eventual values. When a promise is resolved, it will trigger a success action which will update the resolved data into the reducer states, thus resolving the eventual value.

In combination with this, we have created the eventual-values library, very much inspired by another eventual values library. This library is extremely simple, but allows us to encapsulate and abstract the behaviour that we desired around asynchronous values. It allows to you write code like this:

function isReady(value) { ... };

function MyComponent({reducerState}) {
  if (isReady(reducerState.data)) {
    return <h1>Loading</h1>;
  } else {
    return <span>data.name</span>;
  }
}

What’s next ?

We’re still experimenting with those concepts and tools, and are gradually introducing flow typing in our codebase. Watch this space for more updates on how we use React, Redux and JavaScript in general!

About the author
Alexandre Meunier

Recommended Articles

Powered byAlgolia Algolia Recommend

Introducing our new navigation
product

Craig Williams

Director of Product Design & Research

Good API Documentation Is Not About Choosing the Right Tool
engineering

Maxime Locqueville

DX Engineering Manager

Building a Store Locator in React using Algolia, Mapbox, and Twilio – Part 3
engineering

Clément Sauvage

Software Engineer, Freelance