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:

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”:

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:

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…

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

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: https://github.com/giovannibenussi/apollo-mocks-example

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…

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. …

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…

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…