Forem: Angel M

Lazy initial states in React

Angel M — Sun, 17 Jul 2022 20:13:42 +0000

One of the most important aspects about performance in React applications is how your components react to changes. After introducing hooks in 2019, the definition of components using functions became the new norm.

They came with an interesting side effect: the entire function is executed any time React detects a potential change in your component. Before, components defined with classes only executed certain methods like the lifecycle ones (componentDidMount, etc) and the well known render method.

To manage it, React added the amazing useEffect hook. However, it's important to keep in mind that functions executes all the code inside when they are called.

Initialize a state in React

You can initialize a state in React using the useState hook:

import { useState } from "react";

const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  // Increment the given counter
  const incrementCounter = () => setCounter(counter + 1);

  return (
    <section aria-label="Counter">
      <button onClick={incrementCounter}>Increment</button>
      <output>{counter}</output>
    </section>
  );
};

MyComponent defines a new state to manage the current counter value. Following the previous statement, any time React detects a potential change, it calls MyComponent function and compares the result of the execution with the previous state of the application.

Now, taking a deep look to this function, there are multiple calls and defintions:

Call to useState
Define the incrementCounter function
Call JSX method under the hood

Apart from that, there's a tiny detail that is usually forgotten. 0 is also evaluated. So, what happens if you need to call a function to calculate the initial state value?

Lazy initial state

Now, let's check the following code:

import { useState } from "react";
import { initState } from "./utils";

const MyComponent = () => {
  const [value, setValue] = useState(initState());

  // ...
};

In this case, useState doesn't receive a static value but a function result as parameter. Note that the initState function is called any time React calls MyComponent. However, useState only use the the result once. After its mounted, next executions of the component will discard the initState result.

Depending on the complexity of initState, it may cause some performance issues in MyComponent even after the first initialization. To avoid it, React allows you to pass a function that will be executed just once:

import { useState } from "react";
import { initState } from "./utils";

const MyComponent = () => {
  const [value, setValue] = useState(() => initState());

  // ...
};

This trick is called lazy state initialization.

You don't need to be lazy by default

Let's be fair. Fortunately, states are initialized with static values most of the times. Not all applications will benefit from this useState feature. However, this is one of those difficult performance issues to detect and the solution is quite simple.

Just keep it in mind when you need to call a function to initialize a state. And think it twice if it's a requirement because your component will still need to wait for the result when it's mounted.

References

Hire ethical developers

Angel M — Wed, 06 Jul 2022 17:47:30 +0000

Imagine you are running a small shop in your city. One day you catch a few people stealing something in your shop. After arguing, they ask to join your shop crew because they know some security points that could be improved.

Is that the kind of people you would want to work with? Probably not. They know that you're losing your money when they steal something. However, that's not a reason for them to stop doing it.

What's happening in the developer's world?

Professional ethics

Some time ago, I read this article about a man that was using a screenshot API to earn money mining cryptocurrencies. The article talks about how the company managed the situation and stopped him.

The conversation was respectful and finally, the man stopped minning crypto using that service. I don't want to discuss how the company managed the situation, but I'd like to highlight some parts of the conversation:

C: are we the first company you attacked?

M: no..

M: this is my hobby

M: for fun and profit

[...]

M: i am sorry if you had any loss

C: It's ok we haven't lost anything.

[...]

M: can i be a part of your team ?

C: i'm sorry but we already have a developer in house.

We're at the same point as the shop example. A person without professional ethics that knows the damage he or she might cause to your company is asking to join your team. He knows how to use your service illicitly, so he knows how to protect you.

Based on the comments of the article, it seems the company was wrong. But, were they really wrong ignoring his offering?

No.

Ethics in general ought to be integrated in all your hiring decisions. Surround yourself with people that help you to grow as a professional, but even more importantly, as a person. Please, don't reward bad people because they are good programmers.

Mentors and idols

The same principle applies to your mentors and idols. Remember, ethics matter and are essential. If you know that your idols are good professionals but completely awful people, don't promote their work.

You may think that it doesn't matter because their opinions are not relevant for their work. However, increasing their popularity has a dangerous consequence. Their ideas will become more popular too.

Please, create a better community by promoting good people, not just developers.

Safe and predictable inline scripts

Angel M — Mon, 04 Jul 2022 08:18:51 +0000

In web security, there are many attack vectors that a malicious actor can use. One of the most common attack vectors is the injection. There are many different types of injections. This article is focused on CWE-79 Cross-site Scripting (XSS) injections.

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites - OWASP

In other words, an XSS attack consists of running untrusted and malicious scripts in other user browsers. With this attack, a malicious actor can get access to the environment to read the information in cookies and storage, and compromise the site behavior.

To minimize the risk, there are different ways to ensure the browser only executes trusted resources in your sites. Let's explore how to run inline scripts securely 👇.

Content Security Policy (CSP)

The Content Security Policy (CSP) property allows you to teach the browser about the resources it should read and execute in your site. It can prevent the execution of non-expected resources to minimize the risk.

You can define a CSP policy in two ways:

Returning the Content-Security-Policy HTTP header in the response

  Content-Security-Policy: policy;

Create a <meta> tag

  <meta http-equiv="Content-Security-Policy" content="policy;">

Policies

Policies give you the tooling to only allow the execution of resources that you trust. A CSP policy can define:

A default behavior for the different resources
Restrictions for specific resources

For example, this policy ensures the browser only executes resources from the same domain:

default-src "self";

You can allow other domains and specify any domain for certain resources like images:

default-src "self" example.com; img-src *;

From there, you can start adding stricter policies.

Inline Scripts

Inline scripts are wild and one of the most common injection vectors. An attacker may run arbitrary code on your site using different approach. So, a good practice is to restrict inline scripts via CSP:

default-src "self";

However, sometimes inline scripts are required. For example, this site uses an inline script to load the site theme. Using the previous CSP policy would block this script. Inline scripts can be enabled using the unsafe-inline value:

default-src "self"; script-src "self" "unsafe-inline";

As you may guess, this is a risky option as it allows any inline script in your site. To protect against unexpected inline scripts, CSP provides us with two tools to enable only trusted ones.

Nonces

In cryptography, a nonce (number once) is an arbitrary number that can be used just once in a cryptographic communication - Wikipedia

Nonce strategy requires to generate a base64 random string on the server for every request. It requires a server to generate the nonce dynamically. Once the nonce is created, you should:

Set the nonce value in every trusted script

   <script nonce="RANDOM_NONCE">let my_trusted_script;</script>

Configure the CSP the policy to allow script associated to the nonce:

   default-src "self"; script-src "self" "nonce-RANDOM_NONCE";

This approach is straightforward. However, it requires a server to generate a new random nonce on every request. If your site is static like this blog, let's check the next approach.

Script Hash

The script hash strategy allows you to indicate the hash of the inline scripts of your site. The browser computes the hash of every inline script and compares it with the values provided in the CSP policy. If the script matches the given hash, the script will be executed.

To compute a script hash, you need to:

Compute the SHA-256, SHA-384 or SHA-512 hash of the script content. Note this includes every tab, space, and break line. Always calculate the hash of the exact code that will be executed.
Convert the given hash to base64.

To make things simpler, I created 👉 a small tool 🔨 so you only need to paste your code there.

Once you have the hash, configure it as a trusted inline script in the CSP policy:

default-src "self"; script-src "self" "sha256-sytuQ9rGYPcMw/DRh3WEVO2EynM4II6TcLanpOZl+NA=";

This approach allows you to execute inline scripts in static sites safely. This is the approach I use on the site 😄.