The React Newsletter

Hi <<First Name>>,

How to build bulletproof react components

React is a declarative framework. This means instead of describing what you need to change to get to the next state (which would be imperative), you just describe what the dom looks like for each possible state and let react figure out how to transition between the states.

Shifting from an imperative to a declarative mindset is quite hard and often times when I spot bugs or inefficiencies in code it's because the user is still stuck in an imperative mindset.
In this blog post I' ll try to dive deep into the declarative mindset and how you can use it to build unbreakable components.

Next.JS vs Gatsby.JS: Picking The Right React Framework

As web development advances, the way we assemble websites and front-ends is also changing.

Web applications used to be simple static HTML pages with a few hyperlinks and terrible animations we built in our 2nd grade library time.

However, developing web applications and websites has become much more complex in this modern era.

New frameworks, libraries, and tools are developed on a daily basis and it can be hard to keep up. As a result, many advancements in web technology have focused on simplifying web development. Some of those include concepts like headless content management systems, like ButterCMS, which help simplify back-end development.

On the front-end, there are plenty of frameworks to choose from when it comes to development.

These frameworks include React.js, Angular.js, Vue.js and many more.

React is currently one of the more popular front-end javascript frameworks. With its popularity comes many tools that leverage React and play a role in simplifying the React development process. Two such tools are Next.js and Gatsby.js.

Both of these frameworks were developed to help ease the connection between the back and front-end. Partnered with the right headless CMS, this workflow can majorly streamline your development process.

But what is the difference between Next.JS and Gatsby? First, let's take a look at each individually.

React GraphQL App (MERNG): #5 Authentication Context

In this class, we set up an auth context in which we store an application wide state and distribute it so that all of our components are aware of our authentication status.

Watch video

Make your own DevTools

How many times have you entered the username/password on the local version of your app? How many times have you filled out that one form just so you could fix that bug that only shows up when some specific fields are filled in a specific way? How annoying is it to have to restart your dev server when you want to change which backend environments your frontend is hitting?

I don't know whether these things all apply to your situation at work, but these things were really annoying for me when I worked on an admin portal at Alianza. So I thought about creating a browser extension like I'd seen people do at previous jobs I had worked at. That way I could have the extension control the app/environment. But I remembered trying to work on and contribute to those and it was pretty indirect and not entirely straightforward. And there were some things I wanted to do only temporarily, and only for my own development, not the rest of the people using the extension. The other problem with an extension is that there are quite a few limitations to extensions and I didn't want to have to hack around those.

9 Tips for Building Awesome Reusable React Components

Type-checking is essential for a positive dev experience and an optimized code collaboration. It is a way to make code much more intelligible to others, as well as to your future-self.

Read more

Decouple from Redux Using Hooks

Received wisdom in the react community holds that you should subdivide your components into 'smart' containers and 'dumb', presentational components.

The rationale is to separate concerns. Logic and behavior such as data fetching, any interaction with the outside world, dispatching actions and other side effects go into our smart container and what our UI should look like as a function of the resulting data into our dumb component.

This idea leads to a pervasive pattern of creating container components solely for the purpose of connecting a part of the component tree to the redux store. So we end up with two components; one in a containers folder fetching data from the store and passing down actions and the actual component in the components folder.

To me, this quickly felt cumbersome and rigid, if I simply wanted a component to have access to a slice of the store, I found myself having to create an intermediary container and changing a number of imports in other files that use the component.

React video courses

Because I need to pay my bills 😉