DEV Community: Lorenz Weiß

The power of http headers and 4 examples you did not know before

Lorenz Weiß — Fri, 23 Oct 2020 16:22:30 +0000

This post was originally posted here

Hello Http (headers)

Almost everything in the web is sent with http and even non-developers have seen it when using the internet as keyword
inside urls or links.

Http stands for Hypertext Transfer Protocol and gives us the ability to transfer hypertext between a browser and a server.
This is a great technology that has been around almost since the invention of the web and is constantly evolving and offering more and more great features

What are Http headers?

As a developer you probably heard of http headers, at least in the moment you heard about the CORS policy.
This is a problem you must have heard about when developing websites.
But what exactly are http headers and what other ways are there to use them?

Let us first find out what they do and how you could use them.

When a browser requests a resource, for example a page of this blog, it asks the server with a request.
This request looks something like this:

fetch("https://www.lorenzweiss.de/race_conditions_explained/", {
  credentials: "include",
  headers: {
    accept:
      "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3",
    "accept-language": "en,en-US;q=0.9,de-DE;q=0.8,de;q=0.7",
    "cache-control": "max-age=0",
    "sec-fetch-mode": "navigate",
    "sec-fetch-site": "same-origin",
    "sec-fetch-user": "?1",
    "upgrade-insecure-requests": "1",
  },
  referrerPolicy: "no-referrer-when-downgrade",
  body: null,
  method: "GET",
  mode: "cors",
});

So you can see the URL or location of the resource, some information about the request and also a lot of headers with some information about the request.
This is how your browser tells the server some more information about the request. For example what kind of data type it accepts or
how the client is handling the cache.

After sending the request, the server replies, and it also sets some headers in the reply, which could look like this:

:authority: www.lorenzweiss.de
:method: GET
:path: /race_conditions_explained/
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
accept-encoding: gzip, deflate, br
accept-language: en,en-US;q=0.9,de-DE;q=0.8,de;q=0.7
cache-control: max-age=0
cookie: _ga=GA1.2.1173972759.1584812492; _gid=GA1.2.2076192721.1594044231
sec-fetch-mode: navigate
sec-fetch-site: same-origin
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36

There is also some information that the server wants to tell the browser what to do with the resource, for example
if there are cookies, it must be determined which encoding was used, etc

Basically, in the http-context the headers for the communication of the browser and the server are used to extend the simple
Requests for resources. You could see it as the sheet of paper that is added on top of a package that you oder from an online store,
giving you more information about the context and the resource that you ordered.
Most of the headers have quite good defaults which you don't need to think of, but there are some headers that
can get quite important, like CORS headers. But there are so much more headers that you might never heard of which are very useful
and good to know how to use.

Headers you don't know

Do not worry, this article will not deal with CORS headers. The following http headers are those that are rarely used, but
can be really powerful and helpful to significantly improve the communication between a server and the browser.

So let's dig into it. Here are some headers that you can set and that are very useful and practical.

If-Range

What and why?

Imagine you start downloading a large resource, such as a video, an image, etc., and stop in between because of connection problems.
With If-Range you can tell the server if the representation is unchanged, to send the part(s) that are requested in Range.
Which means only the parts that were missing and not again the whole thing.

This can be very helpful when dealing with large resources and often bad connections as with mobile devices.
Because the resource can be downloaded in parts even if the connection is interrupted in between.

How to use

It can either be used with a date when the resources were last modified, or with an ETag, which is a key to help if the resources was invalidated

If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>

Example

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

Vary

Vary Comes from a time when the web or http was used for a variety of things and not just for web pages.

It is based on the idea of using http to exchange information in many different formats.
How does it do that? Well, it tells the server in which header to find the information, how to present the information.

Nowadays it can be really helpful if you have different resources for different customers, for example
mobile, tablet or desktop.
Imagine three different images for the same resource are stored on the server, depending on the device.
Then you can simply use the Vary header to tell the server to check the device and then decide which image size to send.

Example

For the example with the device dependent images, you can simply pass the 'user agent' to tell the server
that it should check the user-agent for device information.

Vary: User-Agent

How to use

Vary: <header>

Just enter the header, the server must check before deciding which resource to send.

Content-Disposition

If we go back to the example of a request to a server, for example to load this website, it is clear to the browser,
that it must display the resource of the answer.
But it can also be the case that the server sends a resource that the browser should automatically download to the user's computer,
like a picture or pdf etc.
A server can tell the browser what the browser should do with the attached resource via the Content Disposition header.

Example

With defining the Content-disposition to attachment the browser knows that this is a resource to download instead of just
show.

Content-Disposition: attachment; filename="data.pdf"

How to use

You can define the header as inline or attachment, where `inline is always the default.

Content-Disposition: <inline | attachment>

Feature-Policy

This is a fairly new header and therefore only supported by modern browsers (sorry to all IE users). However
I want to mention this anyway because I think it can be really helpful for some use cases.

Basically, the feature-policy tells the browser which features or apis the browser should provide to the document and itsiframes` to be used.

For example, it can ban all scripts or iframes etc. within this website to allow sensitive apis like the camera or microphone.

How to use

Feature-Policy: <directive> <allowlist>

The directive is the name of the feature. You can see the full list of features here
The allowlist defines the origins which are allowed to use the directive.

Example

Suppose we want our website to use neither the microphone nor the camera. With this header the
document or a contained iframe cannot access these functions.

Feature-Policy: microphone 'none'; camera 'none'

More Headers:

Here are some more headers that are worth mentioning:

Conclusion

Https headers are great and also very useful! But sometimes they can be quite complex, and it's really hard to get an overview of what headers are available and what benefits they bring.
Also when developing a website, especially in the frontend, you don't come in contact with them too often, except maybe with the CORS headers.
But I think that this missed some possibilities. http headers represent the communication between the server and the
customers much better, and we all know that communication is the key to a good relationship.

I hope I could shed some light on the darkness of http headers for you. In case I missed a good and helpful header,
please do not hesitate to send me a mail or contact me in any way.

What is the value of experience as a software developer?

