DEV Community: selbekk

Terminal illness

selbekk — Sun, 05 Jul 2020 11:22:27 +0000

You don't have to be a Linux hacker to use the terminal to be productive. Here's a few tips I've picked up the last couple of years that might make you even iller in the terminal.

Just a disclaimer - I'm no terminal professional. Yet, over the 7 last years, I've learned a few very nice-to-know techniques that you might not have heard of. There's no guarantee that you'll learn anything from this, but a pretty bit chunk of my readers might learn at least a thing or two.

A little side note here - these commands are meant for OSX only. They might work on Linux or WLS, but I haven't tried them out.

Use the clipboard!

Every once in a while, you have some data in the clipboard that you want to use somehow, or you want to copy the output of a command into the clipboard. Either way - it's very possible to do!

So there are two commands you need to know - pbcopy and pbpaste. You can use them together with the pipe operator | and the "to file" operator > to do really cool stuff.

Here's a few examples:

To paste whatever is in your clipboard into a new file - let's say .env - you can do this:

$ pbpaste > .env

No more creating a new file, then opening it in vim or VSCode to paste and save - now you can just type a few characters and get the job done!

Similarly, if you want to copy a file to the clipboard, you use the pipe operator and pbcopy. This is how it looks:

$ cat .env | pbcopy

cat echoes out the entire contents of a file (in this instance .env) and the pipe operator passes it as input to the pbcopy command. Voilá - now you can copy the content of entire files without opening them!

I use this all the time when I need to copy my ssh key and paste it into GitHub or BitBucket.

You don't have to limit yourself to files though - pbcopy is much more flexible than that. Whatever you pipe in can be placed on the clipboard - so if you want to copy the result of a program (let's say an encryption program or pwd), you just pipe it on in.

Doing more with `less`

I often use the tiny file reader program less to scan, search and read through files. It's really powerful if you know how to use it, but even if you're just using it for the first time, you can just use the arrow keys on your keyboard to scroll through files directly in the terminal.

Now, I use this mostly to read configuration files, and if I come across something I need to change, I've always had to close the file I was looking at, and open it in an editor like vim.

Luckily - you can just type v, and the default editor (typically vim) opens up, focused on the same line you were at. Once you close vim (provided you know how to close vim), you're placed back in the same spot as you were as well.

Also - you can go the start of the document with g, and to the end with shift+g. You can search for a phrase by tapping /, and typing out whatever you're looking for. Navigate through the occurrences by n (forward) and shift+n (backwards). And there's a ton of other things you can do (which you can read about here).

Open files and folders with open

Often times, you stumble across a file you want want to open the file's default application. That might be a video, an audio clip or perhaps a CSV file. You could exit the flow you're in, of course, and use Finder to navigate to your file and double click it - but we can do better.

If you want to open any file, you can use the open command to get it done from the terminal:

$ open videos/screen_recording.mp4
$ open package.json
$ open images/vacation.png

I usually don't open a lot of files this way, but I do open folders! Just use open on any folder, and you'll get started right away!

$ open ~/Documents
$ open . # opens the current folder

Some power characters!-

There are two really nice characters to know when using the terminal, and those two are - and !.

The - character (dash, hyphen, whatever you call it) works well in two contexts. You can add it to the cd command to return to the previous directory you were in, and you can add it to git checkout to check out the previous branch you were on.

# Example of using cd -
~/Documents $ cd /usr/bin
/usr/bin $ cd -
~/Documents $

# Example of using git checkout -
(master) $ git checkout feature-branch
(feature-branch) $ git checkout -
(master) $

The exclamation mark is also pretty neat - it lets you search the history of command you've done previously, or re-use the arguments to the last command you used.

$ !cat
$ # shows you the last command you ran that started with cat

$ less a.txt b.txt
$ vim !* # opens a.txt and b.txt in vim

$ less a.txt b.txt
$ vim !$ # opens b.txt in vim

It's a neat little trick that I know for some reason, but I never use. Perhaps you'll find some use for it though!

