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
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.
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.
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:
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.
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.
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.
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.
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.
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.
The thing is - there is no silver bullet when it comes to education.
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.
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?
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.
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.