DEV Community: Jakob Lind

What is babel-preset-env and why do I need it?

Jakob Lind — Tue, 23 Apr 2019 18:04:40 +0000

If you have followed any recent tutorial on how to set up a modern JavaScript project, you have installed Babel and then added babel-preset-env to your .babelrc:

{
  presets: ['@babel/preset-env']
}

...and things works fine. It transpiles the ES6 for you just like you wanted to and you move on with the tutorial.

But what did you just do with your .babelrc file and why does it work?

It's not a nice feeling to just type something that you read in a tutorial without really understand why you should use it. Let's look into what babel-preset-env really do, and why you need it.

This is part 2 of my post about implementing ES6 with Babel and webpack. In the first part, you learned the basics of what problems Babel solves.

Before I can tell you what babel-preset-env does, I need to explain the basics of Babel to you. It's good to refresh even if you feel you already know it.

Babel from scratch

The most common way to use Babel is together with a build system such as webpack. When using Babel with a build tool it's easy to overlook how Babel really works. It feels like Babel and webpack is the same thing.

A good exercise is to learn Babel without a build system - even though you don't intend to use it that way in production. So get your editor and terminal ready and code along.

First create a new NPM project:

mkdir babel-test
cd babel-test
npm init -y

Next install Babel as dependency to your empty project:

npm install --save-dev @babel/core @babel/cli

Add a file called input.js and add the following to it:

const hello = () => console.log("hello world!");

That is an arrow function which is an ES6 feature. This is supported in most browsers but not all, that's why it's a good idea to transpile it to ES5. Now let's run this file through Babel:

npx babel input.js --out-file output.js

If you open output.js, you'll see that nothing has changed. It's exactly the same content as input.js. That's not what you expected, was it? The reason for this is that Babel doesn't do anything out-of-the-box but Babel is built on presets and plugins. If you don't add any presets or plugins, then Babel will do nothing.

Babel doesn't do anything out-of-the-box

It's the Babel plugins that does the work

To make Babel actually do something, we need to add a plugin. It's the plugins that does the heavy lifting.

Each plugin is it's own NPM library. So for every plugin you want to install, you have to install a new NPM library or you can use a preset that we'll come back to in the next section.

In the code you have written in input.js you only have one ES6 feature: an arrow function. So what we are going to now is to install a Babel plugin that transpiles ES6 arrow functions.

Let's start by installing a plugin that transpiles the function you have written in input.js file.

npm install --save-dev @babel/plugin-transform-arrow-functions

Next, you need to tell Babel to use the dependency. Add a file called .babelrc file to the root of your project. This is the configuration file for Babel, and you'll use it to tell babel to use the plugin @babel/plugin-transform-arrow-functions when doing the transpliation. This plugin only transpiles ES6 arrow functions.

{
  plugins: ['@babel/plugin-transform-arrow-functions']
}

Ok, that's it. Now you can re-run babel and look at the generated output.js file. It now contains the transpiled code!

const hello = function () {
  return console.log("hello world!");
};

That's awesome! But if you want to use more ES6 features you would need to install one NPM package and add an entry in .babelrc for every feature. That's just too much work. But there is a solution to this: presets!

Babel presets bundles together common Babel plugins

The Babel foundation has created presets that contains common bundles of plugins. That means you only have to do the NPM installation and babel configuration once and then a bunch of plugins are automatically installed for you.

There are many different Babel presets, both official presets from Babel foundation and unofficial presets from other organizations such as Airbnb. Heck, you could even create your own preset if you want.

The official presets are:

@babel/preset-env
@babel/preset-flow
@babel/preset-react
@babel/preset-typescript

Every preset is its own NPM dependency that you need to install and configure. Ok, now you are finally ready to learn about babel-preset-env.

Ok, now babel-preset-env

Let's convert you mini-code base to use babel-preset-env instead of @babel/plugin-transform-arrow-functions

Install the NPM dependency:

npm install --save-dev @babel/preset-env

Next, configure in the preset section of your .babelrc file

{
  presets: ['@babel/preset-env']
}

What you have done now, is that you have installed the basic configuration of babel-preset-env. Out-of-the-box you get all plugins you need to transpile all ES6 features!

But babel preset env is smarter than this. You can have even more fine grained controll over what plugins should be installed

The unique selling point with babel-preset-env is that you can define what browsers you support