Much more usable, however is the double exclamation point! Especially in conjunction with the sudo command. If you've ever run a command and realized you had to run it as an administrator, you can simply do sudo !! and re-run it with sudo!

$ chmod +x /usr/share/firmlinks
chmod: Unable to change file mode on /usr/share/firmlinks: Operation not permitted
$ sudo !!
$ # Now it works!

Searching the command history

Speaking of command history - you don't really need the ! command when you know about the ctrl+r shortcut! Tap it once, and you'll be able to do an interactive autocomplete search of your entire command history!

Oh my...

Lastly, I want to talk about oh-my-zsh. Zsh (pronounced sea shell) is a popular alternative to the well known bash shell, and oh-my-zsh is a small framework that adds a ton of useful functionality, aliases and plugins to make your workflow as smooth as possible.

If you haven't installed it already, you can do so by visiting their home page. Next, pop up this cheat sheet and start learning. There's a ton of useful shortcuts for git (like gst for git status and gc for git commit), but also really nifty commands like ... for navigating two directories up or take deep/directory/tree for creating a new directory and navigating into it.

In addition, there are tons of great themes and plugins available to make your terminal super powerful. I've had oh-my-zsh installed for years, and I just love it more for every passing day.

Last words

These are some of my favorite tips for being productive in the terminal. There are tons of stuff I've skipped - like how to grep or exit vim - but to be honest I don't use those a lot either. I hope you found at least one new technique to add to your roster - and that you promise to share your favorite commands with your fellow readers in the comments section.

Forwarding refs in TypeScript

selbekk — Mon, 18 May 2020 08:23:41 +0000

Originally posted on my blog - selbekk.io

When you're working on a component library, or just creating reusable components in general, you often end up creating small wrapper components that only adds a css class or two. Some are more advanced, but you still need to be able to imperatively focus them.

This used to be a hard problem to solve back in the days. Since the ref prop is treated differently than others, and not passed on to the component itself, the community started adding custom props named innerRef or forwardedRef. To address this, React 16.3 introduced the React.forwardRef API.

The forwardRef API is pretty straight-forward. You wrap your component in a function call, with is passed props and the forwarded ref, and you're then supposed to return your component. Here's a simple example in JavaScript:

const Button = React.forwardRef(
  (props, forwardedRef) => (
    <button {...props} ref={forwardedRef} />
  )
);

You can then use this component like ref was a regular prop:

const buttonRef = React.useRef();
return (
  <Button ref={buttonRef}>
    A button
  </Button>
);

How to use forwardRef with TypeScript

I always screw this up, so I hope by writing this article I can help both you and me to figure this out.

The correct way to type a forwardRef-wrapped component is:

type Props = {};
const Button = React.forwardRef<HTMLButtonElement, Props>(
  (props, ref) => <button ref={ref} {...props} />
);

Or more generally:

const MyComponent = React.forwardRef<
  TheReferenceType, 
  ThePropsType
>((props, forwardedRef) => (
  <CustomComponentOrHtmlElement ref={forwardedRef} {...props} />
));

It was a bit un-intuitive at first, because it looks like you can pass a regular component to ForwardRef. However, regular components don't accept a second ref parameter, so the typing will fail.

I can't count how often I've done this mistake:

type Props = {};
const Button: React.RefForwardingComponent<
  HTMLButtonElement,
  Props
> = React.forwardRef(
  (props, ref) => <button ref={ref} {...props} />
);

This is a mistake, because the RefForwardingComponent is the type of the render function you create (the one that receives props and ref as arguments), and not the result of calling React.forwardRef.

In other words - remember to pass your type variables directly to React.forwardRef! It will automatically return the correct type for you.

Another gotcha is the order of the type variables - it's the ref type first, then the props type. It's kind of counter-intuitive to me, since the arguments to the render function is the opposite (props, ref) - so I just remember it's the opposite of what I'd guess. 😅

I hope this article helped you figure out this pesky typing issue that have gotten me so many times in a row. Thanks for reading!

Setting Up a Development Environment in Elm

selbekk — Sun, 16 Feb 2020 11:45:09 +0000

As I was building out yet another Elm test project, I wanted to add some CSS to my app. I added a styles.css file to my source folder, and soon realized I had nowhere to include it! I've always been running elm reactor up until this point, but that doesn't give me access to any styles whatsoever.

After looking in the docs, I found I could use elm make to create a default HTML file for me, but that meant that I had to build my project on every change to iterate on my application. Surely, there's a better approach out there?

Turns out, the options weren't documented very well, but they're definitely out there! This article will show you a few different ways you can set up a development environment for a real world application, complete with hot reloading and all.

Getting started: Hello again, NPM

The first thing you'll need to do, is to run npm init (alternatively yarn init) to bootstrap a package.json file. I thought I wouldn't have to use a JavaScript package manager for Elm apps, but in order to set up a development environment, you definitely need to.

In any real world application, you'll probably need some JavaScript libraries at some point, too, so don't feel bad about adding it. You'll still be writing Elm most of the time!

The naïve approach - automation!

The simplest approach I could come up with is to set up a file watcher that runs elm make --output public/app.js on every change in my Elm files. I went with watch, an npm package, and added the following to my package.json:

{
  "scripts": {
    "start": 
      "watch \"elm make src/Main.elm --output=public/app.js\" src/**/*.elm"
  } 
}

Now, I can create an index.html file in the public/ directory, and add my CSS file next to it. When I'm done, my file structure will look something like this:

src
 - Main.elm
 - OtherFiles.elm
public
 - index.html
 - styles.css
 - app.js
package.json
elm.json

The index.html file is super basic, and will look like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>My Elm app</title>
    <link href="./styles.css" rel="stylesheet" />
  </head>
  <body>
    <div id="root"></div>
    <script src="app.js"></script>
    <script>
      Elm.Main.init({
        node: document.getElementById("root")
      });
    </script>
  </body>
</html>

Now, I can open the public/ folder with i.e. serve, and iterate on my app like it ain't no thing.

The Elm approach: `elm-live`

Even if the above approach technically works, it feels like I've built something with toothpicks and band-aids. Surely, there's something a bit more put together?

Luckily, there is. elm-live is the all-Elm alternative that provides us with iterative builds, hot module reloading and a ton of other features.

To get started, install it with npm or yarn:

npm install elm-live
yarn add elm-live

Next, we need to add a script to our package.json file:

{
  "scripts": {
    "start": 
      "elm-live src/Main.elm --hot --start-page=public/custom.html -- --output=public/app.js"
  } 
}

And that's it! Start your script, and a hot-reloading dev server will pop up and instantly improve your developer experience.

My favorite approach: Parcel

Although the elm-live approach is nice and all, we still need to have a bunch of manually edited stuff inside of our public/ folder. Wouldn't it be nice if some build tool figured all of this out for us?

Meet Parcel. Parcel is a bundler for web apps, which happens to support Elm out of the box. In addition, it works with JavaScript, CSS and other resources as well, which will help us a lot down the road. Let's give it a try!

First off, let's install it with your package manager of choice.

npm install parcel-bundler
yarn add parcel-bundler

Next, move your hand-crafted public/styles.css and public/index.html into your src folder. They're source code, after all! We'll create an additional file, index.js, which will look like this:

import { Elm } from './Main.elm';
import './styles.css';

Elm.Main.init({
  node: document.getElementById('root')
})

This lets us remove the inline script tag from our HTML file, as well as the <link /> CSS tag.

Finally, let's add the script to our start tag:

{
  "scripts": {
    "start": "parcel src/index.html"
  } 
}

There's nothing more to it. Run your script, and you'll notice a hot-reloading dev server pop up for you, just like you'd expect. This will even include an Elm debugger tool as well 😎

A nice bonus feature with Parcel, is that you'll be able to add styles processing and JavaScript transpilation in no time at all. That's nice to know!

That's it!

Turns out, setting up a nice developer experience isn't a lot of work, once you know what to do. I hope this article can help future beginners like myself looking for the best way to get started.

Please let me know how you set up your dev environment in the comments!

Dad jokes and HTTP requests in Elm

selbekk — Thu, 02 Jan 2020 23:18:24 +0000

What does the Elm developer say when asked to go out to party? Maybe. Oh yes. Welcome to the shit show that is my dad joke game 😎

After creating both a counter and a todo app in Elm, I'm ready to go for the big leagues. Create that real business value. Satisfy the client needs in a functional fashion. So I decided to create dad joke generator via the fantastic and free Dad Joke API!

Even though the feature might be laughable (hah! 😄), it's no joke to implement - at least not for me. We'll have to do HTTP calls, set the correct headers, and deal with something called commands.

In this article, I'm going to take you through what I did step by step, and try to explain the new concepts I encounter.

Creating a good model

I like starting with modeling the state of our application. In this case, we have three possible states - waiting for data, having failed to fetch the data, and successfully fetching the data. We can model that with a regular type:


type Model
    = Failure
    | Loading
    | Success String

I guess we could've created an Idle state as well, but we're going to fetch a joke initially anyhow, so it won't be a need for that. Speaking of...

Initializing with commands

The next thing we want to do is intializing our application. It'll be a bit different than we've done previously - instead of just being the initial model, it'll now be a function that returns something called a tuple.

The type signature looks like this:

init : () -> (Model, Cmd Msg)

There's a few new things here. First, what's a tuple? In this case, you can think of it as way to return several values from a function. It's a bit more complex than that, but you can think of them as a very light weight data structure of sorts.

In our case though, we're just returning two things - our initial model, and an initial Cmd. But what is a Cmd?

A Cmd (or command) is something you want Elm's runtime to do for you. It can be a lot of things, like creating random numbers or accessing browser APIs. Or doing HTTP calls. Once it's resolved somehow, it will return a Msg, which our update function will deal with.

If you're coming from a React background, you can think of this Cmd argument to our init function as an action you'd want to run on mount. Kind of like componentDidMount or useEffect(fn, []) works!

So let's write our initializer!

init : () -> (Model, Cmd Msg)
init _ =
    ( Loading
    , Http.get 
        { url = "https://icanhazdadjoke.com"
        , expect = Http.expectString GotJoke 
        }
    )

We return a tuple with our initial model - Loading, and a call to the Http.get function.

To get this to compile, you need to install the elm/http package with elm install elm/http in your terminal, and then imported in your file with import Http.

The Http.get function accepts a record with two parameters - the url, and something called expect. This last one uses another function - Http.expectString, which tells Elm to parse the response as a string, and then "dispatch" the GotJoke message with the result.

But - we haven't specified our messages yet - let's do that next.

Messages and results

For now, we only have one possible message to send in our app - namely the "we received a response from the server" value.

That "we received a response from the server" is wrapped in a Result type, which can either be an error or the successfully parsed response. We can specify that like so:

type Msg = 
    GotJoke (Result Http.Error String)

Now, I'm no functional programming nut, but if I've understood the introductory blog posts correctly, Result is what's known as a monad. 😱 Now, after the obligatory panic attacks, I realized monads a just containers for a value that adds some functions for you to use. However, if you're new to functional programming, just close your eyes to the monad part, and just think of Result as a type that's either Ok or Err.

Implementing the update function

The update function is a bit different this time around as well. The type signature looks like this:

update : Msg -> Model -> (Model, Cmd Msg)

Like before, the update function receives the message and the initial model, but now it's returning a tuple - two values - (Model, Cmd Msg). This feature lets a message trigger a command, if we want to.

Let's implement it:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg _ =
    case msg of
        GotJoke result ->
            case result of
                Ok joke ->
                    ( Success joke, Cmd.none )

                Err _ ->
                    ( Failure, Cmd.none )

Here, we pattern match the message - even though we just have a single message. By doing it this way, we'll be able to add features without refactoring too much later.

Inside of the GotJoke match, we're doing another pattern matching case to handle the two different cases of the Result type - an Ok type with the parsed result, and an Err type with the error (which we ignore).

Both the Ok and the Err types return a tuple with the Msg as the first item, and then Cmd.none as the second. Cmd.none indicates that we don't want to trigger a new command as a result of this message. This makes sense in our case - because if we got a result, we're done, and if the API call failed, there's no need to try again immediately.

Implementing a view

I'm a front end programmer after all, so the coolest part for me is always going to be implementing the view. Here's what I put together:

view : Model -> Html Msg
view model =
    div [ A.style "text-align" "center" ]
        [ h1 [] [ text "Elm dad jokes 😎" ]
        , case model of
            Loading ->
                p [] [ text "Loading..." ]

            Failure ->
                p [ A.style "color" "red" ] [ text "Ouch, something went wrong while fetching the stuff over the network" ]

            Success theText ->
                pre [] [ text theText ]
        ]

Here, I create a containing <div />, a heading, and then pattern match our model to create three distinct views based on which state we're in.

Namespacing attributes

Notice the A. in A.style? Previously, I imported all of the possible attributes into the global namespace with import Html.Attributes exposing (..). That turned out to be a bit polluting to my taste. In this app, I'm namespacing them with A, by changing my import to import Html.Attributes as A. This way, I don't pollute the global namespace as much, while still keeping the attribute names short when I need to use them.

Putting it all together

We've forgotten one step - calling the Browser.sandbox function. This time, however, since we're introducing commands into the mix, we need to call a different function - Browser.element. It looks pretty similar, but requires another function - subscriptions. We're not going to bother with subscriptions this time around, so let's just say we don't have any:

subscriptions : Model -> Sub Msg
subscriptions model =
    Sub.none

Now, we got all the pieces to call Browser.element:

main =
    Browser.element
        { init = init
        , update = update
        , subscriptions = subscriptions
        , view = view
        }

That should be it! Let's run our app to get some laughs:

Argh - I must've missed something - I'm not getting the joke, I'm getting the entire HTML page! This is ridiculous, and not in the way I wanted it to be!

After reading the API docs, you have to specify the Accept: text/plain HTTP header to only get the text. But how do I do that?

Try 2 - `Http.request`

The original Http.get function I called earlier didn't support sending headers, but after heading (hah 😄) over to the very nice documentation for the elm/http package, I came across another function that provided more flexibility - the request function.

After a bit of trial and error, I ended up with changing my init function to this:

init : () -> ( Model, Cmd Msg )
init _ =
    ( Loading
    , Http.request
        { method = "GET"
        , body = Http.emptyBody
        , headers = [ Http.header "Accept" "text/plain" ]
        , url = "https://icanhazdadjoke.com"
        , expect = Http.expectString GotJoke
        , timeout = Nothing
        , tracker = Nothing
        }
    )

A few more lines of code, but still pretty manageable. After refreshing my page, I got what I had been hoping for:

Great success!

Fetching more jokes!

Even though that joke truly is a classic, I soon wanted more. So the next feature I wanted to implement was adding a "get a new joke" button! Let's go through the steps I needed to add this new feature.

First, I added a new type to the Msg type:

type Msg
    = GotJoke (Result Http.Error String)
    | RequestNewJoke

Now my update function is broken, since I no longer handle all cases. Let's fix that:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg _ =
    case msg of
        GotJoke result ->
            case result of
                Ok text ->
                    ( Success text, Cmd.none )

                Err _ ->
                    ( Failure, Cmd.none )

        RequestNewJoke ->
            ( Loading, fetchDadJoke )

If we receive a RequestNewJoke message, we set the state to Loading, and trigger the command fetchDadJoke. But where does that last part come from?

The fetchDadJoke command is refactored out from our init function, and is the code that calls the API:

fetchDadJoke : Cmd Msg
fetchDadJoke =
    Http.request
        { method = "GET"
        , body = Http.emptyBody
        , headers = [ Http.header "Accept" "text/plain" ]
        , url = "https://icanhazdadjoke.com"
        , expect = Http.expectString GotJoke
        , timeout = Nothing
        , tracker = Nothing
        }

init : () -> ( Model, Cmd Msg )
init _ =
    ( Loading
    , fetchDadJoke
    )

Neat, right? I guess I could've refactored out the entire tuple, but it looks pretty nice as is, too.

Finally, we just need to add some buttons to our UI. I decided to add a retry button in case of errors, as well:

view : Model -> Html Msg
view model =
    div [ A.style "text-align" "center" ]
        [ h1 [] [ text "Elm dad jokes 😎" ]
        , case model of
            Loading ->
                p [] [ text "Loading..." ]

            Failure ->
                div []
                    [ p [ A.style "color" "red" ]
                        [ text "Ouch, something went wrong while fetching the stuff over the network"
                        ]
                    , button [ Events.onClick RequestNewJoke, A.type_ "button" ]
                        [ text "Try again" ]
                    ]

            Success theText ->
                div []
                    [ pre [] [ text theText ]
                    , button [ Events.onClick RequestNewJoke, A.type_ "button" ]
                        [ text "Get another joke" ]
                    ]
        ]

And that's it, really! We now have "get a new joke" support as well.

Last thoughts and next moves

I learned a lot building this project, and I hope you did as well with following along. There's quite a few new concepts here, with Result and Cmd and what have you. However, it's coming together quite nicely.

This is the third app I've ever built in Elm, and the syntax is starting to finally feel... "right". I was very skeptical at first, but I think it's growing on me.

Handling HTTP requests was a breeze, but very few APIs just return simple text strings. So next, I want to integrate with a fully fledged JSON API, so I can try my hands on decoding and encoding JSON. I'm sure it'll be a hoot!

You can see the entire code for this app in this gist, and even try it out if you want.

After a bit of struggling, I even made a CodeSandbox of it:

Thanks for following along! If you find any bugs, or have any questions, please feel free to ask in the comments!

A Year of React - 2019 in Review

selbekk — Tue, 31 Dec 2019 08:59:13 +0000

Written in collaboration with Caroline Odden and Jonas Løchsen. This post was first published at blogg.bekk.no (in Norwegian), where we also publish weekly React summaries called <ForrigeUke />.

This was a great year for Greta, and a terrible year for Trump. But the real winner this year was React, and its amazing community of developers, advocates and regular ol' users.

There was a lot that happened in 2019. We've spent every Monday night giving you a short summary of all the big and small news stories in this community we all love and cherish. Some of those stories were a bit bigger than the others.

In this post, we'll go through the year, highlighting some of the biggest new features and news stories of 2019. To finish it off, we've also found the recordings from some of our favorite React conferences!

Hooks

After a few months of eager waiting, React 16.8 finally brought the feature we'd been waiting for - Hooks - to a stable release.

It was at ReactConf 2018 the React Core team let us know they were working on new functionality that was supposed to improve our React quality of life considerably. The proposal was named hooks, and gave us great tools to handle both state and side effects in function components.

If you didn't catch the initial talk, you can (and should!) see it here:

Oh, and here's the introductory blog post, too!

We also wrote a post about what we thought about hooks (in Norwegian), if you want to give that a shot. 🤘

React Native gets hooks, too!

The week after Hooks were launched for the web, React Native followed suit. The 0.59 version included full hooks support, and had all of React Native Twitter freaking out 🙌

// Detect dark theme var iframe = document.getElementById('tweet-1096463521896898562-47'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1096463521896898562&theme=dark" }

React Router 5

This was such a great release - completely without breaking changes! Well - almost. The only reason they had to bump their major version was the way they handled their dependencies in react-router-dom.

It might have been in violation with the rules of semantic versioning, but whatever 🤭 Here's the release blog post if you want to read more about it!

But it wasn't all screw-ups - this version brought React 16 compability, no more <StrictMode /> warnings, support for an array of paths, and lots more.

Create React App v3

The third major version of create-react-app came with a bunch of new cool stuff, including "rules of hooks" eslint support, TypeScript linting and absolute imports.

You can read the complete changelog here.

Hot Reloading 2.0: Fast Refresh

Hot reloading is simultaneously the best and the worst feature of the React developer experience. It's just amazing to see your components update automatically on save, while keeping the component state. It lets us iterate quicker than on any other platform I know of! At the same time, it has a tendency to not work like half the time, and it can be a nightmare to get working in the first place.

Most of the reason the developer experience has been both good and bad is that it was a feature implemented in user land. To fix this, the React team has stepped up and implemented a much more stable implementation that works in both React and React Native.

// Detect dark theme var iframe = document.getElementById('tweet-1169687758849400832-851'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1169687758849400832&theme=dark" }

It's already available for React Native, and support for the web is just weeks away. If you're using Parcel, you can start using it in the newer alpha releases, and Webpack has an open pull request for adding support.

This means we'll probably get it in create-react-app as well! We're very excited.

React Router and Reach Router join forces

Routing is something most React apps use in some way, and lately there has been two major players out there. React Router has been the defacto choice for a long time, but ever since Gatsby started using the competitor Reach Router, we suddenly have a choice to make when it comes to routing. At least until next year.

On the Norwegian national day, May 17th, Reach Router king (and React Router founder) Ryan Florence proclaimed that the two libraries are merging into one!

You can read all the details here, but in short, we'll see more hooks, less libraries (Reach Router is being deprecated), and a common API moving forward. We've already noticed some of this work with the new hooks introduced in react-router@5.1.0, and we can't want to see what's in store.

Speaking of mergers - perhaps we'll see more of those moving forward? In the CSS-in-JS world, Styled Components and Emotion is starting to look veeery similar API-wise! 🤔

New DevTools

After teasing us throughout the year, Brian Vaughn was very proud when he finally revealed the completely rewritten version of React DevTools this August. This rewrite brought hooks support, improved performance for large applications and a much better user experience.

As far as we can tell from his Twitter account, however, Brian Vaughn isn't done implementing new features yet. Version 4.3 is already on its way!

React Gate

While most of the big names in React were hanging out at React Rally, a pretty nasty Twitter incident happened. What was later known as "React Gate" was a large, distributed argument about the more toxic and racist parts of our community. Racism and social exclusion were discussed in a very vocal and polarizing way, and a lot of people excused themselves from Twitter for an extended period of time. Ugh.

There are great recaps out there that summarizes the entire debacle, and we wrote about it in two of our blog posts.

The aftermath wasn't all bad though. On the contrary - some very actionable positive things came from it! The React team has increased their focus on including marginalized groups in tech, and implemented the Contributor Covenant Code of Conduct. Many of the people included in the React Gate episode has later taken on stronger roles in the community, trying to include good folks and shut down the trolls, racists and misogynists. That's what I call a happy ending.

// Detect dark theme var iframe = document.getElementById('tweet-1166364879852359681-974'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1166364879852359681&theme=dark" }

Concurrent Mode

The big event of this fall was ReactConf in Henderson, Nevada, and it was a really nice one. The biggest news was the introduction of Concurrent Mode - which is now available in the experimental release channel of React.

Please note, however, that it's still very much experimental, and not available in any stable release. If you're trying to dig into the APIs to be a bit in front when they are published, however, you should dig right in.

To quote the extensive documentation, Concurrent Mode is

a set of new features that help React apps stay responsive and gracefully adjust to the user’s device capabilities and network speed.

This sounds wonderful! The React team has provided us with an amazing developer experience as they have iterated on their product, but this feature is a bit different. It's about the end user experience - and making it as smooth as possible. We're really digging that direction!

Concurrent Mode opens up a new world of possibilities. As the name hints, it lets us render several things concurrently, and even pause rendering certain elements if a higher priority task comes along. All of this plays together to make your app seem as smooth as possible.

