After one year of absence in 2020, the React Conf 2021 has returned as an online event. Packed with many exciting talks and is free for everyone. It didn’t come as a surprise that speakers were talking about the upcoming React 18 release and its features most of the time. I watched the whole event (over 5 hours), and I’d like to share the key takeaways.

React Hooks were introduced in React version 16.8. Hooks are functions that let you "hook into" the React state and lifecycle features straight from function components. There are many benefits of using react hooks. With help of React Hooks we can use React without classes. It allows us to write more readable, cleaner code with less lines of code.

React by Example as a book is focused on 12 different examples of UI widgets. Every chapter is a walkthrough on implementing such component, whether it’s a password strength meter or article list with voting. Each one has accompanying Git code repository which enables you to peek into individual commits and take the example further.

At the moment of writing initial version of the book the freshest version of React was 0.13.3. Fast-forward and we’re on 16.0.

How did we manage to update the code and what helped us in the process? Read on!

As a Rails developer, I learned a lot just from reading Ruby on Rails code. Aware of that experience, I try to look into the internals of other open source projects as well, to see what’s going on there.

It has two primary benefits:

• You will most likely better understand the project, its API and learn a few programming tricks.
• It demystifies the library or framework that you use.

We often put some open source libraries or frameworks on a pedestal and think that we, mere mortals, cannot produce such code. That it is beyond our level of skills. Reading the code of libraries, that you use, can teach you that many (not always all) parts of their code are approachable and possible to understand. That’s a first step to contribute or start your own project. Feeling empowered that you can. And that you would be useful to the team.

For many React developers using JSX it is not clear how to make a dynamic JSX tag. Meaning that instead of hardcoding whether it is input or textarea or div or span (or anything else) we would like to keep it in a variable.

Let’s have a look.

I (and I am pretty sure you as well) sometimes get the feeling that there is too much boilerplate when it comes to implementing forms with React and Redux. Connecting actions, validations, state updates and rendering for a simple form can be a tedious job. I know there are people working on good wrappers but I am not sure we are there yet.

I hope that over time we will get better abstractions that will remove this boilerplate for simplest situations. And we will only need to focus on more complex or unusual interactions which differ from the default of “update of this input means update of that property in the state”.

In the meantime I wanted to present (perhaps obvious) techniques that can reduce the amount of code.

State. One of the most complicated concepts in React.js nomenclature. While some of us already got rid of it in our projects (Redux anyone?) by externalizing state, it is still widely used feature of React.js.

While convenient, it can cause some issues. Robert Pankowecki, one of Rails meets React.js authors had the problem with validations when he started his journey with React.

The story went like this: Validations seem to be quite easy to do, but there is a problem of vanilla form - first time user sees the input it should not get validated, even if it’s invalid to have this input empty. This is definitely a stateful behaviour - so Robert concluded it’ll be good to put his validation messages in state.

So basically he just went and implemented the logic like this:

// ...
changeTitle: function changeTitle (event) {
 this.setState({ title: event.target.value });
 this.validateTitle();
},
validateTitle: function validateTitle () {
 if(this.title.length === 0) {
 this.setState({ titleError: "Title can't be blank" });
 }
},
// ...

Bam. This code doesn’t work. Why is so? This is because setState works in an asynchronous way. That means after calling setState the this.state variable is not immediately changed. This is described in docs under “Notes” section:

setState() does not immediately mutate this.state but creates 
a pending state transition. 
Accessing this.state after calling this method can potentially 
return the existing value.

So it is rather a misunderstanding or lack of knowledge than something really weird. Robert could avoid his problem by reading the docs. But you can agree that it’s a rather easy mistake to make for a beginner!

This situation has triggered some interesting discussions internally in the team. What can you expect from setState? What guarantees you have? Why can you be sure that state will get updated correctly if you change the input and press “Submit” immediately? To understand what’s going on and to make an interesting journey into React internals I’ve decided to trace what happens under the hood if you call setState. But first, let’s solve the problem Robert had in an appropriate way.

Sometimes your React components are wrappers for external components. And those external components APIs might not be declarative. Instead, they provide you with a set of imperative APIs that you can use to change their state. What can you do in such situation?