By default, babel-preset-env just installs all ES6 plugin you'll need. But this can bloat up your bundle. Look at this example how modern ES6 is transpiled to old legacy JavaScript code

From this tweet by @jamiebuilds

On the left is the ES6 code, then you can see in the middle how much code is generated if you must support very old browsers. And the amount of code needed to support not-super-old browsers to the right.

The amount of code needed to support old legacy browsers in this example is extreme.

So if you only use the default babel-preset-env you might end up in a bloated bundle. What can we do about this?

It would be nice if there were a way to tell Babel to not use all plugins, but only a subset of plugins that you really need. That way less of your code gets transpiled to bloated ES5 code.

If you read my previous post on this subject, you learned that most modern browsers already support most ES6 features. If you look at Google analytics for your site you might realize that 99% are on modern browsers. So maybe you don't have to support all old browsers that have ever existed.

When you have made a decision on what browsers you want to support, you can tell babel exactly what browsers you should support with babel-preset-env. You do that with the config file called .browserlistrc which is part of a standard that defines what browsers your app supports. Babel-preset-env reads from this config file.

You can, for example, say you don't support IE by adding the following to your .browserlistrc file:

not ie all

or that you define that you only support browsers with a market share of 0.25% or more:

>0.25%

If you describe to babel-preset-env what browsers you support, it can use less plugins, and that means less unneeded code.

How should my browserconfig look like?

Read your Google Analytics stats (or whatever tool you are using) to get an impression of what browsers your users are using, then use the browerlist docs to compose your configuration.

If you don't use Google Analytics then a good default can be to support all browsers with a market share of 0.25% or higher like this:

>0.25%

Using "last 2 versions" is not recommended.

You can get a list of all browsers supported by your browserlist config by running following command

npx browserslist

It will list all browsers in the console.

Next step is to learn how to configure webpack

As I mentioned earlier, the most common way to use Babel is with webpack. So now that you know how babel works, a natural next step is to start looking into webpack.

I have created an email course that gives you one email per day that will only take a few minutes to read. After five days you have learned how to build a complete production ready webpack app. Get access today by signing up. It's free!

→→Free webpack email course ←←

How to build a large React application

Jakob Lind — Fri, 01 Sep 2017 05:24:08 +0000

You have a vision for your next big application. It’s a SPA with many routes. It should handle authentication and registration. A nice UI with animations. And it should communicate with external and internal APIs.

Then you think to yourself: Where do I start? Is there a tutorial I can use that describes how to code this app?

It’s difficult to find such extensive tutorial. Even if you find a tutorial which shows you how to build a large app, it’s unlikely it will teach you to build an app that is exactly like yours.

You need a process to build it yourself.

Break it down to tasks

To succeed building your large application, you must take control over it. The way you do that is by breaking it down into smaller and more manageable tasks. This is an example:

Create a “hello world react app
Add forms
Add a /dashboard page
Add a backend for handling API requests
Where to persist data, DB or SaaS such as Firebase?
Where to host the app?

You don’t need to do this perfectly. Don’t spend too much time on this exercise, 10 min max. The reason is not to create “todos for everything, but to realize your app is not a big monster. It consists of small tasks that are completely possible to finish.

You will be able to code some of the tasks without learning anything new. And some of the tasks will require researching to learn how to solve it.

Some of the tasks might be questions that you need to answer, for example, “where to persist data?”. You don’t need to answer all those questions in advance. You will answer them when you decide to implement the task. You don’t want to overwhelm yourself by doing all research upfront.

Keep it simple

When you pick a task to start work on you only have to solve a small well-defined task. If you don’t know how to solve it, you have to do some googling. Most likely you are going to find a lot of different solutions and many opinions on how to resolve the task. It’s easy to spend hours reading blog post after blog post even about minor details. Time quickly gets wasted.

To keep your focus and not be overwhelmed you must use a guiding principle: “what is the most simple thing I can do?”

It is so important that I am going to repeat it for you:

Your guiding principle when solving tasks is “what is the most simple thing I can do?”

It is so easy to get distracted away from this. There are so many smart solutions out there. But those smart solutions are not that smart when they distract you from reaching your goal.

You will require more advanced solutions when you need to scale up the code base. But not now.

This approach to software development applies both for hobby projects and most production applications.

Don’t overthink

