Vector vs Keyword Search: Why You Should Care
Search has been around for a while, to the point that it is now considered a standard requirement in many ...
Senior Machine Learning Engineer
Search has been around for a while, to the point that it is now considered a standard requirement in many ...
Senior Machine Learning Engineer
It’s no secret that B2B (business-to-business) transactions have largely migrated online. According to Gartner, by 2025, 80 ...
Sr. SEO Web Digital Marketing Manager
Twice a year, B2B Online brings together industry leaders to discuss the trends affecting the B2B ecommerce industry. At the ...
Director of Product Marketing & Strategy
This is Part 2 of a series that dives into the transformational journey made by digital merchandising to drive positive ...
Benoit Reulier &
Reshma Iyer
Get ready for the ride: online shopping is about to be completely upended by AI. Over the past few years ...
Director, User Experience & UI Platform
Remember life before online shopping? When you had to actually leave the house for a brick-and-mortar store to ...
Search and Discovery writer
If you imagine pushing a virtual shopping cart down the aisles of an online store, or browsing items in an ...
Sr. SEO Web Digital Marketing Manager
Remember the world before the convenience of online commerce? Before the pandemic, before the proliferation of ecommerce sites, when the ...
Search and Discovery writer
Artificial intelligence (AI) is no longer just the stuff of scary futuristic movies; it’s recently burst into the headlines ...
Search and Discovery writer
Imagine you are the CTO of a company that has just undergone a massive decade long digital transformation. You’ve ...
CTO @Algolia
Did you know that the tiny search bar at the top of many ecommerce sites can offer an outsized return ...
Director, Digital Marketing
Artificial intelligence (AI) has quickly moved from hot topic to everyday life. Now, ecommerce businesses are beginning to clearly see ...
VP of Product
We couldn’t be more excited to announce the availability of our breakthrough product, Algolia NeuralSearch. The world has stepped ...
Chief Executive Officer and Board Member at Algolia
The ecommerce industry has experienced steady and reliable growth over the last 20 years (albeit interrupted briefly by a global ...
CTO @Algolia
As an ecommerce professional, you know the importance of providing a five-star search experience on your site or in ...
Sr. SEO Web Digital Marketing Manager
Hashing. Yep, you read that right. Not hashtags. Not golden, crisp-on-the-outside, melty-on-the-inside hash browns ...
Search and Discovery writer
We’re just back from ECIR23, the leading European conference around Information Retrieval systems, which ran its 45th edition in ...
Senior ML Engineer
Your grandfather wears those comfy slipper-y shoes all day, every day, and they’re starting to get holes in ...
Sr. SEO Web Digital Marketing Manager
Jul 12th 2016 engineering
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:
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.
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.
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.
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.
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:
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>;
}
}
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!
Powered by Algolia Recommend