Linters are a great tool to find and fix problems in your code. It’s like having a friendly coworker that reviews your code after every change when it’s most fresh. You can of course ignore it though and it’s not gonna be a weird situation as it would be in real life.

Let’s see how they work in real world code:

Hyperlink with a target set to blank so it opens on a new tab
Hyperlink with a target set to blank so it opens on a new tab

Here’s the associated output on ESLint when we write this code:

Using target=”_blank” without rel=”noreferrer” is a security risk: see react/jsx-no-target-blank

Let’s see this in plain ol’ english:

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:

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

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:

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…

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:

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

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

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…

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…

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

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