One Year of Learning React in One Article: 5 Tips for Beginners
By: Anthony Oleinik
Tags: Beginners Website Design, Typescript, React, Frontend

React

For the past year, I focused on learning React for my PWA’s. This was 12 months ago — today, I’m teaching you five tips I learned in the last 12 months that helped supercharge my React Development.

1. Use Typescript!

My first dabble into React was using JS. While JS has come miles from where it started, the dynamic typed nature of it brings many problems that can never be fixed by cool ES features. Time and time again, I was passing in a prop or a variable that was undefined and getting runtime property access errors — it’s just not possible to expect a human to find every single time a variable might be undefined.

The switch to Typescript made me 10x as productive as before — no longer did I spend hours debugging in a programming session. Typescript compiler would catch most of my runtime errors that would have reared their ugly head in JS at compile time. For those of you just starting learning React, skip the month-and-a-half of hair-pulling debugging and console.log('is' + var + ' undefined?') 's - go straight to the type-checked heaven that is Typescript.

There are those that argue that Typescript is just slower to prototype. That typing variables takes longer than writing a simple let t = MyObj() . I find that after an incredibly short learning curve that is learning Typescript, you actually prototype faster than using JS - this is because you can be confident that you have the properties you need on your objects and that they're actually there when you need them, instead of being undefined or tied to the prototype of the object.

If you were to listen to one tip on this list, writing TypeScript would be that one that puts you 10 steps ahead.

2. Use Functional Components for Efficient, Readable Code

Coming from Flutter, class components were a much quicker learning curve than functional. At first, I avoided functional components — hooks were hard to learn, passing arguments into functional components was confusing and having setState variables for each state variable was confusing.

I do spend some time on Reddit, though, and 100% of r/React were sold on functional components. I decided to bite the bullet and write my next component as a functional one due to the unanimous love for them.

I never wrote a class component again.

Take the following component, for instance:

IMyComponentProps {

prop1: string

prop2: string

prop3: string

}



interface IMyComponentState {

state1: number

state2: number

state3: number

}



export class MyComponent<IMyComponentState, IMyComponentProps> {

this.timer: NodeJs.Interval



componentDidMount() {

this.timer = setInterval(() => this.onRefresh, 200)

fetchApi().then((data) => this.setState({ state3: data }))

}



componentDidUnmount() {

clearInterval(this.timer)

}



onRefresh = () => {

fetchApi().then((data) => this.setState({ state3: data }))

}



build(): JSX.Element {

return <OtherComponent onClick={this.onRefresh.bind(this)} />

}

}

Let’s take a look at what’s wrong here:

That’s a lot of code to make an API call every 30 seconds.

The .bind() calls are ugly, but are necessary for the code to function properly.

calls are ugly, but are necessary for the code to function properly. Around 30 lines of code for a simple class component.

a lot of this , which is notoriously confusing in TS/JS. (although TS will save you from some difficulties of this )

A functional component can make all that better:

IMyComponentProps {

prop1: string

prop2: string

prop3: string

}



export const MyComponent = ({ prop1, prop2, prop3 }: IMyComponentProps): JSX.Element => {

const [state1, setState1] = useState(0)

const [state2, setState3] = useState(0)

const [state2, setState3] = useState(0)



let timer: NodeJS.Interval



const onRefresh = () => fetchApi().then(setState3)



useEffect(() => {

timer = setInterval(onRefresh, 200)

return () => clearInterval(timer)

})



return <OtherComponent onClick={onRefresh} />

}

one third the code

easier to follow

can fit in more succuient ES6 features

no worrying about this

All around a better deal, and honestly, not that high of a learning curve either. Perhaps more advaced hooks will require more learning, like useRef , but those are not necessary and only helpful - and don't have class component equivalents.

Learn functional components ASAP — it’ll make you a better developer.

3. The Best State Management Solution: Unstated-Next

This point is one of the more controversial ones. If you don’t know what a state management solution is, here’s my one sentence intro: Sometimes, you need to share state between components (for instance, the username of a logged in user or if they’re logged in or not) and it’s not practical to pass around a username to hundreds of components — instead, you have some sort of higher-scope store to store the data so many components can access it.

I’ve met many, many Redux fans — they love the rigidity, and if that’s you, that’s fine! But I’m a fan of making a change in one place and having it just work. With Redux, I find myself stuffing a bunch of state variables in a single Redux Store, so that I don’t have to rewrite all that boilerplate.

Unstated Next is by far the simplest state management solution. I’m not going to write a full Unstated Next tutorial, but there wouldn’t be much of a tutorial. The readme is all you need to read, and you know everything you need to know.

Unstated Next is the simplest state management solution of all time, and does everything redux does.

4. Snowpack > Create React App

Create React App isn’t bad by any means — it’s actually great at what it does. But I do think there are other great-er options out there. For instance, the one I have been using lately is Create Snowpack App. Create Snowpack App has blazingly fast compilation speed. Create React App, on larger projects, takes a little bit of time to compile. Create Snowpack app has O(n) compilation time because it only recompiles the file that you changed. This means that a huge project will have the same compilation speed of a smaller project - something that CRA can't promise you. After feeling the pains of CRA on larger projects, CSA was the no-brainer alternative. I haven’t looked back.

CSA is a huge change that will turbo boost your next project.

I built my own CRA boilerplate — it has my favorite eslint configuration and a few tsconfig changes I like to work with. You’re free to run this command for the boilerplate :)

git clone https://github.com/antholeole/snowpack-boiler.git

5. Just Build!

The best tip I have is to maximize your coding time. While all these tips will supercharge your development, you have to learn your methodologies. The only way to do that is to develop on your own, without a tutorial working on a project that inspires you.

For instance, one of the personal changes I made is that my eslint config doesn’t allow semicolons. If you like semicolons, that’s perfect and don’t be afraid to carve your own path.

Here are some things you’ll have to decide in your front end journey: