DEV Community: Vlad Oganov

Small React Tip – Customisable Filter Panel Component

Vlad Oganov — Sun, 03 Jan 2021 13:53:01 +0000

We're working on an application that's basically a number of tables. Of course for making life of our customers better we wanted to add an ability to filter data in these tables.

Depending on a kind of data tables could be filtered by the date, price, name, or an id of an item in the system. Different table had different set of column, hence could have different filters.

We wanted to have a reusable and customisable solution, that holds the logic of keeping state locally, and give as an ability of adding a new type of a filter field.

We could go with a straight forward solution like the following:

function FilterPanel(props) {
  ...

  return pug`
    if props.hasDate
      FieldDate(
        value=...
        onChange=...
      )

    if props.hasAmount
      FieldAmount(
        value=...
        onChange=...
      )

    ...
  `
}

And as you can see here we just control presence of fields by flags like hasDate, hasAmount, which is not flexible in a case we want to change the order of the fields. Then we decided to separate fields and the panel.

The first step to find a better solution was to draft its interface to outline the way we want to use it. We came up with the following:

FilterPanel(
  values={}
  onApply=(() => {})
)
  FieldGroup
    FieldDate(
      name="dateMin"
    )    

    FieldDate(
      name="dateMax"
    )

  FieldGroup
    FieldAmount(
      name="amountMin"
    )    

    FieldAmount(
      name="amountMax"
    )

As you can see here we have an ability to configure the panel depending on what table we're going to use it with.

To share the logic between these fields and make it flexible in a case we want to group the fields we used React Context.

If it looks new for you, I highly recommend to read the official docs first.

We create the following folder structure for this component:

FilterPanel/
  Context/
  FieldDate/
  FieldAmount/
  FieldName/
  atoms.common.js <--- common styled components
  atoms.js
  index.js

Let's start with the Context module:

import { createContext, useContext } from 'react'

const Context = createContext({
  getValue: () => null,
  setValue: () => {},
})
Context.displayName = 'FilterPanelContext'

export const Provider = Context.Provider

export function useFilterPanelContext() {
  return useContext(Context)
}

This it our interface to work with the context instance: the Provider component and useFilterPanelContext.

The state holding went to the FilterPanel component:

function FilterPanel(props) {
  const [values, setValues] = useState(props.values)
  const [wasChanged, setWasChanged] = useState(false)

  const isApplied = !_.isEmpty(props.values)

  function getValue(name) {
    return values[name]
  }

  function setValue(name, value) {
    setWasChanged(true)
    setValues({ ...values, [name]: value })
  }

  function clearValues() {
    setWasChanged(false)
    setValues({})
    props.onApply({})
  }

  function submitValues(event) {
    event.preventDefault()
    setWasChanged(false)
    props.onApply(values)
  }

  const formLogic = {
    getValue,
    setValue,
  }

  return pug`
    form(onSubmit=submitValues)
      Provider(value=formLogic)
        Wrapper
          each child in Children.toArray(props.children)
            Box(mr=1.5)
              = child

          Box(mr=1.2)
            if isApplied && !wasChanged
              Button(
                type="button"
                variant="outlined"
                size="medium"
                onClick=clearValues
              ) Clear

            else
              Button(
                type="submit"
                variant="outlined"
                size="medium"
              ) Filter
  `
}

A code is the best documentation. And if there are some places you'd like to know more about, here is some explanations.

Why do we hold state locally? We want not to apply this filters right after they changed — only by click on the "Filter" button.

Why do we track wasChanged? We want to know if user has changed a value of a field, so we show the "Filter" button again instead of the "Clear" one.

How does Provider help us? Data that were passed as the value props are now available in all components that use the useFilterPanelContext hook.

What the purpose of Children.toArray(props.children)? It's a way to render the children and to apply some additional logic. Here we wrap each child into Box — a component that adds margin right.

And the last but not least — a field component. We will take the amount one as an example. Here it is:

function FilterPanelFieldAmount(props) {
  const { getValue, setValue } = useFilterPanelContext() <---- our hook

  const handleChange = event => setValue(event.target.name, event.target.value)
  const handleClear = () => setValue(props.name, '')

  const value = getValue(props.name)

  const Icon = pug`
    if value
      IconButton(
        variant="icon"
        size="small"
        type="button"
        onClick=handleClear
      )
        Icons.TimesCircle

    else
      IconLabel(for=props.name)
        Icons.AmountFilter
  `

  return pug`
    FieldText(
      size="medium"
      id=props.name
      name=props.name
      value=value
      placeholder=props.placeholder
      onChange=handleChange
      endAdornment=Icon
    )
  `
}

And that's it! It's a really nice practice to make something customisable via React Context. I hope it was useful, and let me know if there something I missed.

Cheers!

Add pattern matching in React using Daggy

Vlad Oganov — Wed, 19 Aug 2020 15:41:14 +0000

I’m going to talk about a great library called Daggy, which gives you the ability to add pattern matching to your Javascript code and transform the React render method.

This article is for people who are already familiar with React and have experience working with it. If you’re a newbie in React, read the article about a quick start in React, and then return to us. Have a nice read!

The problem of “if”

Let’s start with this statement: we love React 😊
React is a powerful and easy-to-use library with many advantages. And, of course, it has some trade-offs. One of them: it’s a library… so we don’t have any predeclared patterns and restrictions—a.k.a. standards and practices. In this case, we have to invent our own solutions.

One of these patterns is called conditional rendering. What does this mean? This “if” hell:

render() {
if (this.state.isLoading) {
    return ...
}

if (this.state.isError) {
    return ...
}

if (this.state.isListEmpty) {
    return ...
}

return this.state.list.map(item => ...)
}

I don’t like it… do you? I think that you’re just used to it.

OK, maybe it’s necessary to solve this problem. I think this is the case. Why? Here are some reasons:

React is based on the idea of a declarative way of defining the render function. Using ifs, we have to investigate all the imperative workflow instead of just taking a look at the JSX (or pug) code.
You have to define a lot of system helper fields in the state, like isLoading, isError, etc. And it’s complicated to reuse such solutions, even with Redux.

The Solution: javascript pattern matching

Once upon a time, I got the solution: pattern matching. There is only one problem with this solution: we don’t have one in the JS standard, and so we need to use a custom solution. I found one: Daggy.

Daggy is a library that gives you the ability to define a type and values of this type—sum types. Using pattern matching we can declare the action depending on the value of this type. Take a look at this example:

const Item = daggy.tagged('Item', ['title'])

const List = daggy.taggedSum('List', {
  Empty: [],
  Items: [Item],
})

const list = List.Empty

list.cata({
  Empty: () => console.log(‘empty…’),
  Items: items => items.map(item => console.log(item.title)),
})

If you have some functional background you may say, “Oh my Haskell!”
And it almost is 🤘

The advantages of this approach are:

You get the type security to make your code more predictable.
Ability to reuse this definition over your code.
You make your app behavior more obvious and your life easier 🙂

And a small explanation about types from my perspective.

Binding with Haskell and FP

Types make our code more expressive and readable. You define a range of values that a variable with a type as a label can be or a function can accept. It protects you from summing strings or compelling a cat to “woof”.

Another advantage is that it makes your code more descriptive:

type Password = String

This gives you a little bit of context, but I’d recommend that you take a look at Haskell to get familiar with the modern functional hype 😉

Javascript pattern matching example

Well, let’s get back to the React world and sprinkle your app with the magic of types. How can it help us make our code more readable and declarative? I think the best way to answer this question is to create a pet application with poor names and logic, but that is to the point 😀

I’d recommend using create-react-app and then yarn add daggy. You can use whatever project structure you want, and I’d recommend the following:

src
  index.js
  App.js
  App.css
  types.js

Our pet application will be a small list with fake data fetching and filtering. We’re going to start by declaring types—it’s pretty easy:

const Item = daggy.tagged('Item', ['title'])

const List = daggy.taggedSum('Page', {
  Empty: [],
  Initial: [],
  Items: [Item],
  NotFound: ['searchMessage'],
  FetchError: [],
})

A small explanation. The tagged function gives you a type-wrapper called Item with a field called “title”. The taggedSum function returns union types so that we can work with an entity depending on the state of the value.

We’ll define start data and the fake fetch function:

const LIST = [
  { title: 'Butter' },
  { title: 'Bread' },
  { title: 'Eggs' },
  { title: 'Fish' },
  { title: 'Cake :3' },
]

const petFetch = () =>
  Promise
    .resolve(LIST)
    .then(list => ({ list }))

Then we’ll focus on our component. State and render go first:

class App extends Component {
  state = {
    list: List.Initial,
    searchString: '',
  }

  render() {
    return (
      <div className="container">
        <ul>
          {this.state.list.cata({
            Empty: () => <li>This list is empty =(</li>,
            Initial: () => <li>Loading...</li>,
            Items: items => items.map(({ title }) => <li>{title}</li>),
            NotFound: seacrhMessage => <li>There is nothing on your request: ’{seacrhMessage}’</li>,
            FetchError: () => <li>Oooooops...</li>,
          })}
        </ul>
      </div>
    );
  }
}

Take a closer look at the render function. We are using the cata method to start the pattern matching and, depending on the value of the list, we’ll render a piece of JSX. Personally, I think that looks better than ifs or even switch 💩

The result is the following:

Easy peasy lemon squeezy. Eloquent UI 🙃
And now we’re ready to add other methods:

componentWillMount() {
    setTimeout(this.fetchList, 2000)
  }

  fetchList = () =>
    petFetch()
      .then(res => this.wrapList(res.list))
      .catch(() => this.setState({ list: List.FetchError }))

  wrapList = (list) => {
    const wrapperList = list.length === 0
      ? List.Empty
      : List.Items(list)

    this.setState({ list: wrapperList })
  }

Here we start fetching with a 2-second delay to show the loading method. Everything’s clear with the lifecycle method componentWillMount and fetchList, but you might have some questions about the wrapList method. Here we construct a value using type constructors, depending on the length of the list, and then set it to the state field “list”.

For the sake of good code design, I’d recommend that you separate wrapping and state changing, then create a set of functions for working with types. I’ll skip it here, to prevent creating a post with tremendous size 😜

Let’s make our life a little bit harder and add a filter for titles. First, we should upgrade our state and render method.

 state = {
     list: List.Initial,
     searchString: '', }