Once we started using React in our projects, our productivity went up. We were able to deliver complex view with many moving parts in a fraction of a time we would need before with other technologies.

Our application grew with time and some of our applications got really complex views. In some point, it was really inconvenient to pass down some common data in large component trees. It wasn’t a no-go, but a bit tiring.

One of the most promising ways to advance your skills in the language is to read the code of mid-sized or large-sized project. And React.js codebase is a great project to start with. It is written by competent JavaScript developers, well-tested and not foreign in a sense that it incorporates patterns native for JavaScript only.

In this article I want to highlight one brilliant pattern called Transactions in React.js. It has many possible applications (like most design patterns do) - from keeping invariants to managing cross-cutting concerns. Also an implementation is very simple and I’d like to dissect it. I’ll also tell you how it is used in React codebase.

Modularisation system is a part of every modern language that is used for creating complex applications. JavaScript is special here - modularisation system is not a part of language itself. We got great standards (CommonJS or AMD) and tools to make modularisation work. One of the most popular is Webpack - a module bundler which comes with variety of so-called loaders, transforming the input code.

Unfortunately modularisation systems not within the language creates compatibility problems. There are libraries that can’t understand modules and assumes that dependencies are available globally under predefined names.

I had this issue today. I wanted to use the great Chosen library for multi-select inputs. Unfortunately Chosen expects to have jQuery defined in the global namespace and is unaware of modules at all. In this article I’d like to show you how to integrate such module-unaware libraries with Webpack without introducing global variables.

Not so long ago, React 0.14 was released. You can read the full guide on the facebook’s github, but it’s very long and detailed. If you want TL;DR, in addition with an example, read this article.

I will do Warning Driven Development on this public gist.

React attacks us with the virtual DOM right away, on the main page. This feature seems to be very important!

But what does “virtual DOM” mean exactly?

React.js has a tremendous amount of interest in communities interested in frontend development techniques. Those communities vary when it comes to average skill and knowledge about programming. It is not bad - the same situation is visible in Rails-centered communities (from where I’ve arrived) too.

That means there are many approaches to understand and use React.js ideas in practice. Certain patterns arise - most of them are cool, but there are also common mistakes made by developers trying to use React.js in their projects.

I want to speak about one of such common mistakes. It is a problem of unneeded state. In this blogpost I’d like to show you why it is bad and how to detect and avoid it in your React components.

I recently stumbled upon an interesting problem. React.js was loosing focus on an input while the user was typing.

We, the Arkency team, are glad to announce that our last child - “React.js by example” book, has been officially released! It is currently in version 1.0.

If you don’t know the book - this is a set of 12 easy-to-medium web widgets written in React.js using ES6 and JSX, explained in step-by-step manner. You can check out these widgets here.

One of the reasons why we love React is its declarativeness. Instead of thinking how to change things, you simply declare how it should look like, and React does the dirty job for you.

However, as your application grows, it might be hard to keep up with the data flow. Especially when it has a complex structure: many layers, nested components and things like that. The state of your components is internal. The more complicated structure you app has, the more props- and callbacks-passings you need to keep your components up-to-date. It starts to feel like we lose this freedom that declarativeness gave us.

React.js is not only a technology for creating dynamic user interfaces. Sure, it is unopinionated about how you structure the rest of your frontend application. But it does not mean that there are no ideas or guidelines that can help you with creating other parts of your app.

There are many ideas and technologies that align well with React.js. One of those (more general) ideas is data immutability. It comes from the functional programming world - and applied to the design of your frontend app can have many benefits.

When designing your web application, you would like the user to confirm some actions sometimes. For example, you may want the user to confirm deletion of his data. There is window.confirm JavaScript method that might be useful in this case but it could not be styled and just displays native browser’s dialog window. In this article I would like to show you how to create React component as a replacement for window.confirm that can have similar behaviour and your application’s look & feel. It has similar API to window.confirm so migration should be really easy.

