DEV Community: JJ

I created redux-api-struct.

JJ — Wed, 06 Feb 2019 04:53:31 +0000

I wrote this article before.

https://qiita.com/konojunya/items/07fd138144cb410da387

This article translated into English what I wrote in Japanese on a site similar to dev.to, Qiita Japan.
Because I'm Japanese and I'm not good at English, I translated it using a translation machine, but please tell me if there is a mistake in English.

I published a library called redux-api-struct.
This is a library in which you can write more concise and more type-safe logic for React and asynchronous applications managed by redux.

The API is described in the README, but here's a quick way to use it.

The characters are React, Redux, and Promise.
Take the example of a common technique for a Web application that usually accesses resources to the API.

For example, you are making a blog service. There is a detailed screen of the article. The API uses GET method to access /articles/:id.
Let's say that the value is managed by the state article. article the details are assumed to be the following structure.

interface Article {
  title: string;
  body: string;
}

If the api is accessed and statusCode is 200, article will look like this:

{
  article: {
    title: "hoge title",
    body: "hoge body"
  }
}

Now consider a component that display this.
The following functional component is defined:

import * as React from "react";

interface Props {
  article: Article;
}

export const ArticleTemplate: React.FunctionComponent<Props> = ({ article }) => (
  <>
    <h1>{article.title}</h1>
    <p>{article.body}</p>
  </>
)

It seems to be good if it passes the article to props.

Let's try to actually move. Then, the error comes out depending on the writing. If the article initialState is null, it will be null.title access and an error occurs. Let's define an empty string instead of putting null.

The page will then be displayed. If an empty string and an empty body are displayed and the api access is success, you can see the article.

But what if there is an error in the api?
For example, if you access the URL of an article that does not exist in the article details, 404 is returned.
You have to render the not found page. It is necessary to know whether the request was successful or not.
That's why we have three articles to fetch, success, and failure. But for example if you want to put out a loading screen other than these, in the current situation, for example, title is an empty string will be implemented such as fetching.
It is redux-api-struct to be able to handle all these easily. :)

Initial the access state to the api initial, fetching, success and failure has managed in four states.

The component only has to switch between the four states. Accessing the actual data is not an error like referencing null unless it is success.

The first thing to do is to bind the state of the reducer with the type ReduxAPIStruct.

import { ReduxAPIStruct, createDefaultStruct } from "redux-api-struct";

interface InitialState {
  article: ReduxAPIStruct<Article>;
}
const initialState: InitialState = {
  article: createDefaultStruct<Article>(null)
}

The type passed to generics of ReduxAPIStruct is the original data type.

The state wrapped by this ReduxAPIStruct has the following tree structure:

interface WrappedArticle {
  state: ReduxAPIState,
  data: Article,
  error: ReduxAPIError
}

The status is managed by the four states described above.

Please read the implementation of the component as it is easier to see the README.

https://github.com/konojunya/redux-api-struct#usage

In this way you can easily create an asynchronous web application while keeping the type safe.

p.s.

If you like it or if you have a bit more consideration, I'd be happy to have a star or issue.

Thanks.

Author: @konojunya

How to treat component as TypeSafe in Redux + Atomic Design

JJ — Mon, 05 Nov 2018 04:35:16 +0000

It rewritten what I made an article on Nihon Qiita technology sharing service to English.
The article of Japan is as follows.

俺の考えたRedux + Atomic DesignでTypeSafeにコンポーネントを扱う方法

It is poem. Let's take notice of browsing :)

First of all apologize because you may think you do not understand Atomic Design in the first place.
Just as a common recognition, I also write it in the document, so I will use this method to operate.

Directory structure

- src/
    - actions/
        - hoge.ts
    - api/
        - client.ts
    - components/
    - model/
        - type.ts
    - store/
        - index.ts
        - reducer-type.ts
        - sagas/
        - reducers/

ActionCreator is described inactions.
The API surroundings (communication using axios) are summarized in client.ts.

The components subordinate is modeled on Atomic Design.

model/type.ts is managed by separating them with namespace Payload Response Domain.
For example, if you use API to login with email and password Payload.Signin

interface Signin {
  email: string;
  password: string;
}