You might read about Presentational/Container pattern, Higher order components, and other best practices. You start to lay out your architecture and you want to take the patterns into consideration.

Stop.

Learning best practices and setting an architecture at the same time will almost guarantee you to get stuck.

Your approach should be different: Only add stuff when you have felt the pain of not having it.

With the stuff I mean:

Best practices
Libraries
Programming patterns

When your application grows you need to continuously revisit your code and think about how you can improve it. When you feel pain, improve your code base and reduce technical debt.

But am I ready for X?

If you are new to the React ecosystem you might have gotten the advice to start with React, and only move over to Redux when you are ready. But how do you know when you are ready? And how do you know when you are ready for other “advanced technology such as routing, authentication, Ajax calls, etc?

If you are using the approach “start small, and only add tech when you feel the pain you don’t have to think about if you are ready or not. If you feel the pain, you know what kind of library/tool you need. And if you start small and simple, you will not get overwhelmed.

Stop thinking about you and think about the app you are building.

Conclusion

When you want to build a large application there are many things that can overwhelm you. Your own application can overwhelm you, and the React ecosystem can overwhelm you.

That’s why it’s important to have a process to take back control. To make it manageable you have to make it simple.

4 questions to ask yourself when you get stuck

Jakob Lind — Tue, 04 Jul 2017 11:03:12 +0000

Hi, I wrote this article with React developers in mind, but it applies to all kinds of languages and libraries! Enjoy!

Take a look at these common questions and answers:

Q: Where should I put my state?
A: 2 options for putting it in React components. Or use Redux. Or Mobx. Or…

Q: Where should I put my logic?
A: Container components or actions creators or util libs or…

Q: How should I do testing?
A: You have 5 options for assertions, 4 for stubs, 3 for spies, 4 test runners…

See the pattern? For every problem you have a list of several idiomatic ways to solve the problem.

Which solution should you pick? Ideally you want just the one idiomatic way to solve your problem, but instead you get a long list of options without guidance on when to choose which one.

So you get confused. And then you get stuck.

And sometimes there doesn’t even exist an idiomatic way to solve the problems you are having. Even though they are common problems.

“What file structure should I use? Do what you want.
“What is the minimum set of tools I need? It depends…

That doesn’t help either…

All we want is one clear and simple by-the-book solution. But in the React ecosystem there isn’t one, so what should we do?

Give up?

The question you ask yourself is important

So when you run into a problem you ask yourself the question “What’s the most correct/idiomatic way to solve this problem?“.

That question can many times help you solve the problem you have, or lead you in the right direction. But it can also be leading to more confusion than clarity.

"Judge a man by his questions rather than by his answers." – Voltaire

The real world is complex, and finding a suitable solution requires that you look at the problem from more than one angle.

The way you do that is asking many kinds of questions. Here are some examples:

1. “What’s the simplest thing I can do?”

Sometimes it is necessary to create Redux Store and Actions with Thunk Middleware to do Ajax requests.

And sometimes a 4 line HTML form tag is enough.

Don’t always reach for the “correct and fancy solution, but pause and reflect on what is the simplest thing you can implement to solve your problem. A simple solution is more maintainable, less risk for bugs, and usually most elegant. And also quickest to implement.

2. “What kind of problem am I trying to solve?”

Performance problem?
A feature where time to market is critical?
Is it a proof of concept?
Internal tool?
For learning?

If learning is the goal, you might want to write two or three different implementations of the same feature just to explore and compare. If time to market is important, you might go for the quickest implementation, even if it’s “wrong”.

3. “What level of competency does my teammates have?”

Many juniors? Seniors only? If you will recruit more devs, what are their profile? These are the really important question to take into consideration because it says something about the level of “smartness and room for creativity you will allow the codebase to have.

4. “Can I make a decision now, and revisit later?”

There are circumstances where the best thing to do is make a good enough solution, and revisit it later. If you think you are going to make it perfect on the first try, there is a risk you over engineer and as a consequence make the code more complicated than it has to be.

You don’t yet know how the code base will develop. Maybe that piece of code wouldn’t grow as big as you thought. And maybe the feature gets removed from the product completely in a month. (has happened to me many times)

Use this question with caution! You don’t want to throw in a lot of quick fixes all over the place. There is a balance.

Conclusion

Every application is unique, and going for generalized solutions is not always the best approach. To find the best solution for the problems in your application requires you to think further than the official documentation and tutorials.

