I am glad that you find this article useful! I suppose that you are asking me about the prevention of endless looping.

The code from the provided repo will surely loop to eternity if the REQUEST action fails every time. The solution here could be adding a retry counter to the action. Such information would allow the monitor saga to abandon the action after the configured number of attempts.

If you look at the Flux Standard Action (https://github.com/redux-utilities/flux-standard-action), it says the best place to put such data is in the meta property of the action.

You could extend the functionality of the monitor saga to increment the counter every time it encounters a failed action.

Example:

starting to monitor action:
{ type: ‘FOO_REQUEST’, payload: { … } }

action failed, refresh the token and dispatch it again:
{ type: ‘FOO_REQUEST’, payload: { … }, meta: { retry: 1 } }

…

action failed again, retry counter is > 3, ignore the action…

I hope this is understandable. Cheers!

A common mistake when writing business logic in web apps is code duplication. If a component needs to fetch user data the first thing that comes to mind is fetching it in the componentDidMount hook. The problem with that is repeating the code in every component that needs the same data.

What if the logic for data fetching is written only once, and just invoked when needed?

Redux saga

Imagine separate threads that can listen to dispatched actions, and react to them by executing some logic and dispatching other actions. That is technically not accurate but good enough to get an initial idea.

For those that want to thoroughly understand redux-saga, be advised to see the official documentation.

It is a Redux middleware that executes sagas (for now think of them as plain functions) based on dispatched actions. There are some similarities to Redux reducers although they are very different things.

• there is a root saga (remember root reducer?)
• they can read and change state (indirectly)
• they can be combined and reused

Why saga?

The name redux-saga comes from the concept of long-running transactions that are modeled and known by the saga design pattern name. The pattern attempts to resolve the problem of complex interactions between different services.

For example, when the user is requesting a particular resource from a server the request needs to be authenticated. The process of authentication can be modeled as a saga.

Web applications often have many processes that could benefit from this design pattern such as multi-stage data fetching, interpreting complex user interactions and monitoring the user or application state.

Generators

In redux-saga, sagas are implemented with the help of generator functions. They are a part of the ES6 standard and are supported by all major browsers besides IE. With the help from Babel, generators can be used in IE and older browsers too.

A generator cannot be used directly as it needs to be instanced before. After the instantiation, it is executed by calling the next() function. When the generator is finished it will return the done flag.

function* generator() {
  yield 1
  yield 2
  yield 3
}

const gen = generator()

gen.next()
// { value: 1 }

gen.next()
// { value: 2 }

gen.next()
// { value: 3, done: true }

The generator code should be straightforward except the yield keyword. It is very similar to the return keyword as it returns the value. The difference is that when the next() function is called again, execution will continue from the last yield statement.

Here is a generator that outputs numbers from the Fibonacci sequence.

function* fibGenerator(limit) {
  let current = 0
  let next = 1
  let temp

  for (let i = 0; i < limit; i++) {
    temp = current
    current = next
    next = temp + next
    yield current
  }
}

const fib = fibGenerator(3)

fib.next()
// { value: 1 }

fib.next()
// { value: 1 }

fib.next()
// { value: 2, done: true }

For an in-depth introduction to generators, I suggest starting with this MDN web doc.

Authentication Monitor

Every web application needs to fetch its data from a server that may or may not be protected from public access. The most common way of authentication today is the usage of JSON web tokens or JWT.

A client needs to include the server-issued JWT in the header of every request that queries non-public data. When the JWT is expired or not valid the server will return the 401 status code.

Authentication failure can be handled in many different ways and often the best approach is to refresh the token and try again. That process can be isolated and solved with sagas.

For the example to be simple and understandable there should be some rules for the Redux logic.

Assumptions

1. Every interaction with the server is implemented as a three action process consisting of these states: REQUEST, SUCCESS, FAILURE.
2. Failures should contain the error as a payload of the action.
3. There should be a mechanism to prevent monitoring of some actions.

Implementation

For those who want to see the finished code, it is available in this repo.

stjepangolemac/monitor-saga

Here’s a step by step explanation of the code.

Actions that do not trigger new requests should not be monitored and they could be identified by the lack of the REQUEST suffix. Some actions should not be monitored for a range of different reasons so it is essential to recognize them too. The easiest way is to put them in a list.

const ignoreActionTypes = ['TOKEN_REFRESH']

function monitorableAction(action) {
  return action.type
    .includes('REQUEST') && ignoreActionTypes
      .every(fragment => !action.type.includes(fragment))
}

A couple of helper functions will prevent code duplication and make the code more readable and understandable. An action is identified by stripping the state suffix from the action type. For example, GET_PROFILE_REQUEST is actually a GET_PROFILE action with REQUEST state.

function identifyAction(action) {
  return action.type.split('_').slice(0, -1).join('_')
}
function getSuccessType(action) {
  return `${identifyAction(action)}_SUCCESS`
}
function getFailType(action) {
  return `${identifyAction(action)}_FAILURE`
}

For an easier understanding, let see how the monitor is fired before it’s implementation.

export default function*() {
  yield takeEvery(monitorableAction, monitor)
}

If an action needs to be monitored the monitor will be spawned, otherwise nothing will happen. After the action is classified as monitorable the saga waits for a SUCCESS or FAILURE action.

function* monitor(monitoredAction) {
  console.log('started monitoring', monitoredAction.type)
  const { fail } = yield race({
    success: take(getSuccessType(monitoredAction)),
    fail: take(getFailType(monitoredAction)),
  })

  ...

There is no need to do anything if the process succeeds so there is only a check for a failure which is a result of an invalid token.

...

if (fail && fail.payload && fail.payload.code === 401) {
  console.log('detected 401, refreshing token')
  yield put(userTokenRefreshRequest())

  const { success } = yield race({
    success: take(userTokenRefreshSuccess().type),
    fail: take(userTokenRefreshFailure().type),
  })

  if (success) {
    console.log('token refreshed, retrying', monitoredAction.type)
    yield put(monitoredAction)
  } else {
    console.log('token refresh failed, logging out user')
    yield put(userLogoutRequest())
  }
}

...

Token refresh is monitored too because the token could be corrupted or altered by a malicious code. In that case, there is nothing else to do but to log out the user and handle the problem somewhere else.

After successful token refresh, the failed action should be retried.

  ...

  console.log('monitoring', monitoredAction.type, 'finished')
}

When the action is retried the monitor returns and finishes it’s task although it will again be monitored by a new monitor. This could potentially create an endless loop but there is a solution for that too.

Improvements

This implementation of the monitor is already able to handle most of the cases in a web application, but there are some ways to make it even better.

1. timeouts for waiting on SUCCESS and FAILURE actions
2. retry limits
3. plug & play reusability in different projects
4. additional suggestions from the responses (maybe?)

Summary

Web applications are slowly but surely getting more complex because users expect more. At the same time, product owners expect more for less time so it is essential to write smart and flexible code.

Sagas are a powerful tool that allows the developer to deliver that complex logic but make it very maintainable at the same time.

As said before, the code is available in this repo.

Let me know if you like this story below in the responses and make sure other people see it by clicking on them 👏.

Learn more

• How to write better code in React
• 11 Javascript utility libraries you should know
• Building a UI component library

One last thing

Bit’s component platform turns all the components and modules in your applications into an API you can use to build new things. Give it a try.

Bit - Share and build with code components

Complex App Logic With Redux And Redux Saga: Write an Authentication Monitor was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.

The problem

The world of frontend development is getting more complicated by the hour. There are new frameworks, tools, techniques, and user requirements every time I decide to read some news and tweets to catch up.

Finding a direction in that kind of quick and always changing environment is difficult. One way of finding a stable ground is organizing the code by some standard or a design system.

Atomic Design

It is a system that recognizes hierarchy, importance, type, and role of each and every component. The components are combined in a way that resembles the structure of our universe.

• atoms
• molecules
• organisms
• templates
• pages

Why

The need for some kind of a design system appears when we start to get overwhelmed by the count of components on a project. In projects where there are a hundred or two hundred components, it is not easy to remember everything.

Origin

The mind behind this system is Brad Frost, and for those of you who want to learn more about it feel free to stop right here and first read his in-depth post on the subject. There is even a book.

Atomic Design

Example UI

In my quest for the perfect UI to recreate, I could not find anything that satisfied me completely. This is the closest I could find.

I will not try to pixel perfect it nor achieve the exact same layout. The goal here is to showcase the separation of components.

Breakdown

I do not consider this a deterministic process. I am certain there are better ways to decouple this UI into components but the essence is the same, make them more manageable. I will use the top-down approach.

• one page - dashboard
• two templates - header and workspace
• many organisms - tools, time, map,…
• even more molecules - tool buttons, temperature info, feed items,…
• probably even more atoms - labels, icons, links, headings,…

Cataloging

Making every component decoupled and available in an online catalog will make it easier for future developers to find and use them.

Bit

A component-as-a-service platform that enables components to be cloud-hosted, discoverable, versioned, isolated, and easily incorporated in other projects.

Bit - Share and build with code components

It solves common problems of managing component systems and saves developers from reinventing the wheel while increasing their productivity. Below is an example of a rendered component pushed to the Bit scope. For more information watch this video.

Result

In the end, I created 15 components that can be combined to build the view from the example UI. The charts are not included because they are out of the scope of this article. Components are cataloged and available on this link. The repo that contains whole code can be found here.

atomic-design. Javascript components by stjepangolemac.

After the development, it is really easy to make your own catalog of components. You just need to sign up on the bitsrc.io, then type in a few short commands and you are done.

# Navigate to the project directory and initialize Bit
$ cd project_dir

$ bit init
$ bit login

# Add the components to the local scope
$ bit add src/components/atoms/*
  ...
$ bit add src/components/pages/*

# Check if all components are added
$ bit status

# Tag the version and upload the components to Bit
$ bit tag --all 1.0.0
$ bit export <your_username>.<your_scope>

The result can be seen on this link. That is a scope, think of it like a namespace for exported components. You can have as many scopes as you want, and you can make them private or public.

Let us see the <Panel /> component here. There is support for component documentation, testing, building, and compiling. You can even explore file structure and code.

$ bit init
$ bit import <your_username/<your_scope/avatar-image \
  --path src/components/avatar-image

You are now able to use these components in any future project by just importing the component. You do need to make sure the project that you are importing the components in supports bundling of resources used. For example, components from the link above import .css files.

You should definitely explore features that Bit offers like component rendering, testing, and documenting. The best place to start is the official documentation.

Summary

Bit is a refreshing new tool that makes it easier to manage modular and reusable components in a standardized way. Developers should focus on the project requirements and quality code delivery, they should not worry about the usage of their components in other projects or by other people.

Give Bit a try and if you have any problems feel free to ask for help on Gitter channel or send an email to team@bitsrc.io.

One last thing…

Let me know if you like this story below in the responses and make sure other people see it by clicking on the 👏.

Learn more

• 11 React UI Component Libraries You Should Know In 2018
• How To Write Better Code In React
• 11 Javascript Utility Libraries You Should Know In 2018

Atomic Design With React And Bit: Simplify a Complex UI was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.

There were attempts to handle the ui state in a ‘ui’ reducer in Redux but it had it’s flaws. Namespacing the states in that reducer increased the boilerplate code both in components and redux logic.

Descriptive and versatile checklist with must do’s and should do’s when conceptualizing sleek and professional React code

Going through the process of learning and using React and Redux I came to a following conclusion - they are not hard to grasp but are fairly difficult to master. Both are pretty minimal when it comes to their API and that helps new users to churn out new components and even apps at an incredible pace. Nevertheless, that convenience degrades the average quality of React code.

Being the minimally opinionated library as it is, React allows a fair amount of maneuverability regarding the different approaches one can take. The consequence of that is the broad spectrum of available best practices for someone to apply. Some of those alleged best practices are not even good practices at all, and some of them are not compatible with one another. Best practices can depend on the tools and libraries you use, and they can be different relative to the type and purpose of the app.

The greatest difficulty I had and still have when searching for some additional valid knowledge is the lack of high quality and up-to-date materials. My goal here is to compile and organise in one place as many methods, concepts, and practices as my laziness allows.

Pillars of creation

High-quality React code rests on 5 pillars. It is not by chance a pillar and not a column, pole or a shaft. Pillar is defined as a slender, freestanding, vertical support (“Pillar.” The American Heritage® Dictionary of the English Language. Wordnik.com).

The code should be made as simple as possible, but not simpler. And it should document itself. And it should be fast. And that is it.

There are 5 core principles (or pillars) of React components and they are:

1. Modularity
2. Reusability
3. Brevity
4. Flexibility
5. Efficiency

For every important thing that influences the usage of a best practice, there will be a ⻧ character (I do not know the origin nor the meaning of it, it just reminds me of a checkbox hanging on a sign). Afterwards, important concepts will be summarised along with the available ways to respect them.

Modularity

A proper way to write modular and composable Javascript code is to follow the principles of functional programming (⻧). A brief suggestion is to write functions wherever and whenever possible. More complex algorithms and processing should be handled with higher order functions (⻧) which take other functions as parameters or return them. That way the duplication of code is minimum and the organisation is maximum. Take a look at one helper function in the inferno-shared package from InfernoJS team:

export function isNullOrUndef(o) {
  return isUndefined(o) || isNull(o)
}

The function is composed of two functions that could again be composed of more functions. This prevents redundancy and visual complexity.

Reusability

As it is with every piece of code that is ever written, the shape of the implemented functionality must always adhere to some interchangeable format so that it can easily be replaced or reused. When it comes to React this principle can be fulfilled by grouping similar components or utility functions and extracting them to a separate git repo or npm package. A good example of this can once again be found in the work of the InfernoJS team.

inferno-compat
inferno-component
inferno-create-class
inferno-create-element
inferno-devtools
inferno-hyperscript
inferno-mobx
inferno-redux
inferno-router
inferno-server
inferno-shared
inferno-test-utils
inferno-utils
inferno-vnode-flags
inferno

Organising similar code in independent packages enables clean import paths, easier maintenance, and greater modularity. The downsides are reviewing changes and testing code which can become much more complex. Effects of those problems can be minimised by using Lerna(⻧). Be sure to check Webpack aliasing feature (⻧) for even shorter and more beautiful import paths.

Brevity

With the introduction of functional components in React 0.14 developers got the ability to write more concise and clear code (⻧). The type of component depends on the need to use component state (which is discouraged, use Redux) and lifecycle methods. Imagine a component that renders an image of a sloth. Now imagine the most verbose way to write it.

class SlothImage extends React.Component {
  render() {
    return <img src='sloth.gif' alt='Pretty face'>
  }
}

export default SlothImage

This code is completely correct and performant but can it be shorter? This component has no use of lifecycle methods.

const SlothImage = props => {
  return <img src='sloth.gif' alt='Pretty face'>
}

export default SlothImage

Two lines have been spared by converting the class component to the functional component. What if the source and alt text are externally defined?

const SlothImage = props => {
  return <img src={props.source} alt={props.alternativeText}>
}

export default SlothImage

The amount of lines is unchanged but the total number of characters is greater. Heard of JavaScript destructuring (⻧)?

const SlothImage = ({ source, alternativeText }) => {
  return <img src={source} alt={alternativeText}>
}

export default SlothImage

That is better but it is not enough. Let us rename the props to their respective <img> counterparts and export the component in the same line.

/*
The props should now be built like this:
{
  src: 'sloth.gif',
  alt: 'Pretty face',
}
*/

export default props => <img {...props}>

The dots are called a spread operator (⻧). One line is short enough but most of the real world components are not this simple. Remember, the goal is to reduce the number of characters, not newlines. My personal taste for writing more complex components is as follows:

export default ({
  separateNext: underline,
  rightComponent,
  onRightComponentClick,
  ...rest: imgProps
}) => {
  return (
    <Row
      underline
      actionComponent={rightComponent}
      onActionClick={onRightComponentClick}
    >
      <SlothImage {...imgProps} />
    </Row>
  )
}

If I could pick one rule in writing React components it would be exceeding the 80 characters mark (⻧) in a single line. When dealing with more than few properties it is always a good idea to format them one below another and to properly indent them. Using destructuring along with renaming and the rest operator (⻧) is a good way to save some keystrokes.

Flexibility

If we want the components to be reusable, they need to be able to fit in different contexts and visual environments. That implies having different shape and style dependent on the parents or surrounding children. The component that renders a text input for entering an amount of money could be used like this:

<TextInput
  wide
  required
  suffix={<DollarSign />}
>
  43
</TextInput>

The logic for achieving the correct behavior of this component is not too complex. The checks for boolean props are oneliners and rendering the suffix is a matter of injecting it in the right place. But the over need for flexibility and customisation may complicate the component to the point where it has several hundred lines of code. The sign of overcomplication is the usage of “enum” like props or having too many props.

<TextInput
  required
  width='col-6'
  height='xlarge'
  bgColor='#a4a4a4'
  type='primary'
  suffix='dollar'
>
  1337
</TextInput>

Every component should have a single responsibility (⻧) and a reasonable amount of flexibility. If the code is too complex, break it down to several components.

Efficiency

User experience greatly depends on the responsiveness and snappy interaction which must be the priority when building (progressive) web apps. One of the things that can slow down transitions and navigation is unnecessarily iterating over arrays, especially if the app contains long tables and lots of repeating elements. Let’s suppose we need to render only short strings in spans.

const arr = ['foo', 'bazzzz', 'bartender', 'qux']

const spans = arr
  .filter(entry => entry.length <= 3)
  .map(entry => <span>{entry}</span>)

This way there are two loops to do a simple rendering. A great way to get two times faster execution is to, guess once, shorten the number of loops twofold.

const spans = arr.reduce((acc, curr) => {
    return curr.length <= 3 ? [...acc, <span>{curr}</span>] : acc
},[])

The reduce method (⻧) on the Array object is very powerful since it allows processing the entries before accumulating them by some rule.

Performance can be even greatly impacted by unnecessary re-renders of complex React components. Every change in the props triggers the rendering process that can be CPU intensive for complex components. To the rescue comes shouldComponentUpdate (⻧) lifecycle hook. If the change in some prop does not need to trigger rendering it can be written like this:

class Example extends React.Component {
  ...
  shouldComponentUpdate(nextProps, nextState) {
    return nextProps.foo !== this.props.foo
  }
  ...
}

When this hook returns true the component will be re-rendered, and if it returns false it will not.

Important concepts sorted by magic (⻧)

• Functional programming
• shouldComponentUpdate
• Higher order functions
• Functional components
• Lerna
• Webpack resolve.alias
• Destructuring
• Spread operator
• Rest operator
• 80 characters
• Single responsibility
• Array.reduce

One last thing…

Let me know if you like this story below in the responses and make sure other people see it by clicking on the 👏.

Step by step guide for writing awesome React components was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

I will surely keep in mind to give you some feedback on that topic, maybe even propose something different when the time is right. Anyway, thank you for your response.

The motivation behind redux-constants-builder was indeed the boilerplate of redux API middleware constants. It is a small step towards more compact code. Builders for reducers and sagas could substantially shorten the boilerplate and I have some ideas about that too. I am still conceptualizing a way to use all these builders to make a redux module builder that could maybe fit an entire logic of a module in one file.

I did see redux-io before a couple of weeks on your Shoutem documentation and put it on my “must try” list. I am making some plans to build a relatively simple React Native app using Shoutem and redux-io, which seem really amazing. The only question I have for redux-io is how would you handle authentication?

Reducing the Redux boilerplate by domain driven modularization of store management logic.

I started using React and Redux a couple of months ago and after going through the basic concepts I immediately fell in love. It took one relatively complex app to realize how much boilerplate I needed to write. It soon became apparent that without some kind of reorganization of logic and file structure, maintenance and extension will become tiresome.

After a couple of days of researching and thinking about ways to reduce the code, I conceived a template. The biggest concern I wanted to avoid was the towering height of Redux-related folders like constants and actions and the long import paths.

DISCLAIMER: The packages which I use are not obligatory by any means and these tips can be used with virtually any selection of tools. This disclaimer is mostly related to the selectors and sagas below.

Grouping files by function

Most guides and tutorials regarding React and Redux on the web are following this folder layout:

actions/
  |-- codes.js
  |-- locations.js
  |-- partners.js
  |-- users.js
constants/
  |-- codes.js
  |-- locations.js
  |-- partners.js
  |-- users.js
reducers/
sagas/
selectors/

This folder structure is commonly known as “Rails-style” and it groups the files based on their function which is not per se a bad thing. The problem appears when you have tens of files grouped together and every action requires you to skim the list in a quest for the right file.

Making it even worse, import paths are always crossing several levels of folders which make imports fat and importing cumbersome.

Domain driven modularization

What if we could group files by their respective “departments”? For example, let’s put all users related files in one folder and point out some advantages of this approach.

users/
  |-- actions.js
  |-- constants.js
  |-- reducer.js
  |-- saga.js
  |-- selectors.js

At first glance, nothing special happened but let’s address aforementioned problems and see what is different.

• File count — folders are now easier to skim through or analyze and they are using less vertical space, which means better use of screen real estate
• Import paths — importing now takes less horizontal space because all related files are in the same folder, which means no more figuring out how many slashes or dots is enough

Depending on the size and complexity of your project, it may already seem considerably easier to maintain and extend the codebase. But, what if there were additional improvements?

Bundling the domain

Organizing the code like this allows us to define an index file that could import all those specific files, and then export them from a single point. For example, let’s take users domain and bundle it into one file.

users/
  |-- actions.js
  |-- constants.js
  |-- reducer.js
  |-- saga.js
  |-- selectors.js
  |-- index.js

Now, all remaining files need to be imported into the index file and afterwards exported.

// index.js

import * as constants from './constants'
import * as actions from './actions'
import * as selectors from './selectors'

import reducer from './reducer'
import saga from './saga'

export {
  constants,
  actions,
  selectors,
  reducer,
  saga
}

We can make this even shorter by directly exporting imported modules. The downside of this approach is losing the grouping of imports.

export * from './constants' // BAD
export { default as reducer } from './reducer' // GOOD

EDIT: Exporting and renaming the import is actually possible if you are willing to use Babel export extensions transform. Thanks to Matija Marohnić for pointing this out to me!

This way, when you need something related to the users domain, you always import from the same path. It’s not uncommon to import both action creators and selectors at the same time.

import
  actions as usersActions,
  selectors as userSelectors
} from '../../redux/users'