Lorenz Weiß — Mon, 20 Jul 2020 22:16:53 +0000

This post was originally posted here

Experience

We've all seen it, you're in an interview for a job and they'll certainly ask you about your experience in software development.
In fact, you probably saw the following line in almost every job description for a software development position before you started looking

You need at least X+ years of professional experience working as a X-developer for this position.

They may even have been asked how many years of experience they have with specific technologies.
I've even heard of huge Excel spreadsheets where you have to fill in the years you've worked with each technology.

So I have always wondered:

What exactly is this mysterious experience?
Can you count it?
Do you have a reference for it?
Is it just the simple years you've worked so far?
Is it really that simple?

Let's dig into it a bit.

Gaining Experience

Most companies or recruiters I've seen so far define or rate experience by the number of years.
And your position is defined by this. A hard example would be that 5 years of experience as a software developer prepares you to become a senior developer, with more than 10 years you can become a manager.

Well, So why don't we just sit there, count the years and gain more and more experience?
With this analogy, you'll be the best developer in the last year before retirement, and all you'll have to do is sit and wait to get better and better.

Let me explain why I don't think that is true and why defining experience isn't that simple.

Defining Experience

For a better understanding of what experience really is, it is important to divide it into "Technical Experience" and "Everything else than technical Experience"

Technical Experience

As a software developer, you will always have to learn new things. The tools we work with change so quickly that it is important to keep a sharp eye on current trends and new methods or technologies. However, experience in working with a technology from 5 or even 3 years ago is often not as valuable as the experience you gain when working with the current technologies.

Imagine you have worked as a software developer for 10 years and then traveled the world for 5 years without reading or touching any code. Does your 10 years of technical experience have the same value as someone who has worked in the last 5 years? Probably not.

Understanding the context

Suppose you as a developer have been working for over 5 years with a huge code base that already exists before you started working on it. You did your best to add new things, refactor some things, or understand the legacy code.
Another works in an agency or as a freelancer and has contributed or created several different projects of varying scope. Although your were in the same field or using the same technology, you have both gained quite different experiences.

One type of experience is how to handle and maintain a large project and how to work with legacy code, the other is more experience in setting up projects and the ability to recognize the balance between quality and speed..

It depends on the motivation

This is probably the most overlooked point of experience.
You can either be the developer who is always curious and always open to try new things and ready to step out of the comfort zone, or you can be a one-trick pony developer who knows one thing quite well, and you always do it because that's what you know.

But at the end of the day you will have the same years of experience, but the actual knowledge and experience you have acquired is completely different.

Everything but technical experience

We all know it, the work as a software developer usually includes working with other people or mostly working with within a team. So you will soon realize that a large part of the experience is in how to deal with teamwork, planning, communication and mentoring. You cannot learn these things by reading a book or an article. These things are part of the job. This is probably the case when experience is the most valuable resource. But again, is time the best measure here?

Let's imagine that someone works in a team with rather fewer people and the fluctuation is quite low, which means that everyone works together for years. Is this experience they all have easily transferable to other teams? Or is this experience really linked to the specific company or team?
Wouldn't someone who has worked with several different teams or companies of different sizes at the same time be more experienced in this respect?

Getting insights

Don't get me wrong, I'm not saying that everyone should change the company or the team every 3 months, I would just argue that it's easy to get into a kind of comfort zone where you always work with the same people and get used to the workflow without getting new input. If new input and leaving the comfort zone is indeed the best way to gain experience.

Especially when it comes to non-technical things, since you usually can't read or learn them with the resources available, the only thing that brings new insights is to talk or work with new people. So perhaps another measurement other than time would be more appropriate for defining experience in this sense.

Years can matter

Let me get this straight: I'm not saying the years don't matter, they definitely do. I'm pretty sure I'm a better developer today than I was 5 years ago.
But I'm also pretty sure there's someone out there somewhere who has fewer years in the "field" and is a far better developer than I am, because that's just a reference point for yourself, but not as easy as comparing with others.

Conclusion

Let's take an example, if you work as a simple door-to-door salesman selling vacuum cleaners, there is a simple measure of how well you work, the number of items you sell, for them it is so simple. Therefore, from any point from which you work in this area, you can be the best directly by simply selling more items.

But I think when it comes to judging the experience or value of developers, it's not that easy, and since software development is such a common task, it's almost impossible to find this way.
That's why the most used one at the moment is just the simple time of work experience.
But since it is obviously not so easy to define it, why do we use such a simple measurement? Can't we make the definition a bit more detailed than just a simple number?

If someone would spend the whole working day writing one line of the same Javascript code over and over again for 5 years, would that make him a developer with 5 years of Javascript experience?
Yes, but would that make him/her a good Javascript developer?
No, not really.

So I think we somehow need a better way to understand the real value of experience as a software developer, and especially when it comes to hiring, there must be a way to identify that experience, rather than just counting down the number of years.

Sometimes I have the feeling that we lose a lot of potential in young talented developers just because we don't give them a chance or don't appreciate them enough because of "too little experience".

Add automated code templates for react components

Lorenz Weiß — Mon, 22 Jun 2020 14:44:21 +0000

This post was originally posted here

Save time creating components

Working with a component-based framework involves a lot of creative work, in which obviously many components are created, which ideally always have the same structure and can be put together to form an application.

Most likely, each component begins with the same structure, e.g. styles, tests, logic etc. and with each piece a new file is needed.

Creating these files and always writing the same structure for components can be quite annoying. In this article, you will learn how to speed up this process and create your own simple scripts and templates that do all of this for you with the magic of PlopJS.

The goal is to have one single command that spits out everything you need for your component at once and always has the same custom structure. Having this helped me a lot in my daily work creating new components and significantly accelerated my work.

Using templates from your IDE

Most likely you are already using your IDE templates to generate the components. This is a fairly simple approach, which is activated by default with the most popular IDEs.
For example, with VSCode.

Snippets are not enough

