Common Mistakes in Frontend Engineering

From by

Before we start, let me write some disclaimers before anyone going to a conclusion without any context.

  1. I have been in the frontend space since 2010. I still remember being taught to do psd slicing to make a website. Spent years of building websites with plain HTML, CSS3, and jQuery (yes I know, I’m just joking). Then I learnt the React way and it changed my life.
  2. Started working on the Frontend space since 2015 with internship which then followed up full time job in the Bay Area.
  3. These are the common mistakes are based on what I see from other engineers that I encountered along my way in the engineering life. I considered them as mistakes because I experienced it myself, and I ended up suffering from it. That’s why I considered it as my own mistakes that I want people to avoid before going to the same holes of problem.

1. Never ever let the App collapse

Failed due to mapping an object.

How often do you see this during development? A lot I must say; but this thing should never happen in production. You can see the bottom part that this will only be shown in development, but in production it will be just a blank white space.

Most of these mistakes are coming from accessing something that doesn’t exist. Now imagine how often these things happened during production where some data from the backend doesn’t match with your expectation? Now you want to blame it to backend team? No, it’s your fault. Frontend should always handle this kind of thing by having a check to avoid issues like this.

One easy solution that I would suggest is to have default values. This can be interpreted in many ways, but here’s what I’m talking about.

Bad example

Relying on the fact that the object will have an exact match like you stated above is really not a good idea. Say that the structure changed, you’ll ended up with “Error: Trying to access edges of undefined”

Good example

But having it like this (using Lodash’s get for this example) will make sure that even when we don’t have that, it will default to empty array. So then it will just not print anything inside the mapping, but the App doesn’t collapse.

2. Using random number percentage especially when using grid system

This one is one of my pet peeves. Just because you need something needs to be positioned a certain way, I saw many engineers are using random number generator to state how things should be positioned.

Nice percentage you have there

Let’s talk about vertical positioning. If you need that component to be positioned literally in the middle of the screen; first of all, top 50% is not vertically centered. It will take the top 50% of the screen then placed your element right below it. And now imagine people with a smaller screen height, do you still want it to be in the center, or maybe not anymore? Think about those cases first and think of better solution that might exist (hint: flex)

Now let’s talk about the horizontal positioning. This one might be debatable for some people, but let’s discuss it further. And let me get this one out first: If you know exactly that you want it to be positioned 46% from the left on every screen sizes then please do use it. But if your goal is just to put it on the center, again the text might be changing, so it’s not a good idea to just generalize that 46% will be the best number to be put there.

What I would suggest is to stick with fixed number in the most part. Say that you want to have something in the middle which is smaller than 100%. Instead of writing it as width: 90%; might be a better idea to have width: calc(100% — $side-margins); so then with that, you’re thinking forward with different screen sizes and how they would react based on each screen size.

I discussed more examples here if you want to check it out.

3. Usage of zIndex with ridiculous constant number

Many of these mistakes happened during bug fixes; there’s a bug where things should be placed above the other component. What they do is just give a random zIndex until it fixes the issue. Yes it solves your issue, but it creates 10 other problems down the road for other engineers and that’s not cool.

Here’s an example with 5-colored-boxes stack on top of each other. And now because everyone likes to give a random zIndex number, now imagine there’s a bug where the yellow box needs to be placed in between the black and the green one. Now it becomes really hard because of the bad habit of random putting random numbers as the zIndex.

There are many solutions to this problem, but I would like to propose 2 ideas:

  1. Keep the hierarchy in the correct order so we can avoid needing the zIndex for those components. This is because things on the bottom will be printed in the DOM on top. Meaning that you can utilize this fact to correctly place the component so they are in order
  2. Keep a constant file for the zIndex variable, just like saving colors using any CSS preprocessor like Less or SCSS. With that, you can reuse the same zIndex constant to know where things should be placed. Things to consider with this is that you need to have a design system from the designer to decide which components should be placed on top. For example Modal box will have a large zIndex because most of the time it will have to stay on top of any other components that exists.

4. You want to know more about these commons mistakes?

One good idea is to share this kind of knowledge between engineers. Although many of you are doing the same thing, there are different instances where different experiences can help each other to avoid issues like these.

You can also learn from us by joining our Frontend Engineering Team @ Kargo Technologies. We’re hiring!

UC Berkeley Alumni 2015. Frontend Software Engineer in the Software Security Company — working remotely from Indonesia due to H1B!

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