Composing React components

The index file can be used for all sorts of wiring and enwrapments of React components too. This is exceptionally useful if the component is connected to the part of Redux state and has constants, action creators, or requires an async action to be called. The structure is the same with the addition of the component definition.

// containers/TodoList/index.js

import { connect } from 'react-redux'

import TodoList from './todolist'

import * as constants from './constants'
import * as actions from './actions'
import * as selectors from './selectors'

import reducer from './reducer'
import saga from './saga'

const connectedTodoList = connect(
  state => {
    return {
      todos: selectors.todos(state)
    } 
  },
  dispatch => {
    return {
      getTodos: () => dispatch(actions.get.try())
    }
  }
)(TodoList)

export default connectedTodoList
export {
  constants,
  actions,
  selectors,
  reducer,
  saga
}

Conclusion

Not everyone will appreciate the granularity of control and choice available while writing React + Redux apps. However, if utilized effectively it can lead to surprisingly sleek and organized code.

I am currently experimenting with builders for Redux-related code and if I succeed in making the code short enough, putting all of this in a single, well-organized file may be a plausible action. The builder for constants can already be tested.

redux-constants-builder

Feel free to try it and leave your suggestions, comments and ideas!

I hope this article was helpful and that it would spark some new ideas about code structure in React + Redux apps. Stay tuned for my future efforts to reduce the Redux boilerplate!

One last thing…

Let me know if you liked this story down in the responses and make sure other people see it by clicking on the ❤.