However, there are some limitations with it, and you still need to create separate files like your styles, your tests, your index files, etc.
Especially if you work with a large team with different IDEs and setups, you have to make sure that everyone follows the same pattern within a project, or you will have different approaches between all of your components, which have been created by different people and IDEs.

A good example and an important use case is working with a component library.
To create a new component that is added to your library, you always have to create not just one file, but several files in the same pattern, which is not possible with the built-in templates of most IDEs.
However, building components is required in every project, so adding this functionality increases the productivity of each project

Plop your components

There's a pretty neat way to generate your components and define the structure and chains of what should happen.
Let's find out how this works.

Introducing PlopJS

PlopJS is a scripting tool that I now use in most of my projects to generate my components or other workflows.
What is PlopJS? Let's check the official documentation:

Micro-generator framework that makes it easy for an entire team to create files with a level of uniformity.

That sounds pretty great. But how can you add that to your component library or project?

Component structure of the library

Before we start I should clarify some things here, for the following example we are using:

styled-components for stylings
storybook for displaying our components
Jest for testing.

However, these are just examples and you can use anything you want to generate your files.

With this tech stack, every component in your project should have the same structure (this is also highly opinionated and of course you can create your own structure as you like):

MyComponent
:- MyComponent.jsx        // Main file
:- myComponent.styles.js  // Stylings
:- myComponent.story.js   // Storybook
:- MyComponent.spec.js    // Tests
:- MyComponent.docs.md    // Documentation
:- index.js               // Index for exporting

In addition we have in our src folder a global index.js file which exports all the components from one place.

In the end, to create a component, our script should generate these five files and add one line to the global index.js, exporting this component.

NEWSLETTER

Adding PlopJs to your project

If you follow the install process you can install it directly into your project.

npm install --save-dev plop

With that you can start ploppin'. Let's start by adding the plop-script to your package.json

"scripts": {
    ...
    "generate": "plop",
    ...
  }

I call the script "generate", but you can of course call it the one that suits you best.

Now let's add a so called plopfile.js in the root of your project.
This is where all your plop-scripts and -commands are stored.