 render() {
     return (
       <div className="container">
         <input onChange={this.handleChange} />
         <ul>
           {this.filterList().cata({
             Empty: () => <li>This list is empty =(</li>,
             Initial: () => <li>Loading...</li>,
             Items: items => items.map(({ title }) => <li key={title}>{title}</li>),
             NotFound: seacrhMessage => <li>There is nothing on your request: {seacrhMessage}</li>,
             FetchError: () => <li>Oooooops...</li>,
           })}
         </ul>
       </div>
     );
 }

Then we need to add a method for filtering, handling the input.

filterList = () =>
    this.state.list.cata({
      Empty: () => List.Empty,
      Initial: () => List.Initial,
      Items: items => {
        const filteredList = items.filter(this.matchSearch)

        return filteredList.length > 0
          ? List.Items(filteredList)
          : List.NotFound(this.state.searchString)
      },
      NotFound: () => List.NotFound(this.state.searchString),
      FetchError: () => List.FetchError,
    })

  handleChange = ({ target }) =>
    this.setState(() => ({ searchString: target.value }))

  matchSearch = item =>
    (item.title.indexOf(this.state.searchString) !== -1)

The workflow of the filtering is pretty clear and obvious: we filter the list and the result of this action wraps into the type constructors. We get value depending on the result of filtering. Here’s what we got:

Create tagged constructors with Daggy

Here we go. First of all, I’d like to say about the library Daggy that it’s a nice and easy-to-use portal to the functional world that gives us the ability to use pattern matching and union types in JS applications. Second, please go to the official Daggy GitHub of this library and click on “Star”, so that the creators will know you find their tool useful 😎

Also, types give us a simple way to make our code readable, giving entities of our application a descriptive name and a list of fields for predictability.

I’d recommend that you get an experience in any Functional Language to be on top of the modern style of JS coding and write more maintainable applications, not through the objects, but through functions and types.

As always, have a nice experience with your Functional start!

How I arrange a React component

Vlad Oganov — Wed, 19 Aug 2020 15:29:46 +0000

In this article, I’m going to offer my vision of how a basic React component should look and how to structure your React app. If you have a different point of view, go ahead and let me know 😉

I do like React and the concept of components as building blocks of your application. So, the fact that React is a library brings freedom to make everything we want and use any approach that we have in our mind. It sounds good because it is, but this liberation of development using React brings our application to the core of chaos: every team uses different concepts and arrangements. And, it touches not just a project folder structure but the arrangement of components as well.

If you’re a newbie in React, read the article about a quick start in React, and then return to us.

Basic React component

To solve the problem of over diversity it’d be great to have a fixed component structure. I prefer the following:

class MyComponent extends Component {
  // prop types

  // state declaration

  // lifecycle methods

  // render

  // event handlers

  // private methods
}

The main idea of such an arrangement is that you process data (state and props) and construct a render method’s JSX. The idea to keep private methods after the “render” function is that you first read a method name in “render” before you read further and understand what the method does. And, if you pick good names for private methods, you rarely need to jump from reading the render method to the bottom of the component to understand what the component does. And, of course, it gives you a better way to understand and “read” a component.

Let’s take a look at an example. We will create a list of items and add an ability to filter the items by title. Also, all items have a formatted date of creation so, for this, we’re going to use a moment – a library with awesome API to process date.

class List extends Component {
 // props types
 static propTypes = {
   items: PropTypes.arrayOf(PropTypes.shape({
     text: PropTypes.string,
     date: PropTypes.string,
   })),
 }

 // state declaration
 state = {
   seachString: '',
 }

 // lifecycle methods
 shouldComponentUpdate() {
   return !_.isEmpty(this.filterItems());
 }

 // render
 render = () => (
   <div>
     <input
       type="text"
       value={this.state.seachString}
       onChange={this.handleSearchStringChange}
     />

     <ul>
       {this.filterItems().map(({ text, date }) => (
         <li key={`${text}__${date}`}>
           {text}
           {this.formatDate(date)}
         </li>
       ))}
     </ul>
   </div>
 ); 

 // event handlers
 handleSearchStringChange = event =>
   this.setState({ seachString: event.target.value });

 // private methods
 filterItems = () =>
   this.props.items.filter(({ text }) =>
     (text.indexOf(this.state.seachString) !== -1));

 formatDate = date => 
   moment(date).format('MMM Do YY');
}

Here we go! We create the component using our arrangement approach, and it makes our components more predictable and quicker at reading your code.

React dumb components

In the React community, we define components as smart, which has a state, and dumb, which has no state. Most of your components should be dumb because they are easy to compose, reuse, and debug.

Most often, the dumb component is a simple function which gets props and returns JSX. And, the arrangement of such components should be simple: all handles should be passed to one and all the data should be already processed and formatted. Take a look:

const Button = ({ label, onClick }) => (
  <button onClick={onClick}>
    {label}
  </button>
)

Actually, there is nothing to arrange and that’s the point: there is only the destructuring and the return of JSX. Simple and reusable.

Summary

The main purpose of such a component arrangement is to bring an order to this zoo of the approaches to work with React components and create a good React project structure. And, yes, you should have a linter for checking your code and keep the same approach in every point of your project. I’d recommend you to use our company’s linter config. We made it for you!

Make your application orderly and it’ll give a great sense of readability and then maintainability in the future 😉

Have a productive coding!

React. Quick Start

Vlad Oganov — Wed, 19 Aug 2020 14:43:51 +0000

Everyone was a newbie in some field. And there is no way to become a pro in an hour. In this article, I’m going to give you a roadmap to react quick start.

The most important and, unfortunately, the hardest part is deciding which order you should learn in, and separating good resources from bad ones. I had this challenge. There wasn’t a lighthouse to show me the way, so it was the way of trial and error to find what I should focus on and what I should ignore.

Learn HTML & CSS and the basics of JS

First and foremost, I hope that you know HTML & CSS and the basics of JS, especially ES6. You should know how to use ES6 classes, instance level arrow functions, and how inheritance works before the React quick start.

Step 0. Install React

The hardest part of every journey is the first step! In our case it is the zero step – install an environment. To make it as fast as possible, use create react app.

You’ll get all things you need, and start learning React without friction with a setup part of development.

Step 1. Learn the React basics

At this step, it will be enough to read the official React guide. Everything you need is there.

Use these code examples as samples, and create your own app by upgrading these code snippets. Pay attention to the rendering of lists, and lifecycle methods.

Before you move further… check:

What is the difference between props and state?
How can we hide some block of JSX under a condition?
Why should we use keys?

Step 2. Learn the React best practices

In the React community, we use the techniques from Functional Programming such as pure functions, immutability, explicit dataflow, etc. For example, you should use .map/.filter/.reduce instead of for loop in the matter of immutability.

Well, to keep things simple, I’d recommend to read the ‘React “Aha” Moments‘ article and take some notes from it. This article will give you the React way of thinking.

Also, reread the following article from the React official docs.

Check my thoughts on how to arrange methods inside a component.

Ask yourself:

What is the inverse data flow?
What the difference between containers and represental components?
How should we use the children prop?

Step 3. Learn React & Redux stack

Of course, it’s harder than just using React for creating some small apps, but in the real development world, Redux is the essential part of any React app, not just attachment. And, of course, there are a lot of other flux-like frameworks, but Redux gives you the simplest way to keep an application state of any scale. Don’t run into this stuff now and start with so-called container components. When you feel it is not meeting your expectations, start using Redux in learning apps and you’ll see how it helps.

Read the official Redux guide.

Check yourself:

Try to draw the React-Redux work cycle. Check this.
When do middlewares come in?

Step 4. Learn React + React Router stack

It goes without saying that we live in the epoch of the web applications, but it’s still web and it’s very important to divide apps by routes to add more semantics. For instance, a route for your blog post /posts/42, or your profile /profile, etc.

Of course, don’t fall into this and push Router everywhere. First, you should experience the problem of the route-less and then you’ll feel how it will make your application smarter and user-friendly.

Read the official React Router guide, and the following article.

Ask yourself:

What is the difference between absolute and relative paths?
How do the nested routes render?

Step 5. Reuse components

To keep your code clean, you should create a component that you can reuse. It’s obvious, but there’s another part of the ‘Reuse components’ principle: don’t be afraid of third-party components. Use the components that were created by other developers because they’ll save you time.

You should also take into consideration the fact that any third-party component is a dependency.

And discover how it works, because you’ll learn from others best practice and principles.

A short list of available components is here.

Step 6. Keep moving and practice more

Learn more, practice more!

Create apps that will solve your problems and make your life more comfortable.
Read articles about React and its environment. Check authors, and follow them on Twitter. Check this for example.
Don’t be afraid of some strange techs, such as Redux Sagas, or Redux Observables. Use them, and you’ll love them ❤️
Investigate the static typing in JS using Flow or Typescript.
Learn React Native to feel the real power of React in the mobile dev field.

React Native: how to split responsibilities across components

Step 7. Be in the heart of the community

We live in the IT age and it’s hard to learn something if you are isolated. You should go to conferences and follow interesting people on Twitter. In general, keep track of the community life, and you’ll always be in-demand as a developer.

I recommend to check these repos from time to time:

Awesome-react
React-redux-links

I also recommend to follow these guys:

More interesting people to follow in the Dan Abramov’s React List.

Wrapping up

If you want to do something, do it well! Don’t be afraid, keep moving, widen your horizons, and learn from other people to evolve yourself. Enjoy your quick start!

Typing React Components with Flow

Vlad Oganov — Wed, 19 Aug 2020 14:31:08 +0000

I’m going to describe how to use Flow in terms of React & Redux. The reason I did this is that this area is not commonly covered. I couldn’t find any best practices or really cool tutorials for using Flow in React & Redux applications. Let’s fix that!

We live in a strange time when almost all programming languages are moving towards static type systems. There are some rumors that Python and Ruby are going to become a static type. And JavaScript is no exception.

There are some options for making JS type safe: TypeScript, Dart, and Flow. I don’t like Dart because of its non-JS appearance. It looks like Java or something similar, but not JS. And of course, it’s not really popular in the JS community.

Another option is TypeScript. In comparison with Flow, in TypeScript, you have to write all of your projects from the beginning, whereas you can apply Flow gradually. And because TypeScript is NOT JavaScript, it cannot follow the ECMAScript standard, and of course, not all libraries are available for TypeScript.

The final option is Flow. It is really amazing! It covers the entire spectrum of typing tools you need, such as type aliases, type inference, type unions, etc.

This article is not for newbies to Flow, because here I focus on React with Flow practices. If you don’t know the basics of Flow, please read my article “ReactJS. Quick Start”, the official Flow docs and then come back to us.

Advantages of using Flow

The advantages of using Flow as a static type checker are the following:

It looks very clear and natural. People with either Haskell or a Swift, Scala, and Kotlin background will find this checker extremely accessible and nice.
It is still JavaScript. We have the same idioms, the same environment, etc.
Your code more reliable. It checks your code at compilation time, not runtime, so that you have feedback about how your code will perform before you run it.
It offers code documentation. You need only one glance to understand what this function wants to accept and what it returns.
It decreases the number of tests. With static type checking, you don’t need to test every function with many conditions and in many contexts to recognize that it doesn’t work like it is supposed to because if it compiles, it probably works. You are recommended to test only high-level APIs such as what a user sees and how a user interacts with your application.

From PropTypes to Props

Currently, react library provides PropTypes for checking the types of props that we pass to a component. That’s cool, but using PropTypes becomes a mess: we have to use the PropTypes namespace and add some strange-looking checkers like PropTypes.oneOf([‘…’]). Also, the main thing is that PropTypes checks your code at runtime, while Flow checks your code before you run it. Check it:

import React, { Component, PropTypes } from ‘react’;

class MyComponent extends Component { 
    static propTypes = {
        label: PropTypes.string,
        status: PropTypes.oneOf(['error', 'fetching', 'ready']),
        items : PropTypes.arrayOf(PropsTypes.string),
        numberOfUsers: PropTypes.number,
        metainfo: PropTypes.shape({
            content: PropTypes.string,
                        userAvatar: PropTypes.string,
        }),
        }
        // cooooode
}

Using Flow, we can clean it up and add more semantics via type aliases and union types. For instance, the status property has a countless number of discrete values, so it’d be better to transform it:

type Status = ‘error’ | ‘fetching’ | ‘ready’;

And now, instead of status: PropTypes.oneOf(['error', 'fetching', 'ready']), we can use status: Status,

We should do the same thing with metainfo too. For this task, we need to type alias the shape of a Metainfo object.

type Metainfo = {
    content: string,
    userAvatar: string,
};

Let’s combine our semantics improvements and Flow syntax in our component. We’d get something like this:

type Status = ‘error’ | ‘fetching’ | ‘ready’;
type Metainfo = {
        content: string,
        userAvatar: string,
};


class MyComponent extends Component { 
    props: {
        label: string,
        status: Status,
        items: Array<string>,
        numberOfUsers: number,
        metainfo: Metainfo,
        }

        // cooooode
}

Pretty concise and clear. One glance and you see what happens.

Pure Components

I hope you know what this is. If not, a small explanation: a pure component is a component without a state or methods inside itself; it is just a pure function that accepts props and returns JSX. Briefly, I like to use this feature with UI things such as buttons, inputs, etc.

The only problem that destroys all the beauty of pure components is PropTypes. We have to make something like this:

MyPureComponent.propTypes = { … }

…or go back to the class declaration. Well, let’s move to Flow. It gives us the ability to create pure components without PropTypes and keep the type safe. I’m gonna show you a comparison example for better understanding. Take a look at this:

import React, { Component, PropTypes } from ‘react’;

class Section extends Component {
    static propTypes = {
        title: PropTypes.string,
                content: PropTypes.string,
                link: PropTypes.string,
        }

        render = () => (
            <div>
           <title>{this.props.title}</title>
           <p>{this.props.content}</p>
           <div>{this.props.link}</div>
                </div>
    ) 
}

Let’s transform it into a pure component using function syntax and Flow:

import React, { Component, PropTypes } from ‘react’;

    type SectionProps = {
                title: string,
                content: string,
                link: string
        };

const Section = ({ title, content, link }: SectionProps) => (
    <div>
        <title>{title}</title>
            <p>{content}</p>
            <div>{link}</div>
        </div>
) ;

Awesome! In my opinion, this looks simple and clear.

Redux (Action Creators, Thunk Action Creators, Reducer)

Action creators are just pure functions that accept something and return an object. To increase safety, we can use types. But this is not the only reason to use Flow; we can add the semantics to it. For instance:

export const fetchedUserProfile = user => ({
        type: ‘fetchedUserProfile’,
        payload: {
            user,
        },
});

Using Flow, we can make our type for the user to check that the user object has the properties we expect. Also, we can do the same for action so that it’ll enforce the convention about what action should look like:

type User = { id: number, name: string, email: string };

And for actions:

type ActionType = ‘error’ | ‘fetchUserProfile’ | ‘fetchedUserProfile’;
type Action = { type: ActionType, payload: Object };

With our new types, the transformation of the fetchedUserProfile function will be the following:

export const fetchedUserProfile = (user: User): Action => ({ … });

Just one glance and you’ll know how to use it. Documentability! 🙂

Reducer is just a function too, so we can add some magic (not) to it via types. A plain reducer:

const defaultState = {
    status: ‘’,
    userProfile: {},
    items: [],
};

const reducer = (state = defaultState, action) => {
    switch(action.type) {
            case ‘’: {}
            default: return state;
    }
};

Add types:

type User = { id: number, name: string, email: string };
    type Items = { id: number, content: string, check: boolean };

    type ActionType = ‘error’ | ‘fetchUserProfile’ | ‘fetchedUserProfile’;
    type Action = { type: ActionType, payload: Object };

    type State = {
        status: ‘error’ | ‘loading’ | ‘ready’,
        userProfile: User, 
        items: Array<Items>,
    };

And our reducer becomes cool and clear:

const defaultState: State = {
    status: ‘’,
    userProfile: {},
    items: [],
};

const reducer = (state: State = defaultState, action:  Action): State => {
    switch(action.type) {
            case ‘’: {}
            default: return state;
    }
};

Meow :3

We’re moving further toward more advanced types of action creators—thunk action creators. Here we can also use types, but it’s more developed than previous cases.

const fetchUserProfile = (userId) => (dispatch) => 
    User
    .load(userId)
    .then(response => dispatch(fetchedUserProfile(response.user)))
    .catch(() => dispatch(fetchingError()));

Are you ready for types? Of course, you are!

type ActionType = ‘error’ | ‘fetchUserProfile’ | ‘fetchedUserProfile’;
type Action = { type: ActionType, payload: Object };

type Dispatch = (action: Action) => void;


const fetchUserProfile = (userId: number) =>
(dispatch: Dispatch): void => 
    User
    .load(userId)
    .then(response => dispatch(fetchedUserProfile(response.user)))
    .catch(() => dispatch(fetchingError()));

I’d recommend you look at some examples of using types with async functions in the official docs. There you’ll find awesome instances of using Flow with asyncs.

Don’t Use Object

In this section, I’d like to go on a tangent and talk about generics. It’s useful to raise a level of abstraction and make boxes around the things with different types.

Do you remember our Action type? No? Me either 🙂 JK

type Action = { type: ActionType, payload: Object };

It isn’t type safe in light of the payload property’s type because we can place every object with whatever signature. The only one that works—unpredictable. How can we solve this problem in terms of Flow? Use disjoint unions. Look at this:

type Action =
{ type: ‘create’, payload: { name: string } }
|  { type: ‘delete’, payload: { id: number } }
|  { type: ‘update’, payload: { id: number, name: string} };

Type library

Move your types to a separate module (js file) so that they can be used in other modules and be the same throughout the entire app. You just need something like this:

// types.js
export type User = { name: string, email: string, id: number | string };

And just import it to another js file.

// actions.js
import type { User } from ‘./types.js’;

Add more semantics

Instead of using types only for checking the reliability of your apps, you should use it to add an explanation of what it is via the type name. Check the following example:

type Password = string;

I think it is more understandable for further use now.

Summary

Use type aliases and union types to add more semantics.
Use pure components.
Use types for class components.
Use types for action creators.

But enough is enough. Don’t type alias everything, and don’t recreate the wheel.
Well, thank you for coming! Love React, use types, and be happy.

useReducer for the win

Vlad Oganov — Mon, 25 May 2020 18:42:58 +0000

Hey, how are you there? Well, here is a story. It's quite small, but it can save your time and health. So keep reading.

We wanted to have a sequence of steps in our application which it’s changed depending on user’s answers. Take a look:

step with yes/no question -> if yes: Step 1 -> if yes: Step 2 -> Step 3 -> Step 4
                          -> if no: skip    -> if no:  skip   -> Step 3 -> Step 4

The logic is the following:

User pick an answer in a form
The form sends the data to an API – the API persists the answer
On success we change the state of the redux store
We change a flow of steps depending on the answers
Go to the next step accordingly to the flow
Profit

Disclaimer 1.: there is a pretty nice library that can help to manage sophisticated flows – xstate. And for this case it'd be an overkill, so we created our small, simple, homemade solution 😌

Disclaimer 2.: the code presented here is simplified to focus on the issue. Please, don't judge

And here is the code:

function useSteps(flow) {
  const [step, setStep] = useState(_.first(flow))

  const goBack = () => {
    const prevStep = _.nth(flow, flow.indexOf(step) - 1)

    setStep(prevStep)
  }

  const goForward = () => {
    const nextStep = _.nth(flow, flow.indexOf(step) + 1)

    setStep(nextStep)
  }

  return { current: step, goForward, goBack }
}

function LeComponent() {
  const entity = useEntity()

  const flow = [
    STEP_1,
    entity.yesOrNo === 'Yes' && STEP_2,
    entity.yesOrNo === 'Yes' && STEP_3,
    STEP_4,
  ].filter(Boolean)

  const steps = useSteps(flow)

  return pug`
    if steps.current === STEP_1
       LeForm(
          onCancel=steps.goBack
          onSubmitSuccess=steps.goForward
        )

    if steps.current === STEP_2
       .........
  `
}

And it won't work. Every time we run it, onSubmitSuccess is called with the old steps.goForward so even if user answered 'yes', we redirect them to Step 3. Meh. Worth to mention: the entity and the flow are updated correctly before the action of going forward. It. Must. Work. Except it doesn't.

Ok, an overengineered solution to help. Every time user updates the value in the form we update the state of the parent component using redux-form's onChange. Also we have to sync the state of our component with the state that has been persisted on the API in case of the page reloading – so we have this useEffect there. Shit is getting crazy. Take a look:

function LeComponent() {
  const entity = useEntity()

  const [yesOrNo, setYesOrNo] = useState(null)
  const handleYesOrNo = formData => setYesOrNo(formData.yesOrNo)

  useEffect(() => {
    setYesOrNo(entity.yesOrNo)
  }, [entity.yesOrNo])

  const flow = [
    STEP_1,
    entity.yesOrNo === 'Yes' && STEP_2,
    entity.yesOrNo === 'Yes' && STEP_3,
    STEP_4,
  ].filter(Boolean)

  const steps = useSteps(flow)

  return pug`
    if steps.current === STEP_1
       LeForm(
          onCancel=steps.goBack
          onSubmitSuccess=steps.goForward
          onChange=handleYesOrNo
        )

    if steps.current === STEP_2
       .........
  `
}

Perfect! I'm being paid for a reason definitely. But no, come on, we can't leave it as that. What if we need to track more answers? So we started to investigate if there is something wrong with redux-form. Every value around is new, but onSubmitSuccess is living in the past.

And we didn't find what really happened. Instead we decided why not to use useReducer in the useSteps. How? Take a look:

function useSteps(flow) {
  function reducer(step, action) {
    switch (action.type) {
      case 'goBack':
        return _.nth(flow, flow.indexOf(step) - 1)
      case 'goForward':
        return _.nth(flow, flow.indexOf(step) + 1)
      default:
        return step
    }
  }

  const [current, dispatch] = useReducer(reducer, _.first(flow))

  const goBack = () => dispatch({ type: 'goBack' })

  const goForward = () => dispatch({ type: 'goForward' })

  return { current, goForward, goBack }
}

Sweet! Now goForward just push an action w/o rely on the closure, so we can remove all of these stuff of keeping state of the answer in the component and make it in the react way so to say.

And it worked out 🚀 And this is a nice practice in your toolkit for creating such flows with conditional showing of steps. Be happy.

Cheers!