Harry Wolff has written an amazing summary on why Concurrent Mode is the bees knees, and explains himself with a bunch of great examples.

He even touches on whether you need to deal with Concurrent Mode. The answer is - as with most new and more advanced React features - no, but it's a huge win for your users if you do. It's a powerful tool that gives you the opportunity to control how your apps is handling asynchronous tasks and rendering your UI - if you have the time and resources, of course.

Suspense for data fetching

Since React 16.6, React's new Suspense feature has given you the opportunity to delay rendering of your components while you wait for parts of your application to load, and render a loader instead. With the aforementioned Concurrent Mode, we also get this feature for fetching data, images and basically whatever you want!

You can read all about in the docs (note - this is still experimental!)

As with anything that's new and shiny, it might be a bit hard to understand how it all fits together. Luckily for us, Maggie Appleton has made an amazing illustrated guide to both Suspense, how it works, and how to use it:

// Detect dark theme var iframe = document.getElementById('tweet-1206644383560478722-312'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1206644383560478722&theme=dark" }

Another way to understand what problem this new feature solves for us, we also suggest that you have a closer look at this Twitter thread from Dan Abramov. He identifies what the problems with today's solutions are, and pin points how Suspense comes in to save the day.

// Detect dark theme var iframe = document.getElementById('tweet-1193903570078306308-433'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1193903570078306308&theme=dark" }

Create React App gets templates

In December the 3.3.0 version of the offical React bootstrapping CLI create-react-app dropped, and it contained a few very cool features.

First of all, it now supports the concept of custom templates. That is, the files and dependencies that are included when you bootstrap a new project!

This is a great feature for products like CodeSandbox, since it gives them the opportunity to create much more flexible templates for their users. CodeSandbox even launched what they call their Template Universe, which promises to improve project startup times.

// Detect dark theme var iframe = document.getElementById('tweet-1202580698063941632-900'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1202580698063941632&theme=dark" }

The other great feature in this new Create React App version is the support for the two new language features in JavaScript - optional chaining and nullish coalescing operators.

In addition, react-testing-library is included by default. This wonderful library is a must-have for any project anyways, so I'm glad they decided to include it for all projects.

For a complete list of new features, we'd refer you to the changelog here.

Redux Style Guide

If you reading this, there's a high probability that you've touched Redux at one point or another. If you haven't - Redux used to be the must-have application state handling library for any new React app.

Redux has lost much of its glory in the last year, mostly due to improvements in React itself. Many people used Redux as their global store, but with the new Context API and introduction of hooks, solving that problem yourself became almost trivial. In addition, Redux introduced a lot of boiler plate in places where it didn't seem necessary.

That being said, Redux is still a great tool for complex applications, and - much more important - is probably a part of the tech stack of the legacy app you're stuck maintaining.

Since Redux probably isn't going anywhere in the foreseeable future - not from the React ecosystem, and not from your app - it's important to use it the best way possible. That's why Mark Erikson and his crew of maintainers has written a very detailed and useful list of recommendations on how you should do things "the Redux way". It includes a set of rules they've split into three sections - essentials, highly recommended, and optional.

Follow these, and you'll end up with smaller, simpler code with less bugs, and a simpler way to onboard new developers.

// Detect dark theme var iframe = document.getElementById('tweet-1197186583016955904-664'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1197186583016955904&theme=dark" }

Some of our favorite conferences

In addition to all the new features, libraries and news stories we've stumbled across the last couple of months, we've noticed there has been a ton of React related conferences! We've summarized both React Conf and JSConf (both in Norwegian), but here's a quick overview over all the biggest conferences related to React, and where you can find all the talks. There's no particular order here 🤷‍♂️

Speaking of conferences - you can find a very complete list of both conferences and meetups related to React on React's website!

ReactJS Girls Conf

There was a lot of butts hurt when am all-female speaker React conference was announced. What a silly thing to be pissed off about. The conference was amazing, with incredible talks, exciting speakers and supposedly a really nice experience for those that attended.