module.exports = (plop) => {
  plop.setWelcomeMessage('Welcome to PLOP, what do you want to do?');
  plop.setGenerator('component', {
    description: 'Create a component',
    // Get info from user
    prompts: [
      {
        type: 'input',
        name: 'name',
        message: 'What is your component name?',
      },
    ],
};

This function is executed when you run the Plop script with npm run generate.
With plop.setWelcomeMessage you can display a message to the user at the beginning to describe what the script actually does.

PlopJS can even do more than one thing in this script, so we first need to tell it what we want to do so that the user can choose the expected behavior.

Add generators

plop.setGenerator adds new functionality to the plop script. The first argument is the name of your action and the second is an object that defines what to do when the user chooses this option.

In our case, we add the "Create a component" option because we want to well, create a new component.
Before we create this component, however, we need an input. The created component needs a name.

Give it a name

To get the name from the user, we can use the "prompts" option within the object in the second argument.
prompts is an array that defines all of the user's input. For our example, we only need a simple text entry that contains the name of the component. (There a lot more options to get information from the user using prompts)
Our prompt contains three things:

type is the type of the action, in our case a simple "input".
name is the variable name to retrieve the inserted value at a later time.
message is a message that is displayed in the command-line and tells the user what to enter.

Plop actions

The next part of the object in the generator function is the "actions" part. Here we can define our chain of actions, what the script should do.
Several action types are already integrated, which you can use from plopJS. If this is not enough, you can also write your own actions.

In our example we only need two different action types:

Add -- Adding a whole new file (styles, component, tests etc.)
Append -- Adding something to an existing file (add the export to the index.js)

Adding files

Let's start by adding out main component file. For that we add a new action into the actions array.

module.exports = (plop) => {
  plop.setWelcomeMessage('Welcome to PLOP, what do you want to do?');
  plop.setGenerator('component', {
    description: 'Create a component',
    // Get info from user
    prompts: [
      {
        type: 'input',
        name: 'name',
        message: 'What is your component name?',
      },
    ],
    actions: [
      "------------------------------",
      "Generating a new component...",
      "------------------------------",
      {
        // Add the main file
        type: "add",
        path: "src/components/{{pascalCase name}}/{{pascalCase name}}.tsx",
        templateFile: "plop-templates/Component.ts.hbs",
      },
    ]
};

The object consists of three different values.

type describes the type of action. In our case, this is "add" because we want to obviously add something.
path is the directory and filename we want to add or create. With the help of these {{ we are using the handlebars syntax, giving us the option to get the previous user input stored as the value name. With the previous value pascalCase we are defining in what format we want the directory or file be called.
templateFile is the directory to our template file for this action. We will come to this template file in the next part.

Template files

Most actions use template files that you can use to generate your files for your component. For our project or component library we create a folder called "plop-templates" in the root directory of the project.
There we save all template files that we use to generate the components. For the main component file we need a Component.js.hbs file and are filled with:

import React, {FC} from 'react';

function {{pascalCase name}}(props) {
  return (
    <div>
      {{pascalCase name}}
    </div>
  );
};

export default {{pascalCase name}};

As you can see the template file looks almost like a real component, except everywhere we would insert the component name we use {{ pascalCase name}}, this will be filled from plopJS with the inserted name from the prompt.

You can use this kind of templates and functionality for all your other files like styles, tests, etc.

Append the export to the index file

So much for adding. What about adding a new line to our global file "index.js"? For this we can use the "attach" action from plopJS.

  {
    // Append to the global index file
    type: "append",
    path: "src/index.ts",
    templateFile: "plop-templates/global_index.ts.hbs",
  },
};

It's basically the same structure as the adding, except we use "append" for the type value.
The templateFile will contain the single line that will be added to our index file.

export { default as {{pascalCase name}} } from './components/{{pascalCase name}}';

Adding the rest to the script

With all of that we can add the actions for all our files and combine everything in the plop-script.
Adding plain strings to the actions, you can simply print out messages between your actions.

module.exports = (plop) => {
  plop.setWelcomeMessage('Welcome to PLOP, what do you want to do?');
  plop.setGenerator('component', {
    description: 'Create a component',
    // Get info from user
    prompts: [
      {
        type: 'input',
        name: 'name',
        message: 'What is your component name?',
      },
    ],
    actions: [
      '------------------------------',
      'Generating a new component...',
      '------------------------------',
      {
        // Add the main file
        type: 'add',
        path: 'src/components/{{pascalCase name}}/{{pascalCase name}}.jsx',
        templateFile: 'plop-templates/Component.js.hbs',
      },
      {
        // Add the story file
        type: 'add',
        path: 'src/components/{{pascalCase name}}/{{pascalCase name}}.story.jsx',
        templateFile: 'plop-templates/Component.story.js.hbs',
      },
      {
        // Add the styles
        type: 'add',
        path: 'src/components/{{pascalCase name}}/{{pascalCase name}}.styles.js',
        templateFile: 'plop-templates/Component.styles.js.hbs',
      },
      {
        // Add the test file
        type: 'add',
        path: 'src/components/{{pascalCase name}}/{{pascalCase name}}.test.jsx',
        templateFile: 'plop-templates/Component.test.js.hbs',
      },
      {
        // Add index file
        type: 'add',
        path: 'src/components/{{pascalCase name}}/index.js',
        templateFile: 'plop-templates/index.js.hbs',
      },
      {
        // Append to the global index file
        type: 'append',
        path: 'src/index.js',
        templateFile: 'plop-templates/global_index.js.hbs',
      },
      '------------------------------',
      '🤲 Welcome to the world little friend 🤲',
      '------------------------------',
    ],
  });
};

Now when when we run npm run generate, the script will take over all the creation of out component files for us:

Et voilá, everything we need will be done with a single command and will never have the problem of creating all of these files by hand. All files and components now start with the same structure, regardless of who and where they are executed.

How to avoid race conditions with asynchronous javascript

Lorenz Weiß — Fri, 05 Jun 2020 14:17:51 +0000

This post was originally posted here

When you write code, you have probably stumbled upon the term "race conditions" at some point, and every time this word appears, you and every developer should be afraid and do everything possible to avoid having them their code base. But why is it like that? And what exactly are those race conditions?

In this article, I would like to give a brief explanation using asynchronous javascript along with some real-life examples so you don't have to be scared next time.

First, let's look at the definition in the official wikipedia article:

A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.

Phew, that sounds complicated.

Let's try to put it in simpler terms. Basically, it means we have a result, something like a state or an object. And this result depends on more than one uncontrolled event, like an asynchronous function or something that takes a long time and that no one can really predict.

This means that these events have taken place in different orders and produce different results. Now if at least one of the possible results is not desired or unexpected, this leads to a so-called race condition.

But what exactly is really dangerous about it?

Basically, the most dangerous thing is that it can be so random that it may not be reproducible, or even additional debugging can cause the symptom to go away completely by changing the flow of control.

To better understand the problem, let's try to visualize it with a real live example in javascript.

let state = null;

async function mutateA() {
  await /* asynchronous code */
  state = 'A';
}

async function mutateB() {
  await /* asynchronous code */
  state = 'B';
}

In this example we have one state and two functions that will both do something asynchronously like an api call or an expensive calculation.
After finishing, both function will update the same state.

Now let the race begin

Now suppose something called mutateA, for example a simple click on a button.

Immediately afterwards we execute mutateB with another click.
Since mutateA takes some time before updating the state, we now called mutateB before mutateA ended and the state was updated.

Assuming now that mutateB is a lot faster than mutateA, even though we called it AFTER mutateA, it will be finished before and then will update the state to "B".

Now comes the weird part.

mutateA finishes, and sets the state back to "A". So in the end we have a different oder of the state updates than we have clicked the buttons.

This behavior leads to a probably "undesirable" result. We would normally expect the state to be the last mutation we called and to be set to "B".
But in this "race" mutateB overtook mutateA and in the end the state was set back to "A".

What is dangerous about that?

The dangerous thing about this situation is that you can never be sure of what will happen.
Because the time that the asynchronous part of both functions takes is most likely not 100% predictable.

Although it works 99% of the time because mutateA is super fast and no one will solve any problem, there is a slight chance that it won't, and as we all know we developers don't like it to be non-deterministic.

Let's fix it the wrong way.

let state = null;

async function mutateA() {
  await /* asynchronous code */
  state = 'A';
}

async function mutateB() {
  await /* asynchronous code */
  setTimeout(() => {
    state = 'B';
  }, 1000);
}

It looks very simple. To avoid "mutateB" overtaking "mutateA" in the race, we only put a few weights on it and delayed the state update by 1 second.

Well, this could solve another 0.5% of the cases that could occur, but even if we ignored the unnecessary 1 second delay, which is basically hell when it comes to user experience, the problem is actually not gone, it's just a little bit more minimized.

NEWSLETTER

Let's fix it the right way

One way of fixing this problem is introducing a simple semaphore. That means we add a kind of flag or guard that identifies the resource to be blocked.

Ideally, we would also have a kind of queue in which we can save the order of the stored functions. For now to keep it simple, we will only block the resource when another mutation is in progress, and for example disable all buttons that would mutate the same state.

let state = null;
let blocked = false;

async function mutateA() {
  if (!blocked) {
    blocked = true;
    await /* asynchronous code */
    state = 'A';
    blocked = false;
  }
}

async function mutateB() {
  if (!blocked) {
    blocked = true;
    await /* asynchronous code */
    state = 'B';
    blocked = false;
  }
}

So only one mutate function can run at once. With that it's save that only one resource can update the state at once.

Example with react hooks

Let's try to visualize that in a more realistic example using react hooks.


function MyComponent() {
  const [state, setState] = useState(null)
  const [blocked, setBlocked] = useState(false)

  function mutateA() {
    if(!blocked) {
      setBlocked(true)
      await fetch('https://api.for.A');
      setState('A');
      setBlocked(false)
    }

  }

  function mutateB() {
    if(!blocked) {
      setBlocked(true)
      await fetch('https://api.for.B');
      setState('B');
      setBlocked(false)
    }

  }

  return (
    <div>
      <span>Result: {state}</span>
      <button disabled={blocked} onClick={mutateA}>Get A</button>
      <button disabled={blocked} onClick={mutateB}>Get B</button>
    </div>
  )
}

We have two states, one is our application state and the other one is the guard blocking the buttons.

Now when someone clicks on one button the other button is disabled as long as the asynchronous function is running.
This would prevent the state to be in an unexpected mode.

Especially when working with react and having one state that gets modified from different resources you can end up having a lot of race conditions.

So understanding the flow of events withing your code is quite important to avoid those bugs or unexpected events from happening.
I hope you can now code with a little bit less fear in mind.

Have ever experienced something like this? If so I would love to hear how you solved the problem in your example.

Five common mistakes writing react components (with hooks) in 2020

Lorenz Weiß — Mon, 25 May 2020 13:33:54 +0000

This post was originally posted here

React as a framework

React has been out in the world of web development for quite some time now and its position as a tool for agile web development has steadily strengthened in recent years. Especially after the announcement and release of the new hook api/concept, writing components has never been easier.

Although the team behind react and the huge community have tried to train and explain the concepts of the framework in an impressive way, I still see some pitfalls and common mistakes that were made while working with it.
I kept a list of all the mistakes I saw over the last years related to react especially with using hooks. In this article I want to show you the most common ones and I will also try to explain in detail, why I think they are mistakes and a suggestion for doing it in a cleaner way.

Disclaimer

Before we start with the list, I have to say that most of the following things are not fundamental mistakes or don't look wrong at first glance, and also most of them are unlikely to affect the performance or apperance of the application.
Probably nobody would notice, except for the developers working on the product, that something is wrong here, but I still believe that good quality code can lead to a better developer experience and thus to a better product.

As with any software framework or library, there are millions of different opinions about it. Everything you see here is based on my personal opinion and should not be considered a general rule.
If you have a different opinion about her, I would love to hear it 🌟

1. Using useState when no rerender is needed

One of the core concepts of react is dealing with state. You can control your entire data flow and rendering through the state. Each time the tree is rendered again, it is most likely tied to a change in the state.

With the useState hook you can now also define your state in function components, which is a really neat and easy way how to handle states in react. But it can also be misused as we see in the following example.

For the next example we need a bit of explanation, suppose we have two buttons, one button is a counter and the other button sends a request or triggers an action with the current count. However, the current number is never displayed within the component. It is only required for the request when you click the second button.

This is dangerous ❌

function ClickButton(props) {
  const [count, setCount] = useState(0);

  const onClickCount = () => {
    setCount((c) => x + 1);
  };

  const onClickRequest = () => {
    apiCall(count);
  };

  return (
    <div>
      <button onClick={onClickCount}>Counter</button>
      <button onClick={onClickRequest}>Submit</button>
    </div>
  );
}

The problem ⚡

At the first sight, you might ask what is exactly the problem with that? Isn't what what the state was made for?
Sure you are right, this will work just fine and probably there will be never a problem with that, however in react every state change will force a rerender for that component and most likely its children, but in the above example since we never use that state in our render part, this will end up being an unnecessary render every time we set the counter, which can impact the performance or could have unexpected side effects.

The solution ✅

If you want to use a variable inside your component which should keep its value between rendering but also don't force a rerender, you can use the useRef hook. It will keep the value, but doesn't force the component to rerender.

function ClickButton(props) {
  const count = useRef(0);

  const onClickCount = () => {
    count.current++;
  };

  const onClickRequest = () => {
    apiCall(count);
  };

  return (
    <div>
      <button onClick={onClickCount}>Counter</button>
      <button onClick={onClickRequest}>Submit</button>
    </div>
  );
}

2. Using router.push instead of a link

This might be a very easy and obvious one and not really related to react itself, but I still see it quite a lot when people writing react components.

Let's say you will write a button and with clicking the button the user should be redirected to another page. Since its a SPA, this action will be a client-side routing mechanism. So you will need some kind of library for doing that.
In react the most popular one is react-router and the following example will use that library.

So adding a click listener will redirect the user to the desired page right?

This is dangerous ❌

function ClickButton(props) {
  const history = useHistory();

  const onClick = () => {
    history.push('/next-page');
  };

  return <button onClick={onClick}>Go to next page</button>;
}

The problem ⚡

Even though this would work just fine for most of the users, there is huge problem when it comes to accessibility here. The button will not be marked as linking to another page at all, which makes it nearly impossible to be identified by screen readers.
Also could you open that in a new tab or window? Most likely not.

The solution ✅

Linking to other pages with any user interaction should as far as possible be handled by the <Link> component or a normal <a> tag.

function ClickButton(props) {
  return (
    <Link to="/next-page">
      <button>Go to next page</button>
    </Link>
  );
}

Bonus points: it also makes the code a lot more readable and shorter!

3. Handling actions via useEffect

One of the best and most thoughtful hooks introduced by React is the "useEffect" hook. It enables the processing of actions related to prop or state changes.
Despite its helpful functionality, it is also often used in places where it may not be needed.

Imagine a component that fetches a list of items and render them to the dom. In addition, if the request is successful, we would like to call the "onSuccess" function, which is passed on to the component as a prop

This is dangerous ❌

function ClickButton(props) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [data, setData] = useState(null);

  const fetchData = useCallback(() => {
    setLoading(true);
    callApi()
      .then((res) => setData(res))
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  }, []);

  useEffect(() => {
    fetchData();
  }, [fetchData]);

  useEffect(() => {
    if (!loading && !error && data) {
      props.onSuccess();
    }
  }, [loading, error, data]);

  return <div>{data}</div>;
}

The problem ⚡

There are two useEffect hooks, the first one is handling the api call on the initial render and the second one will call the onSuccess function, by assuming when there is no loading, no error, but data in the state, it must have been a successful call. Make sense right?

Sure for the first call this is true and probably will never fail. But you also loose the direct connection between the action and the function that needs to be called. Also there is no 100% guarantee that this case will only happen if the fetch action has succeeded and this is something we as developers really don't like.

The solution ✅

A straight forward solution would be to set the "onSuccess" function to the actual place where the call was successful:

function ClickButton(props) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [data, setData] = useState(null);

  const fetchData = useCallback(() => {
    setLoading(true);

    callApi()
      .then((fetchedData) => {
        setData(fetchedData);
        props.onSuccess();
      })
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  }, [props.onSuccess]);

  useEffect(() => {
    fetchData();
  }, []);

  return <div>{data}</div>;
}

Now it is quite clear at the first sight when the onSuccess is called, exactly in the success case of the api call.

4. Single responsibility components

Composing components can be hard.
When is it time to split a component into several smaller components?
How do you structure the component tree?
All of these questions arise every day when working with a component-based framework.
However, a common mistake in designing your components is to combine two use cases into a single component.
Let's take an example of a header that shows either a burger button on mobile devices or tabs on desktop screens. (The condition will be handled the the magical isMobile function, which is not part of this example 🧙‍)

This is dangerous ❌

function Header(props) {
  return (
    <header>
      <HeaderInner menuItems={menuItems} />
    </header>
  );
}

function HeaderInner({ menuItems }) {
  return isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />;
}

The problem ⚡

With this approach the component HeaderInner is trying to be two different things at once and we all learned from Mr. Jekyll, being more than one thing at a time isn't really ideal.
Also it makes it even hard to test or to reuse the component at other places.

The solution ✅

Bringing the condition one level up, makes it easier to see what the components are made for and that they only have one responsibility, being a Header, Tabs or a BurgerButton and not trying to be two things at once.

function Header(props) {
  return (
    <header>{isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />}</header>
  );
}

5. Single responsibility useEffects

Remember the times, where we only had the componentWillReceiveProps or componentDidUpdate methods to hook into the rendering process of a react component? It is bringing back dark memories and also realizing the beauty of using the useEffect hook and especially that you can have as much as you want of them.

But sometimes forgetting and using a "useEffect" for several things brings back those dark memories. For example, imagine you have a component that fetches some data from the backend in some way, and also displays breadcrumbs depending on the current location. (Using again react-router for getting the current location.)

This is dangerous ❌

function Example(props) {
  const location = useLocation();

  const fetchData = useCallback(() => {
    /*  Calling the api */
  }, []);

  const updateBreadcrumbs = useCallback(() => {
    /* Updating the breadcrumbs*/
  }, []);

  useEffect(() => {
    fetchData();
    updateBreadcrumbs();
  }, [location.pathname, fetchData, updateBreadcrumbs]);

  return (
    <div>
      <BreadCrumbs />
    </div>
  );
}

The problem ⚡

There are two use cases, the "data-fetching" and "displaying breadcrumbs". Both are updated with an useEffect hook. This single useEffect hooks will run when the fetchData and updateBreadcrumbs functions or the location changes. The main problem is now, we also call the fetchData function when the location changes.
This might be a side effect we haven't thought of.

The solution ✅

Splitting up the effect makes sure, they only are used for one effect and the unexpected side effects are gone.

function Example(props) {
  const location = useLocation();

  const updateBreadcrumbs = useCallback(() => {
    /* Updating the breadcrumbs*/
  }, []);

  useEffect(() => {
    updateBreadcrumbs();
  }, [location.pathname, updateBreadcrumbs]);

  const fetchData = useCallback(() => {
    /*  Calling the api */
  }, []);

  useEffect(() => {
    fetchData();
  }, [fetchData]);

  return (
    <div>
      <BreadCrumbs />
    </div>
  );
}

Bonus Points, the use cases are now also logically sorted within the component.

Conclusion

There are many pitfalls when writing components in react. It is never 100% possible to understand the whole mechanism and to avoid every little or even big mistake. But making mistakes is also important when learning a framework or programming language and probably nobody is 100% free of these mistakes.

I think sharing your experience with that can be very helpful for others or prevent them from making them.

If you have any questions or wait, I don't think this is a mistake, please write to me, I would love to hear your opinion.

How and why to write useful commit messages. (5 helpful tips)

Lorenz Weiß — Mon, 11 May 2020 17:16:24 +0000

If you have worked with other developers on a software project, you have probably used git, in order to have a proper version control, especially when you are working in parallel on the same code base. As most of you know git is a very powerful tool to helps people collaborate on a common project and probably used on most of the software projects all around the world, Let's be honest I cannot imagine how it was to work as a software engineer before git was invented.

Working with git

What is probably the most used workflow in git?

When you have completed a step within your task, solved a problem or at least a part of it, you are "committing" your changes and then pushing them to the remote repository.
We all probably do this, or should do it at least once a day.

Along with this you also have to write a clear and understandable commit message for every commit you are doing describing what you have done in that commit.
But what are those commit messages for and why are they so important when working with git ? Let's try to find out using a simple example.

Using commit messages

Suppose you encountered a problem in your project and tried to find a solution. You searched and searched and ended up finding a file that was hundreds of years old and most likely the reason for your problem or bug you need to solve. So what are you doing now?

Let's refactor that file and also fix your problem. Is the problem fixed? Yes? Brilliant! This might have taken you only a couple of minutes but also maybe some hours or even days. But at least it's fixed and you can mark this task as done.

So quickly commit it and push it, so that everyone can see your awesome and your noble work of refactoring. But damn it, we have to write a commit message ...
Okay, well, let's do it quickly so as not to postpone our great solution.

git commit -m 'Refactoring + problem fix'

Good job!

So far everything looks good in your commit,

Well, except this commit message.
What exactly does that commit message tells your teammates?

If you're really honest, not a lot, but you're so excited to finally fix this problem that you don't have time to think about a very good commit message, and also who will read that anyway right?

Let's face it, we all had these thoughts in mind and we are definitely not the only developers writing these commit messages. I am sure that every developer has done this at least once in their life and will do it even in the future.
To make it a bit clearer what I think these "bad" commit messages are, I would like to give you a few more examples of a bad type of commit messages:

- "small fix"
- "testing"
- "Removing the fetching parameters from file to find a good way of splitting the dependencies in the Fetch processor for api endpoint and also did some hacky solution of how the processor was building the query parameters of the url for accessing the endpoint in a more readable and easy way"
- "e-1432"
- "bug fix"
- "I don't know how, but it works now"
- "mmmmmmmmmmmmmmm"
- "fasdf"

What's the problem with them? Well none one of them is really telling me what exactly happened, right? Maybe at least that very long one. But let's be honest who wants to read all of that for every commit to get what happened here?
There is clearly a problem. So how can we write better commit messages? To do this, we first need to find out exactly what the purpose of a commit message is and why we are writing it.

Purpose of a commit message

You probably opened a file at least once and saw something there that didn't make sense to you and your first thought was to remove it or rewrite it. If you are smart before doing that you would investigate a bit what and why that code was added.

But how?

If you're lucky, the developer who wrote it was smart enough to anticipate that this could be confusing. So she or he added a code comment and explained what's going on.
But as we all know, this is most likely not the case. So how do you find out what the hell the purpose of this is?

Maybe let's look at the commit that added this line to find out who added it.
Nice! There is the name of that person. So let's ask him/her? But most probably she or he is not working in your company or your team anymore or has even forgotten what the hell he or she did there. Now you are two people who are confused.
Fortunately, the commit message was well written and explained what the developer was doing at the time.

This is exactly the main purpose of the commit message, it is basically the diary or history of a file. So if you travel back in time, you can see the steps and any changes to this file with comments or a description. It is essentially a change log that you can use to determine the reason for each part of the overall composition of your code. And you can easily do this with appropriate commit messages that describe in a short and understandable way what exactly has changed and why.

Improve your commit messages

Commits are important, but then how can we write the right commit messages instead of the examples above?
Here are some ideas or concepts that could help you write better commit messages:

1. Use a template within a code project

There are many templates that define how you write your commit messages. You can even define the template with your Git configuration:

git config --get commit.template

If you've chosen a commit template, there's probably no real way to decide which template to use. Make sure you sit with your team and think about what suits you best.

2. Agree on a maximum and a minimum character count

While this may sound annoying at first, it can really help you think about the meaning and content of your commit messages to avoid unnecessary or meaningless information.

3. Make it possible to quickly identify the reason of a commit

Clarify the basic types of a commit message, such as Troubleshoot, Feature, Refactoring, etc., which should always be part of each commit message.
There is even an idea how this can be done in a short and elegant way with the help of gitmojis

4. Use a tool to generate your commits

You can also simply use a tool that helps you generate your commit messages. For example commitizen asks you some simple questions and generates a generic commit message for you.

5. Identify your commits

If you are working with Jira or a similar tool that identifies and manages your tasks, define the task ID or number in the commit message. This can help you later identify the task that brought this code.

Conclusion

As a software developer, you will most likely work with other people on a single code base. It is therefore important that the cooperation works as smoothly as possible.
Working on a code base with appropriate commit messages helps you and all other developers who are currently or will be working with the code you have written.

Also, try to find a way to deal with it with your teammates, start discussions about how to structure your commit messages, or try out some tools that might help you do this.
Most importantly, use what suits you best. For example, I'm working on this blog post all by myself, so it's probably a bit useless to be really strict here. Always think of the context.

Use the Inversion of Control pattern with React

Lorenz Weiß — Thu, 16 Jan 2020 20:00:15 +0000

This post was originally posted here

There are many patterns, rules and methodologies in the world of programming.
Sometimes many of them make no sense at first or seem to be revising things to make them more complicated than they should be.
But then, when you take a closer look or use it regularly, you often notice the real advantage of these rules.
Let me explain to you that and how one of them, the inversion of control paradigm, can help you use shareable components in React.

What is the magic behind Inversion of Control ?

The idea of the pattern comes from object-oriented programming in connection with the programming language Java and paradigms such as "dependency injection".
Nowadays, however, not everything is object-oriented anymore and more and more JavaScript developers in particular see more meaning in functional programming.

Not only object orientated

The idea of inversion of control (IoC) not only makes sense for object-orientation, it can be transffered to a lot more such as for React or any other component-based framework with the composition of components. In this article, I want to explain how you can use the pattern not only in Java(script), but also when you want to create a shared UI-component.

But first let's find out what IoC actually means. Let's see what wikipedia says about it.

in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code."

So, what the heck does that mean? Basically it means that a framework, library or any external code is not called by you, rather than it calls your code from inside itself.
To understand the principle a bit better you can read Kent C. Dodds article about inversion of control explained with the filter function of javascript. After reading this the principle it made a lot more sense to me and I thought, wait a second I think this could make also a lot of sense when creating components in react.

How does it make sense to use it in the world of components?

So I was looking at our component library and saw a pattern that could match the inversion of control paradigm.

First, let's do it wrong and look at some code

So let's start with a component. In our case a pretty simple button component.

const Button = (props) => (
  <button class="button">{props.text}</button> 
)

Looks quite simple right? So we can pass any text we want and render it like this:


const Whatever = (props) => (
  <Button text="This is a cool button" />
)

This works fine for this use case, but suddenly we want to have an icon AND a text on a button somewhere. Okay fine then let's add an icon to the props and make it optional.

const Button = (props) => (
  <button class="button">
    {props.icon && (<i class="icon">{props.icon}</i>)}
    {props.text}
  </button> 
)

Mh looks a bit weird but for this use case it's fine... I guess. Oh! now somewhere we start using a button with a subtext below the icon and the text. Okay fine let's add it.

const Button = (props) => (
  <button className="button">
    <span className="upper-line">
      {props.icon && (<i class="icon">{props.icon}</i>)}
      {props.text}
    </span>
    {props.subText && (
      <span class="sub-text">{props.subText}</span>
    )}
  </button> 
)

Phew! I think we made it... Wait what ? There is more ?

const Button = (props) => (
  <button className="button">
    {(props.image && props.imageIsTop) && <img src={props.image} />}
    <span className="upper-line">
      {props.icon && (<i class="icon">{props.icon}</i>)}
      {props.text}
    </span>
    {props.subText && (
      <span class="sub-text">{props.subText}</span>
    )}
    {props.listOfLinks && props.listOfLinks.map((link) => (
      <a key={link.url} href={link.url}>{link.name}</a>
    ))}
    {(props.image && props.imageIsBottom) && <img src={props.image} />}
  </button> 
)

Okay STOP. This is definitely too much code for just one button and may still grow and gets even more complicated with even more conditions and props. We now have at least 10 optional props and conditions to cover all use cases of all buttons in our application.
Nobody will understand them all, and it can be very dangerous to change anything in the logic, and suddenly in one place for this one state, it no longer works as expected.

Inversion of controlling components or calling is now rendering

The principle of IoC says that we don't call the framework, the framework calls us. How does that help us improve our button?
Let us imagine the call as rendering a component. In the example above, we always render the button and pass conditions and props to render the button the way we want. But what if the button renders OUR code?

In react every component gets automatically a prop called children, this prop will be filled with anything you wrap with your component.

It is that easy as it sounds:

const Button = (props) => (
  <button className="button">
    {props.children}
  </button>
)

const Whatever = (props) => (
  <Button>
    This will be rendered as children
  </Button>
)

const WhateverWithIcon = (props) => (
  <Button>
    {props.icon && (<i class="icon">{props.icon}</i>)}
    This will render with an icon
  </Button>
)

So inversion of control in this case means that the Button component itself doesn't care what it renders. props.children can be EVERYTHING, a text and an icon, a text and an image. Everything you want. Because it just renders everything you wrap it with, and the button itself stays fairly small, and you don't have to change the component every time you need a different way of showing what the button should do. Basically, it has superpowers now.

Extend the inversion

But what about the DRY principle ? What if we would have a lot of buttons with icons ? Do we really want to write the whole icon logic again and again?
Why not extend the button to another IconButton component.

const Button = (props) => (
  <button className="button">
    {props.children}
  </button>
)

const IconButton = (props) => (
  <Button>
    <i class="icon">{props.icon}</i>
    {props.children}
  </Button>
)

The IconButton still can wrap everything you want, but also adds an icon to it. But as the name clearly says, we don't make the icon optional. In the end every IconButton needs its icon.
With that we can extend the component how we like it and still be using the inversion of control but do not violate the DRY principle. That's something to impress at a party isn't it?

Conclusion

The inversion of control pattern is very powerfull paradigm, which can be used in quite a few places while programming and makes a lot of shared things or libraries easier to customize and safer to use.
I think especially in the world of react components having more than two or three conditions to display something or not in a component, is a point to think about inverting the control to the one using the component not the one writing it and if you are not sure what to add to the component and what do you want be handled by the use case? A rule of thumb for me is, don't use more than two optional and visual props and if you are using one of them more than two times make it a separate component.

How to setup a global event tracker with vanillaJS

Lorenz Weiß — Fri, 27 Dec 2019 23:36:43 +0000

Today, one of the most important parts of a heavily used website is the ability to track and collect data about the usage and behavior of the users who visit this website. This information helps us to improve our work and to detect and correct mistakes.

To do just that and get some basic data, I wanted to track some of our user interactions in a basic react app. All of them? No, I wanted to start slowly and track only a few and want the list of events to be easily expandable. So the goal is that I can flexibly track when and where a user interacts with our website.

Let's try Redux...

My original idea was to implement a hook in our redux store (yes, it's still implemented with Redux ...) and check if the action is included in my predefined "track action list", and then well ,...track the action.

The big problem with that was that I would be restricted by actions that go through my Redux store and also add more features to Redux, making it more difficult to replace it with another technology at some point.
But I also wanted to track actions like clicking on the sidebar, which does not trigger a redux action.
Basically, Redux was not the best solution ...

The power of vanillaJS

The next idea was a bit more global. I've just added a global click listener at the top of my app. (could be any other event listener like scroll,keydown etc, but in this particular example i just want to focus on a click listener)

// somewhere in the index.js file or any other place.
document.addEventListener('click', (event) => {
  // ... do something with the event
});

With that, I could hook into every click of the user and handle the action.
The big problem with that was that I just wanted to track a specific list of user interactions. Somehow I had to filter the triggered events with a list of defined events and locations.

First, let's check what we can do with the event, the eventlistener gives us.
The event object is pretty big and contains a lot of information, like the position if it's clicked together with a button and, most importantly the target element.

This means that the click event gives us the dom element that the user clicked on, and, what is pretty cool, that this target element object also contains much information about itself.

But how can we differentiate if the element is one of the elements we want to track?

HTML is your friend

HTML and Javascript is a lovestory that goes on for centuries. One of the many reasons of their
unquestioned love is the data-* attribute
With that you can add a property to every HTML-element with a name that starts with "data-"

So, let's do it! Let's say I want to track if the user clicks on the following login button.

<button data-track-id="user_login"> Login </button>

I called the property data-track-id and gave it a unique id. It's very important that it starts with the prefix data- and then something after it, in this case user_login.

But what can we do with it?
Remember the magic event listener object and the target object?
Let's look at it again after the data-track-id is applied.

  ...
  target: {
    ...
    dataset: {
      trackId: "user_login"
    } 
    ...
  }
  ...

Isn't that amazing? I now have my track id in the target object of the the click event. And it's even "camelcased" for us.

Now in the event listener we only need to check if the trackId exists and if its in a defined list of strings.

// defined list of ids we want to track
const trackList = [
    "user_login",
    "user_logout",
    "user_signup"
    // ...
]

// somewhere in the index.js file
document.addEventListener('click', (event) => {
  if (trackList.includes(event.target.dataset.trackId)) {
    track(event.target.dataset.trackId);
  }
});

And that's it. Now I can do whatever I want with the id, send it to an api or notify the user with a toasty.
Just by adding an id to the element and to the list. It's not adding logic or functionality to the components and bundles the controls to one place where I can easily change or add some more stuff to it.