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:
Here’s the associated output on ESLint when we write this code:
Using target=”_blank” without rel=”noreferrer” is a security risk: see https://html.spec.whatwg.org/multipage/links.html#link-type-noopener 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.
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”:
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.
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.
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.
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
We will create our app using create-react-app:
npx create-react-app apollo-mocks-example
As the Apollo’s Get started page…
Do you trust the objects that you create?
Do you write objects and call methods on them without worries?
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:
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
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
We can diplay the user’s zipcode this way:
This doesn’t seem that bad, however, we have the following issues:
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