This is a type to be used as Payload of Action later.

The response of that API is summarized in Response.Signin.

example

interface Signin {
  name: string;
  icon: string;
  token: string;
}

store in addition to index.ts doing combineReducer etc, there is reducers which defines Reducer, sagas which writes saga, and so on.

It is reducer-type.ts that helps the shape that I created in this project.

What is contents of reducer-type.ts

reducer-type.ts has the following contents.

export interface ReduxAPIError {
  statusCode: string;
  message?: string;
}

interface ReduxAPIStruct<T> {
  isLoading: boolean;
  status: "success" | "failure";
  data: T;
  error: ReduxAPIError;
}

export const defaultSet = <T>(defaultValue?): ReduxAPIStruct<T> => ({
  isLoading: false,
  status: null,
  data: defaultValue || null,
  error: errorDefault()
});

export const errorDefault = (): ReduxAPIError => ({
  statusCode: null,
  message: ""
});

export default ReduxAPIStruct;

Inside the application I read this useful tool as ReduxAPIStruct.

What is important is the interface below.

interface ReduxAPIStruct<T> {
  isLoading: boolean;
  status: "success" | "failure";
  data: T;
  error: ReduxAPIError;
}

Each describes the motion when communicating with the application.

isLoading is managed by boolean and deals with whether or not it is loading.
status is created to facilitate fallback to the error component later.
data is the data body when actually obtained from the API. Here is defined as generic with T. When using this type later, pass the Response type of model/type.ts just as it is.
error has a type called ReduxAPIError.

export interface ReduxAPIError {
  statusCode: string;
  message?: string;
}

ReduxAPIError has statusCode and message.
statusCode sets the statusCode of the response when accessing that API.
Message has a type to insert it in the response body from the server and later in saga.

A world with ReduxAPIStruct

First of all, as an important point of what imitated Atomic Design, we separated the clear responsibilities of pages and template.
For example, connect redux only to components of paegs class.

We define pages as a single page which has data and is linked to the URL .
On the other hand, template was created as a UI based on data .

By separating this clear obligation, the pages component looks like this.

For example, I would like to create an article list page that receives the following data.

{
  "items": [
    {
      "title": "タイトル1",
      "body": "本文1"
    },
    {
      "title": "タイトル2",
      "body": "本文2"
    },
    {
      "title": "タイトル3",
      "body": "本文3"
    }
  ]
}

Suppose that the endpoint of this API is [GET] /items and the axios API client is an implementation as follows.

import axios from "axios";

class Client {
  public getItems() {
    return axios.get("/items");
  }
}

The client implements it to return Promise .

The saga code will end, but let's say the result is in the key items of article reducer .

import * as React from "react";
import { connect } from "react-redux";
import { withRouter } from "react-router";
import { requestGetItems } from "~/actions/article";
import ErrorHandler from "~/ErrorHandler";

// templates
import ItemsPageTemplate from "~/components/templates/ItemsPage";
import LoadingTemplate from "~/components/templates/Loading";

// type
import { Response } from "~/model/type";
import ReduxAPIStruct from "~/store/reducer-type";

interface Props {
  items: ReduxAPIStruct<Response.Article.Items>;
}

class ItemPage extends React.Component {
  public render() {
    const { items } = this.props;
    if(items.status === "failure") {
      return <ErrorHandler errorStatus={items.error.statusCode}/>;
    }

    return items.isLoading ? <LoadingTemplate /> : <ItemsPageTemplate items={items.data} />;
  }
}

export default wituRouter(connect(
  state => ({ items: state.articleReducer.items })
)(ItemPage) as any);

If data is being acquired with this, LoadingTemplate will fail and fetch of data will fail.
If it fails to ErrorHandler it succeeds and ItemsPage will be mounted.

You can manage these three states regardless of which page you write or not thinking about anything.

Thanks to ReduxAPIStruct you can easily understand whether that data is in fetch or not, and failing fetch can also be understood by looking at status.

When saga is written by cutting this state management to another state, it is possible to manage the state without thinking about the component.

Afterword

I translate my English using Google Translate. If there is a mistake as a description of English, please point out with comments :(

Twitter: @konojunya
GitHub: konojunya