A few to share when applying Typescript to ReactJS App

Friday, 20/03/2020

Tram Ho

I. Introduction

Typescript is becoming more and more popular, a lot of advice to use Typescript , many large libraries have refactor the JS source code with Typescript , Angular has long used TS as the main “language”, the most powerful and popular Editor currently Nowadays – VSCode is developed almost 100% by Typescript . I ask myself, should we all switch to using TS instead of using Javascript ?
And finally, I didn’t escape the storm, I couldn’t learn Angular because I was afraid to do Typescript , I’ve been using JS with dynamic types all year round, now I hear type checking like some “traditional” languages. shy. Then one day my recent React project was asked to use Typescript , that’s it. And here are some of their share over time develop web applications with TS + React.

II. Install apps

In accordance with the idea of not revinvent the wheel , I use create-react-app , there are typescript options already available, hihi.

npx create-react-app app --template typescript

1 2	npx create-react-app app --template typescript

OK, done with the code . One thing to note is that for files containing components requires the extension .tsx , for example, for App.tsx

import React, { FC } from 'react'

interface PropTypes {
  title: string;
}

const DemoComponent:FC&lt;PropTypes&gt; = ({ title }) =&gt; {
    return (
      &lt;div&gt;{title}&lt;/div&gt;
    )
}

const App:FC = () =&gt; {
  return (
    &lt;DemoComponent title="Hello World" /&gt;
  )
}

import React, { FC } from 'react'

interface PropTypes {

title: string;

}

const DemoComponent:FC<PropTypes> = ({ title }) => {

return (

<div>{title}</div>

)

}

const App:FC = () => {

return (

)

}

III. Type everywhere.

Because it’s Typescript , everything we declare needs a type definition. The dependencies we install also need a type definition, usually in the dependencies accompanied by a prefix name of ” types / {name} ” such as types / lodash , types / react , …
In essence, Code TS needs to be compiled into JS , during the compilation process, if the type check is not guaranteed, the application will immediately report an error and cannot operate with a loving red screen. In the above example, if DemoComponent received the props incorrectly as follows:

const App:FC = () =&gt; {
  return (
    &lt;DemoComponent title={5} /&gt;
  )
}

const App:FC = () => {

return (

)

}

We will get the result: OK so need to declare all types and also always need to use all types everywhere. This was very time-consuming at first, because I got used to JS , sometimes frustrating because I had to debug.
But after a while getting used, I do not see much loss of time, whereas this type of check also helps minimize errors due to their dynamic properties of JS caused. A simple example offline.

import React, { FC } from 'react'

interface PropTypes {
  data?: {
    id: number;
    title: string;
    content: string;
  };
}

const DemoComponent:FC&lt;PropTypes&gt; = ({ data }) =&gt; {
    return (
      &lt;div&gt;
       &lt;p&gt;{data.title}&lt;/p&gt;
       &lt;p&gt;{data.content}&lt;/p&gt;
      &lt;/div&gt;
    )
}

import React, { FC } from 'react'

interface PropTypes {

data?: {

id: number;

title: string;

content: string;

};

}

const DemoComponent:FC<PropTypes> = ({ data }) => {

return (

<div>

{data.title}

{data.content}

</div>

)

}

In this example, we declare prop can data is an object containing the attributes id, title, content, however the component initialization, when no call api suppose it is an undefined value.
When the code comes here, the TS will prompt us to check the condition when the data does not exist.
Here we can fix it by adding the following condition:

const DemoComponent:FC&lt;PropTypes&gt; = ({ data }) =&gt; {
    if (!data) return null;
    return (
      &lt;div&gt;
       &lt;p&gt;{data.title}&lt;/p&gt;
       &lt;p&gt;{data.content}&lt;/p&gt;
      &lt;/div&gt;
    );
}

const DemoComponent:FC<PropTypes> = ({ data }) => {

if (!data) return null;

return (

<div>

{data.title}

{data.content}

</div>

);

}

The code that is always checked by the testers is less error-prone, right? And after a while, TS friends have to remind me less and less, I also feel more confident when coding than using JS before.

IV. But it doesn’t matter if you don’t have Type

Don’t get me wrong, this part won’t work with the previous one. Understandably, you can still maintain the dynamism you have with JS , because type checking in TS is completely optional. The following three ways of writing are valid for TS .

<span class="token keyword">const</span> a <span class="token operator">=</span> <span class="token number">5</span>
<span class="token keyword">const</span> a <span class="token punctuation">:</span> <span class="token builtin">number</span> <span class="token operator">=</span> <span class="token number">5</span>
<span class="token keyword">const</span> a <span class="token punctuation">:</span> <span class="token builtin">any</span> <span class="token operator">=</span> <span class="token number">5</span>

const a = 5

const a : number = 5

const a : any = 5

TS makes the code more secure but still gives you some freedom, for fixed values, or values that are difficult to determine the exact type , such as the response of the api for example, there is still a way to You have no difficulty with type checking at all. However, note that only use any when really necessary.

V. Full ecosystem

It’s already 2020 and I have almost no difficulty with third-party denpendencies when using typescript . React-Router , Redux , Lodash , Moment , Axios , Styled-components or other libraries all support full typescript . Sometimes there will be a few small libraries that do not support typescript but they are insignificant.
Eslint for typescript is also very simple to use, almost no different from normal at all.
Regarding the Development Tool , I use VSCode and this Editor supports typescript very well, because as I said above, it is also used by microsoft typescript to write on it.

BECAUSE. Redux will become complicated

Why do I say complex, because redux itself has been hated by many because it is complicated, to create a simple function, we declare an action types , then declare actions , then declare reducer , then declare the mapStateToProps function and put the component in react-redux ‘s connect function, …
I tried adding redux to the react + typescript application , I followed the instructions on the redux document , and I gave up because declaring the type for each action and checking the type of the action in the reducer made the code much more cumbersome. . Maybe I did something wrong somewhere, maybe I will have a chance to try again later, but now I’m quite happy with mobx .

VII. Everything is still the same

One thing is that after getting used to the TS syntax, I don’t feel there’s any difference between React + JS and React + TS , everything is the same, TS is not a new programming language, was born to JS replacement which is merely a supporting tool to help develop JS applications. When developing web applications using React , the things we care about everyday are component, prop, state, html, css, etc. and typescripts are just a spice added. I think that TS is really good as well as JS doesn’t have any big disadvantages, it’s still worth our trust.

Share the news now

Source : Viblo

A few to share when applying Typescript to ReactJS App

I. Introduction

II. Install apps

III. Type everywhere.

IV. But it doesn’t matter if you don’t have Type

V. Full ecosystem

BECAUSE. Redux will become complicated

VII. Everything is still the same

TikTok becomes the second largest social platform in South Africa

The fastest depreciating after 9 months of launch, iPhone 14 Pro Max continues to break the bottom in Vietnam

Beginner's guide to R: Introduction

10 essential SublimeText plugins for JavaScript developers