A lot of developers coming to JavaScript world attracted by React.js are confused with the tooling used to produce modern JavaScript code. Webpack, Babel, ESLint, Mocha, Karma, Grunt… what should I use and which tool is doing what? JavaScript newcomers are often people coming from communities like Ruby and Java where opinionated, full-stack solutions exist. Frameworks like Ruby on Rails provide a lot of features out of the box - in fact the problem you may have with JavaScript is caused by that. You do not think about the building tools for your code - your template language processors, asset pipeline, cache middleware and a lot other things are pre-configured for you and they work transparently.

JavaScript tooling often consists of small tools, utilities and libraries that combined builds your code to be used in a browser. They allow you to rebuild your project after changes, run your test suite, hot reload your code and so on. You may be lost in this world - I was lost when I first tried to build my JavaScript stack for working with ES2015 code.

In fact this is a problem that you wish to have - system composed of small parts is much more maintainable and flexible than a big monolith that popular framework provides to you. But starting with such granular tooling can be hard.

I’d like to give you a quick overview about what popular tools do - and whether you need them or not.

This is insane, so many companies are adopting React.js every day. Some people say it’s all about hype. We checked which big companies and brands are using React and why they decided to go for it.

React v0.13 introduced a major change in how you can define your component classes. What was a React-bound class system was slimmed down to a level where the pure JavaScript classes can be used. It has many benefits - your component classes are not ‘magical’ anymore, you can take advantage of the common JavaScript idioms and so on.

This change emphasized that React is JavaScript - and React authors don’t want to escape this truth. That change encourages you to use language features, not custom solutions to create your React code. For people coming from different background than JavaScript / Node.js using some language features can be confusing.

One of those confusing features is function context binding in JavaScript. In this blogpost I want to explain how and why you need to do it.

There are a lot of ways people acquire their skill. World of JavaScript tools is a bit unstable - new frameworks and libraries come and go in matter of days. We need to learn new technologies quite often. Software development is about learning through entire career.

The thing is - there is no silver bullet when it comes to education.

There are three different ways to define your React components. With v0.13 version of React, the dev team took a great effort to enable using pure JavaScript classes available in the new ECMAScript 2015 standard. Using such classes allow you to write more idiomatic JavaScript. It also introduces less magic than the old React.createClass syntax. Each of these approaches have the slight differences and consequences when using them.

In this blogpost I want to show you examples of component classes written using React.createClass, pure ECMAScript 2015 classes and ECMAScript 2015 classes with the experimental class properties feature. This will allow you to choose wisely between those three depending on your project needs.

Programming interactive user interfaces using JavaScript might be a tough task. User calls some action and we need to update his view - manipulating DOM using tool like jQuery. It just doesn’t feel good enough to modify document’s elements by hand. It is also really hard to re-use already written parts of UI and compose them with each other.

Imagine if there was one tool, that would solve all these problems and help you deliver your front-end much faster. What if you didn’t have to worry about this whole DOM stuff when you just want to update the view?

How would you feel being as efficient as when developing your Rails backend, when it comes to user interface?

Here comes React.js!

Dynamic user interfaces began to be an important feature for today web applications. To maintain quality, they must be tested properly. There are variety of approaches - each has its pros and cons. As a React developer you may need to choose a proper approach to test your components in an effective way.

When Facebook announced React Native I was amused. It is my chance to start developing mobile applications. I already know React and I can write most of my code using it.

If you haven’t seen @Vjeux talking about React Native on React.js Conf, you should definitely check it out before.

I want to share my path in making simple application for iPhone. I believe that experience should be enough to start creating bigger apps.

React.js comes with a variety of tools and ideas behind it. There are many awesome tools that can work along with React really well. One of the most interesting ideas behind React is how the whole front-end application is structured.

Flux is an interesting approach to structurize front-end apps. It is a relatively simple idea, taking an inspiration from the CQRS architecture. It specifies how your data flows thorough the whole front-end stack. You may heard about it if you are interested in React.

There are lots of libraries which help with building an app with Flux architecture. It may be hard to choose one. They come in different flavors and ideals in mind. Asynchronicity support, immutability as a core, ability to be isomorphic, or more functional approaches are usual ‘ideals’ behind them. I personally was daunted when I tried to choose one.

But an idea is the most important part of the architecture. I would like to show you step-by-step how to create a simple application, backed by a Flux architecture. As a bonus, I’ll show you how to use Immutable.js to improve performance of your React components.