In this post we’ll run a few experiments to see how React’s renderer works and gain a understanding of some of its guaranteed (spoiler: I’ll use this word a lot 😅) behaviors.

First Experiment and Conventions

Every experiment consists of two elements: a graph and an events table:

Image for post
Image for post
Our experiment’s output: a graph and an events table.

Let’s start with our first experiment so you can get familiar with them.

We’ll start with simple component hierarchy consisting of a root component and two children components “A” and “B”:

Image for post
Image for post

When you run an application like this, the following events will happen in succession:

Image for post
Image for post

Note: This is a simple colored output from Firefox DevTools used to describe a sequence of events. A green “Rendered” means that a component is rendered (i.e: it’s function body is called) and a blue “useEffect” means that an effect inside a component was run. Every log is accompanied with a colored label to make it easier to follow along.

Image for post
Image for post

Persist React’s useState to localStorage is a common requirement. You’d want to persist user’s preferences or data to have them at hand on next sessions. However, there are some bugs that are hard to track when doing this. This article will present them and explain how to solve them in an efficient way.

Our Example

Let’s suppose that we add a new settings to allow users to enable dark mode in our website. Something like this:

Image for post
Image for post
Our new dark mode setting.

Internally, we’d keep an internal state using React’s useState to store the following:

  • title: label to display in the UI
  • name: to reference in the input field and to be able to retrieve our persisted state even if we update its title. …

Image for post
Image for post
Photo by Designecologist from Pexels

Slow and steady wins the race

You can become good in any given field if you give it enough time. It doesn’t require a lot of focused, undistracted hours per day to accomplish what you want and for sure you don’t need to stop doing the things that you like to do to start new ones. You can start a new business, book, hobby, whatever by applying the principles described in this article. All you require is to put a few focused minutes exclusively to a given activity towards a goal.

The Compound Effect

Small, Smart Choices + Consistency + Time = RADICAL…

Image for post
Image for post

Traditional business strategy is based on beat the competition by differentiation or pricing. This approach only allows to win a portion of the limited market space.

Blue Ocean Strategy proposes a different strategy called Value Innovation that focuses on offer both value and innovation, and thus, creating a leap in value for customers. When a leap is created, a new market space is created too. In this new market, it is possible to break the value-cost trade-off because you can offer both a good price and offer high value to customers.

Blue and Red Oceans

Image for post
Image for post

The previous information implies that new market spaces are very profitable. New market spaces are called “blue oceans”, and, on the other side, spaces highly competitive are called (bloody) red oceans. …

Mocking Apollo is such a useful feature that it’s misused. I suggest you to start using it as soon as possible since it has too many benefits that you will notice when using them.

I think this tweet that was the reason for this post summarizes it very nicely:

So, let’s go ahead with a working application showing how mocks works!

A working application can be found here if you want to skip the steps and see the final code:

Setting up our application 🚀

We will create our app using create-react-app:

npx create-react-app apollo-mocks-example
cd apollo-mocks-example

As the Apollo’s Get started page suggest, you need to add the following dependencies to start using Apollo with…

Image for post
Image for post
Photo by Goh Rhy Yan on Unsplash

Do you trust the objects that you create?
Do you write objects and call methods on them without worries?

The problem

I used to see (and I have to admin that sometimes I write) code that doesn’t trust another objects behavior or responses. This usually comes in the form of checking that a method response is not null or catch an exception “just in case there was something unexpected that the called class doesn’t handle”.

If you are doing Object Oriented Programming (OOP) and want to do it well, please trust in your objects and their responses. …

Image for post
Image for post
Photo by Clem Onojeghuo on Unsplash

A Response Object is a value object that improves the communication between the different classes and modules in your application, making bug hunting easier and improving the readability of your code.

Basically, a Response Object provides a simple interface to ask if an operation succeeds or if it fails and allows you to provide any additional information that you would require.

A Response Object responds to at least two methods: success? and failure? and can have any data associated with it:

response = SimpleResponse.success(user_id: 1)response.success? # true
response.user_id # 1
response.failure? # false

Real Life Example

Let’s suppose that you are retrieving posts from a third party api. You could write something like…

Image for post
Image for post

Sometimes you would like to let explicit in a test that, beyond ActiveRecord validations, a record can’t be saved if a related model doesn’t exists.

Let’s suppose that you have created a reference from a post to a user this way:

Besides that reference, you could still save a post without an user directly in your database or in your code:

However, you need to be sure that this doesn’t happen so you can avoid to be afraid of edge cases in your code.

To validate that a model can’t be saved in databaset without validation you could use the…

Image for post
Image for post

Let’s suppose that you have the following user class:

class User < ActiveRecord::Base
has_one :address

We can diplay the user’s zipcode this way:


This doesn’t seem that bad, however, we have the following issues:

  • Address can be nil, so this code can fail at some point
  • It breaks the law of demeter

The solution for the first point is simple (but not much elegant):

user.try(:address).try(:zipcode) || 'No zipcode'

This code is still highly coupled, we can to make it better. Fortunately, Rails provides us some help with the delegate method:

class User < ActiveRecord::Base
has_one :address
delegate :zipcode, to: :address…

Image for post
Image for post

I used to validate inputs in GraphQL Ruby this way:

If you have to do many custom validations, your queries/mutations rapidly will begin to grow with code that isn’t closely related to it’s main purpose.

As an alternative, you could use a custom validator so we can change the code above to this:

If you want to have a validator that is called using Validators::Model.validate!(args), you need to create a custom class file in app/graphql/validators/model.rb with the following content:

This way, if you want to add more validations, you only have to add it to this new class instead of clutter your queries/mutations with validation code. …


Giovanni Benussi

Frontend Developer 👨‍💻 Follow me on Twitter 🐦

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store