Now you have a tool which takes into consideration many variables to find specialized solutions which will lead to more readable and more maintainable code.

And hopefully in the end more happy end users!

How to become a more productive React Developer

Jakob Lind — Mon, 26 Jun 2017 06:04:25 +0000

Developing complex React applications is… well, complex. You need to keep many things in your head at the same time, and it’s super easy to get distracted and lose focus.

There are powerful tools to help you stay in the flow, and make you more productive. In this post, I have gathered the “must-haves”.

Automatic code formatter: prettier

Prettier is an opinionated code formatter for JavaScript. You don’t need to think about indenting the code and adding new lines at the correct places – prettier does it automatically for you.
Before prettier to the left, and after to the right

“But wait a minute, my IDE already does that?”

Yes, but prettier works fundamentally different: It parses the JavaScript into an Abstract Syntax Tree (AST) and pretty prints the AST, completely ignoring the original formatting. This makes it much “smarter” and consistently produces a better result.

Prettier has excellent support for React and the official recommendation from Facebook is to use it.

You can get started without doing any configuration. You can play around with it yourself to see how it works here: https://prettier.github.io/prettier/

I suggest adding a keybinding in your editor for easy access when developing. There are plugins for most popular editors.

Errors and warnings in the editor: eslint

Eslint is a linting utility for Javascript. You can use it to show errors and warnings straight in your editor and it can even fix those errors/warnings automatically. You can configure it from scratch or use an existing config and tweak it. Many people like to start with the airbnb eslint config.

Eslint in Emacs: warnings in yellow underline and errors with red.

Eslint works perfectly fine together with prettier and there are editor plugins for most popular editors.

DevTools for React/Redux as Browser plugins

There are developer plugins for both Chrome and Firefox:

It adds itself as a new tab in the “inspect element” area that you most likely are very familiar with:

From there you can inspect all your components visually and for each component you can see the props and state. Very convenient!

Both React and Redux devtools are a must haves if you are a React/Redux developer.

So what can you do with them? I use them for mainly two things: debugging and inspecting data.

How to debug with Devtools

Let’s say you have written a Redux Action/Reducer and you have connect() the React component to the store. You expect something to change in your component when you click a button. Your bug is that nothing happens when you click the button.

A way to debug this is to follow the Redux flow with the devtools in your browser:

The first thing to check is if the action is dispatched from the action creator or not. You can see exactly what actions are dispatched in the Redux devtools.
If the action is dispatched correctly next step is to check if the reducer updates the state correctly. Again check the diff of the state in the Redux devtools.
If the state was updated correctly we move on to check if the React component receives the data in it’s props. This info is available in the React devtool.

You no longer need to throw console.logs around to understand what is happening. Instead you follow the flow of data in the browser with the devtools!

Inspecting data

Another great use case for the devtools is when you need to check how the data structure looks like in the props and the state of your components. An example is the following component:

class Person extends React.Component {
  render() {
    return (
      <div>
        <p>Name is {this.props.person.name}</p>
        <p>Age is {this.props.person.age}</p>
      </div>
    );
  }
}

Let’s say you need to display more information about the person. Then you need to know how the data structure this.props.person looks like. How will you do that?

Easy, Take a look at real data in the devtools.

We can see that it also has city and occupation we can use!

React Hot Loader

React Hot Loader (RHL) does live reloading of your code. That means that when you have saved after edited your code, your browser will automatically get the new changes without you having to manually reload. And the best part is that you will not loose your Redux state like you do when you do a manual refresh of the web page.

I want to admit that RHL is not perfect. Sometimes it cannot do the hot reload and you have to do a manual reload anyway.

What can I do with it?

In addition to use it for coding client side JavaScript, CSS is a great use case (requires that you have CSS in JS). When working with CSS it is often a lot back and forth adjusting pixels and colors. Many people do the tweaking in the developer tools in the browser. The only downside with that strategy is you have to replicate your changes to your code if you are happy with your changes. And if you do many changes, it can be a bit tricky to get everything correctly.

When using RHL, you can do the editing of your CSS straight in your own code and still get the live changes in the browser. When you are done you don’t have to do anything more than commit your code to git!

Conclusion

There are many great tools and technology out there that remove distractions and automate repetitive tasks so you can focus on delivering value. Use them! It will significantly speed up your development speed!