DEV Community: Domagoj Vidovic

Don’t Use Margins For Spacing Between Components, Use Gaps

Domagoj Vidovic — Tue, 07 Dec 2021 15:24:44 +0000

The layout is hard.

There are many different CSS/HTML approaches these days, but most of them are wrong.

"I need to create vertical spacing between components; should I use margins or paddings?"

None.

Let's dive deeper into the organisation of your components on the screen.

The Fall Of Margins

In prehistoric Web times when we had linked documents instead of reusable components, margins made a lot of sense. Let's face it, there wasn't a lot of choices.

Today, in an ideal situation, your Web App should be composed out of reusable components, all the time.

You should be able to pick a component, plug it somewhere in the UI, and it should "magically" work, without any additional styling.

If your layout is set up correctly, mobile design should work out of the box too!

Margins are not great here. Obviously, you can get the job done, but it takes far more effort. It's way less elegant, and harder to maintain.

So, how should we add spacing between those components?

We can just pass margin as a prop, right?

No. Components shouldn't care about spacing between them.

Their parents should.

Adding Some Gap

Our layout can be magical and powerful with flex and grid.

Let's say we have multiple components and want to have 3 in each row. Also, spacing between them should be 1rem.

Components don't care about that. Only the parent does:

.parent {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 1rem;
}

And that it! Whichever component we stick here, it will magically work (if we don't have a large min-width set on them).

What about tablet and mobile designs? The tablet should display 2 items per row, and mobile just 1.

Well, we just need to add 2 different media queries; one with grid-template-columns: 1fr 1fr; for tablet, and grid-template-columns: 1fr; for mobile.

And our layout will work all the time with just a few simple lines!

gap is a replacement for all various combinations of parent + child selectors and margin top/right/bottom/left.

When To Use Margins?

We don't want to make unnecessary wrappers for all of our elements, and many of them need spacing between. What should we do?

If you style pure HTML elements, margins are acceptable here.

I still encourage you to structure them with grid/flex and use gap, but sometimes it's just not so easy to do that without adding additional wrapper elements.

So, this should be enough to make a decision:

Can you add spacing without adding extra elements, with grid/flex + gap?

If yes, do it.
If not, use margins.

Remember, this is true only for pure HTML elements. You never want to have margins on your components. A parent should always take care of their positioning on the screen. grid/flex + gap is the most elegant and powerful option here.

Also, a valid use case is when the spacing between the components is different. Selecting a child component in a .parent .child {} format and adding a margin makes a lot of sense.

But if you have too many different spacings, you need to ask yourself - is there a problem with the design itself?

Pros and Cons

Let's take a look at the pros first.

Your overall architecture will be much cleaner.
grid and flex are powerful. All scenarios like element wrapping, overflow, and much more will be covered.
Responsive design works out of the box. It's so easy when you don't need to switch from margin-left to margin-top for mobile layouts.
Instead of calculating the position of every element relative to each other, the parent will always do it with a clear picture of a whole system.
Your CSS will be much cleaner. You won't need those ugly classes where you target everything instead of the last element because you don't want to add margin-bottom to the last item in the list.
Your components will be completely reusable because they won't have any spacing by default.
This whole system will be way easier to maintain and extend.

It's kinda like the plug and play system.

With margins, it's the plug, adjust, and then play system.

We don't want that extra adjustment step.

Are there any cons? Well, both yes and no. The only one I can think of is gap not supported by IE11.

But you know what? Google search has dropped support for IE11. And you should too.

Let your layout become something you're so proud of. We're building a system of components here and gap is just perfect for it.

How To Create Beautiful Link Previews For Every Platform

Domagoj Vidovic — Mon, 08 Nov 2021 17:05:42 +0000

You've been working hard on your web app.

It's finally done. You are proud of it and want to share it.

But after pasting a link to Twitter, your link preview is so broken. Only the title is correct, everything else is missing.

The first impression everyone will have about your app — is bad.

Let's fix that.

After reading this article, you will be able to:

Have a correct image, title, and description.
Make it work properly on all platforms.
Have different previews depending on the shared page.

And it's all so simple.

Mystical Meta Tags

<meta> tags in your HTML files have many use cases — one of them is to set up preview data properly.

There are eight most common attributes you need to set to make it look properly in 99% of the cases:

title
description
og:title
og:description
og:image
twitter:title
twitter:description
twitter:image

If twitter is missing, it will fall back to og; but still, it's great to include it.

First, you need to set up the correct meta tags in your index.html file:

<head>
  <title>Your Title</title>
  <meta property="og:title" content="Your Title" />
  <meta name="twitter:title" content="Your Title" />

  <meta name="description" content="Your Description" />
  <meta property="og:description" content="Your Description" />
  <meta name="twitter:description" content="Your Description" />

  <meta property="og:image" content="img_url" />
  <meta name="twitter:image" content="img_url" />
</head>

And now, you'll have the correct previews when you share your page.

But what if you want different previews for different pages?

Updating The Meta Tags

Updating meta tags is a straightforward process. You can use external libs for that (e.g. React Helmet if you use React), but I'll share my own pure JS solution.

Let's say we want to update the title. This code does exactly that:

// update og:title
document
  .querySelector('[property="og:title"]')
  .setAttribute('content', yourTitle);
// update twitter:title
document
  .querySelector('[name="twitter:title"]')
  .setAttribute('content', yourTitle);
// update the "regular" title
document.title = yourTitle;

It's quite similar for description and image.

But we don't want to use it in this way. Let's create some helper functions!

setTitle(title) {
  document.title = yourTitle;
  document.querySelector('[property="og:title"]').setAttribute('content', title);
  document.querySelector('[name="twitter:title"]').setAttribute('content', title);
}
setDescription(description) {
  document.querySelector('[name="description"]').setAttribute('content', description);
  document.querySelector('[property="og:description"]').setAttribute('content', description);
  document.querySelector('[name="twitter:description"]').setAttribute('content', description);
}
setImage(image) {
  document.querySelector('[property="og:image"]').setAttribute('content', image);
  document.querySelector('[name="twitter:image"]').setAttribute('content', image);
}

It's that simple.

Ideally, you can create a helper setMetadata and call it after your page gets mounted:

setMetadata(metadata) {
  setTitle(metadata.title)
  setDescription(metadata.description)
  setImage(metadata.image)
}

But there is one trick.

This won't work properly because the metadata is updated on the client. Meaning, you need to download the app first and parse and execute the JS to update the meta tags.

You might think that you need to set up a separate server to have correct previews for the different pages. Luckily, you don't have to!

There is a simple solution.

Let's Prerender

Prerender.io is an amazing tool that will simulate serving a static HTML page to the crawlers.

So, instead of just improving your preview links, this will also boost your SEO. Woohoo!

The process is simple.

First, you need to create an account there (it's free!).

Then install prerender-node package.

They have nice docs, but the only thing you'll probably need to do is add this line to your express app (probably to your server.js file):

app.use(require('prerender-node').set('prerenderToken', 'YOUR_TOKEN'));

You can get 'YOUR_TOKEN' from prerender.io after you register.

Commit your changes, deploy them, and you're ready to go!

Making Sure It Works Properly

You can paste your link to all the platforms and check it manually, but there are much better tools for that. For example, Social Share Preview.

Just paste your URL there and see the preview. If you missed something, the tool would let you know what you're missing.

There are many other tools that do the same trick, google them if this isn't enough for you.

Conclusion

You have it now; your preview links look beautiful on all the platforms!

I just wanted to add that you might have some specific use cases not covered with this tutorial. It's all fine — just google the problem and find a specific meta tag you need. Then, update it with pure JS.

Happy previewing!

This post was originally published on Dom's personal blog. Check out dat new amazing blog design there ✨

Set Up Blazing Fast Frontend Development Experience With Vite

Domagoj Vidovic — Mon, 01 Nov 2021 15:34:36 +0000

Your production app is huge.

You hit npm run dev to start your development server.

After 1 minute, it's there! You can start your dev journey.

Although 1 minute doesn't seem like a long time — for us devs, it is. We are nitpicky and want everything instantly.

Luckily, there's a brand new tool that allows us that.

I present you — Vite.

What is Vite?

Vite is a build tool that provides a blazing fast development experience.

Vite is a french word for "quick", and it's pronounced /vit/ (not white!).

It's created by Evan You, the same guy who created Vue.js.

That doesn't mean that Vite is only for Vue.js — it's framework agnostic!

Why Is It So Fast?

If you don't care about this and just want to set up Vite, just skip this section.

If you're still with me, amazing! I have a few history lessons for you.

Webpack, the most popular build tool today, was released in 2014.

Back then, browsers didn't support native module imports, so bundling the files made sense.

Not anymore in 2021.

It's an expensive process.

Plus, every time you update a single file, you need to update the whole bundle to see the change on the screen.

That's why Hot Module Reload can sometimes take many seconds!

Vite uses the power of native module imports, making your Hot Module Reload instant.

There are still some deeper reasons why it is so fast, so if you're interested, check out their website. But now, let's set up the app!

Setting Up Vite… Is Simple And Fast As It Sounds

There's only one prerequisite: Node version >=12.0.0.

After it, you're all good!

Open your terminal and type:

npm init vite@latest

Then, you have steps:

Project name
Framework (Vanilla JS, Vue, React, Preact, Lit, Svelte)
Typescript or pure JS

And that's it!

Now, you need to go to your project folder:

cd <YOUR_PROJECT_NAME>

Install the dependencies:

npm install

And start the development server:

npm run dev

Here's what happens next:

It's ready in less than 0.3 seconds. That's insane!

Just for a comparison, the same app made with VueCLI + Webpack takes 10s initially. This makes Vite 39x faster!

I won't even talk about the speed after the app gets bigger.

And Hot Module Reload is — instant.

Webpack takes around 2–3 seconds (initially), and up to 5 seconds for massive apps.

Conclusion

What do you think about Vite?

New Frontend tools come out every day, but I can't remember when was I excited as this. I believe this could radically improve our already great Frontend development experience.

Have you tried it yet?

This post was originally published on Dom's personal blog. Check out dat new amazing blog design there ✨

Position Absolute and Relative — The Simplest Guide

Domagoj Vidovic — Mon, 25 Oct 2021 14:51:45 +0000

I remember the time when I was starting my Frontend journey.

CSS caused a lot of headaches. Like most people, I assumed that it's easy. Then, I was annoyed when I couldn't get it working.

My usual flow was:

Detect a problem.
Google it.
Find a solution on StackOverflow.
C/P it without any understanding.

Position absolute and relative were properties I often encountered. "What the heck are they?"

They should be used far less often than you might use them, and when used properly, they are quite simple.

Let's dive deeper into the topic.

How Are Position Absolute and Relative Related?

Usually, all elements follow the DOM flow.

But sometimes, you need to break that flow and tell an element exactly where to go.

Let's say that I have this HTML page:

The code is quite simple:



<div class="bordered-container">
  <div class="absolute-item" />
</div>



body {
  display: flex;
  align-items: center;
  justify-content: center;
  height: 100vh;
  background: linear-gradient(
90deg, rgb(153, 253, 103) 0%, rgb(88, 255, 228) 100%);
}

.bordered-container {
  width: 600px;
  height: 300px;
  border: 2px solid black;
}

.absolute-item {
  width: 40px;
  height: 40px;
  background-color: red;
}

I want to absolutely position my absolute-item right now and tell it exactly where to be. I want it to be always inside the bordered-container; 10px away from the bottom, and 30px from the right.

Let's add the code:



.absolute-item {
  position: absolute;
  bottom: 10px;
  right: 30px;
  width: 40px;
  height: 40px;
  background-color: red;
}

The result is:

It's, obviously, not what we wanted. The square is positioned 10px/30px away from the edge of a whole document, not the bordered-container!

That's why we need position: relative;.

It's Not Black Magic

Whenever you set position: absolute; to an element, it must be positioned relative to something.

Your absolute element will look for the closest parent with position: relative;, and position itself relative to it.

If there are no elements like that, it will be positioned relative to the body element. This happened in our previous case.

To fix this, we simply need to add position: relative; to our bordered-container:



.bordered-container {
  position: relative;
  width: 600px;
  height: 300px;
  border: 2px solid black;
}

The result is:

Yep, it's that simple.

What The Heck Is Z-Index?

When dealing with absolute positions, you might encounter on z-index, so it's worth mentioning.

I'm sure that you've tried setting it to 9999 but it still didn't work.

z-index is used when you have multiple absolute position elements.

The absolute positioned element with the biggest z-index will go on the top. The one with the lowest, on the bottom.

That's it.

Let's keep it simple.

The Downsides Of Position Absolute

Absolutely positioned elements break the DOM flow.

They don't take any physical space on the document.

That means that the elements above/below could overlap with, even if you don't want it.

This can become tricky to maintain.

Our elements should be isolated, if we change one of them, we don't want to adjust everything else.

That doesn't mean position: absolute; is bad! It means that it has its own use cases and you need to know about them.

When To Use It

If you need to adjust the layout within a page or a component, you should avoid position: absolute; in 99% of the cases. Opt-in for Flexbox or Grid instead.

However, if you want to add a badge to your image, it's just perfect. You always want the badge to be on the top (or the edge) of the image, so that it seems like it's a part of an image.

Or if you want to stack a few images/elements onto each other. There's no way other than position: absolute;.

And that's the ultimate guide: use absolute positioning only when there's no other way to achieve that.

Conclusion

Absolute positioning is powerful, and the Web wouldn't be able to look this way without it.

If used properly, it's a charm.

But those use cases are quite rare. If you use it often, you will make your app a hell to maintain.

If you find a StackOverflow answer with position: absolute;, try to skip it. Keep looking. Is there any other way to do it?

If so, avoid the absolute.

This post was originally published on Dom's personal blog. Check out dat new amazing blog design there ✨

11 Reasons Why Software Engineering Isn’t a Stressful Job

Domagoj Vidovic — Tue, 14 Sep 2021 15:19:30 +0000

Everyone talks tech these days.

Software engineers are being raised to the skies in terms of their abilities and work complexities.

But sometimes, it feels like we forget about all the other professions. We ignore their difficulties by focusing on our own.

Instead of that, let’s focus on the positive sides and acknowledge that our job isn’t stressful.

1. We can prioritize time

A major cause of stress is uncertainty. If you don’t know you’ve worked well or done enough work, you could be stressed.

I don’t know the processes inside your company, but it’s highly likely that you set your bi-weekly/weekly/daily priorities for everyone.

That’s said, you know exactly what you should work on. Thereby, you can prioritize it.

When I was starting my career, I didn’t know how much is enough. OK, so I did 4 tasks today; should have I done 6 of them?

Those questions caused stress.

Today, I plan my work in the morning before I start with anything.

When I’m done with it — I’m done! I often grab something else to do, but I’m not stressed about it. I know that I did everything I should have.

On rare occasions, some extra work might pop in and disrupt our plan. You need to learn to adapt it too, and not care about the overhead.

We are almost completely in control of our day-to-day work; we can put it on paper and schedule it.

2. The demand for us is ridiculously high

You can be stressed because you don’t like your job. Or, you might think that you’ll get fired.

But become aware: everyone needs software engineers.

We need to build this invisible world and there are no limits. We’ve just started.

On a typical week, I receive ~10 email/LinkedIn messages from recruiters, with the best offers on the market.

That means that we can go wherever we want, do whatever we like. There are so many options, and everyone’s grabbing for us.

There’s not enough of us, we’re exclusive.

We know that we’ll do well, all the time.

3. Flexibility is underrated

My company offers a free subscription to the co-working spaces in London. Some of those locations are the best in the whole city.

Because of it, I worked at The Shard yesterday, London’s highest skyscraper.

Last week, I was in Croatia, working remotely from the beach.

Today, I’ll work from home and go to the rooftop at some point because the weather is so nice.

And on Thursday, I’ll go to the office because everyone will be there and we’ll have drinks after.
We can do whatever we want. The only important thing is to finish your work. If you bring value, nobody cares where you are or when you started.

4. Work-life balance just rocks

Let’s face it — Software Engineering is a highly paid job. Sometimes it’s right on par with Lawyers, Doctors, and Investment Bankers.

However, those guys can sometimes have crazy working hours; 80 per week and even more. And I haven’t even mentioned the night shifts.

What about us?

Well, after our 8 hours, we can go wherever we want — especially if we did everything we needed.

Sure, sometimes deadlines force you to work a bit more — but it’s nothing compared to the other highly paid professions.

Even the low-paid ones have a much worse working balance.

Again, we’re in a sweet spot.

5. Everyone is just joking around

I’ve been working with 5 different companies so far — and all of them were having fun all the time while working.

Sure, there are some serious moments, but most of the time it’s just laughing, making jokes, sending random images, GIFs, and reactions on Slack.

Not that we don’t work — we’re incredibly efficient. However, we feel better this way and enjoy our work more; that way, we work even better.

And how about those random beers during work hours, or meetings that turn out to the joke warehouse? All of our socials?

I sometimes feel like we’re all just smart children — doing great work and laughing all the time.

6. All of our problems are solved online

The community we live in is incredible.

Need to build something? Google it.

Have an error? Paste it to Google.

Can’t find the answer? Ask it on StackOverflow.

Finding the right solution is a valuable skill. But we have that option. We can find help anywhere.

Even if we can’t do it online, we’ll ask our team members for it.

7. The best tools are free

Our friends from other professions have to pay crazy subscriptions to use some tools. It can be $10k+ per person, just to use something that we created!

I’m a Frontend Engineer; let’s see how much I need to pay for my tools.

VS Code? Free.

Vue/React/Angular/Svelte? Free.

JavaScript/HTML/CSS? Free.

Git? Free.

Powerful extensions? Free.

Let’s face it, almost everything’s free.

We obviously need to pay for hosting services like AWS, but almost everything until that point is free.

We can experiment as much as we want and create prototypes with zero expenses.

Ask other, non-CS engineers how costly their prototypes are.

8. Our equipment is so cheap and light

I’m probably an exception — I use only my MacBook Pro to work, without any external monitors, keyboards, or anything else.

But let’s say I want all those things. Even with them, the cost of equipment wouldn’t go above $2000-$3000, and I’m talking about the best devices on the market.

Everyone else has similar costs because everyone needs a laptop or PC. However, they need a lot more expensive subscriptions and ridiculously expensive equipment.

Science, Mechanical Engineering? The costs can be $1M+ for those.

And you have to be in the office to use it most of the time.

9. We all speak the same language

The best coding practices are the same across the globe.

We all speak English because of resources; the code is in English itself. That’s why we don’t have any obstacles in communication.

Our skills are so valuable because they can be applied anywhere. So unique, but also so general. It’s insane.

10. Oh, that salary

Money is important.

Most of the things you have and use right now were exchanged for money.

But not only material ones; all the wonderful experiences like traveling, eating, dating, and much more.

Software engineering gives us the ability to experience the world whatever we want like. We don’t have to stress about the money.

I moved to London recently, one of the most expensive cities in the world, and I can live an amazing life in a top location without thinking about the costs too much.

I even have enough money for investing a decent amount every month.

Not only that — what about equity and bonuses? That can end up being higher than the base salary itself.

Because of high compensations, banks will give us a mortgage easily. We’re their top customers! So we can easily buy ourselves homes or invest that money.

Don’t forget — we earn a lot. People in their twenties will probably earn more than others ever will in their whole lives.

11. We can see our impact immediately

I create a feature, merge the code. Using the benefits of CI/CD, this feature is shipped to the customers in 1–2 hours.

I can see them using it immediately! Something that I made is making others so happy!

It’s motivating. It’s meaningful.

Even if it’s not shipped to customers, we have a feeling that we created something every day.

Conclusion

We live in amazing times. This is the gold rush of modern time.

But instead of mining, you need to learn to code.
Sure, it can be tricky. It can be hard. It can be exhausting.

But most of the time, we’re just making jokes and doing great work. From anywhere in the world.

Let’s face it, we don’t have too many reasons to be stressed. If we are, we need to take control over it.

Because we can.

Loving my work? Feel free to buy me a croissant. It's such a motivation boost. You rock.

A Ridiculously Simple Way For Creating Responsive Web Apps

Domagoj Vidovic — Wed, 08 Sep 2021 14:34:15 +0000

I remember my first encounter with responsive design. Before any investigation, it seemed incredibly complex.

The same app runs and behaves differently based on so many types of user devices?

I have to cover all the screen sizes, from ultra-wide monitors, over laptop and tablet devices, all the way to the smartphones?

Mate, that must be a nightmare.

But honestly, it isn't.

Responsive design is nothing more than a bunch of if statements.

Let's dive deeper into the topic.

Two Types of Design

Depending on what you create, you have two choices:

Mobile-First Design
Desktop-First Design

Mobile-First Design means that you first design and create software for mobile devices, and then extend it to desktop devices.

It assures that your core functionality will be available on a mobile device.

It's easy to add more functionality on the bigger screen, but it's hard to strip away functionality and keeping the core while going to a smaller screen.

According to this research, 68.9% of websites visit came from mobile devices.

If you're creating a consumer app, Mobile-First Design is likely to be your choice.

Complex B2B solutions require Desktop-First Design, and sometimes don't even have a fully functioning mobile solution - they're just too complex.

That's why I'll focus on Mobile-First Design in this article.

The Design

We'll keep this simple. Let's say that you have a number of items you want to display on your feed. It will look something like this:

Mobile design

We have two components here:

Parent component, container
Child components, items

If we ignore the CSS code for everything except the layout, it will look something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  </head>
  <body>
    <div class="container">
      <div class="item">Item 1</div>
      <div class="item">Item 2</div>
      <div class="item">Item 3</div>
    </div>
  </body>

  <style>
    .container {
      display: grid;
      grid-template-columns: 1fr;
      align-content: flex-start;
      gap: 16px;
      padding: 16px;
    }

    .item {
      padding: 88px 16px;
    }
  </style>
</html>

Can you see the meta tag, <meta name="viewport" content="width=device-width, initial-scale=1.0">?

It's incredibly important and there's no responsive design without it. Without it, your browser won't know the initial zoom and it will look really bad on mobile devices.

Doing the Magic to Make the Desktop Work

Just joking, this is no complex magic. As I've said, just a bunch of if statements!

We're trying to spread the items, keeping 3 of them in each row:

Desktop design

The code looks like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  </head>
  <body>
    <div class="container">
      <div class="item">Item 1</div>
      <div class="item">Item 2</div>
      <div class="item">Item 3</div>
    </div>
  </body>

  <style>
    .container {
      display: grid;
      grid-template-columns: 1fr;
      align-content: flex-start;
      gap: 16px;
      padding: 16px;
    }

    .item {
      padding: 88px 16px;
    }

    @media (min-width: 992px) {
      .container {
        grid-template-columns: 1fr 1fr 1fr;
      }
    }
  </style>
</html>

We're finally here, introducing @media queries.

Let's read this in a simple, already familiar way:

if (screen width is bigger or equal than 992px) {
    apply styles in the same way as before
}

And that's it! Nothing more than this! The styles here will affect only screens wider than 992px.

How About Tablet?

You can combine media queries with logical operators.

Yep, you can do something like:

@media (min-width: 768px) and (max-width: 991px) {
    // styles
}

And those styles will affect everything in range from 768px to 991px.

Remember, this is nothing more than an if statement.

How to Cover All Devices

Media queries are much more than just min-width and max-width.

You can check stuff like orientation, aspect-ratio, and much more.

You can use logical operators like or, not, and all the others.

But to be honest, what you've read in this article is enough for an amazing and simple start.

You probably won't need most of the other queries anyway. Maybe in some rare scenarios. By then, your knowledge about queries will be so powerful that complex queries will be a joke!

Loving my work? Feel free to buy me a croissant. It's an incredible boost to my motivation.

Check out the bottom of the originally published article on Medium for the best course around responsive web.

All CSS Properties You Need to Know to Build a Website

Domagoj Vidovic — Mon, 23 Aug 2021 15:34:00 +0000

Whether you're at the beginning of your CSS journey or somewhere else, you got to admit - a number of CSS properties is massive.

And it's easy to confuse yourself in that vast sea.

You're copying code from StackOverflow until you find a solution that fits. But how will that scale? Why does it even work?

Most of the time, you don't care about the answer. You just focus on the result.

When building a website, some of the CSS properties are must-haves; yet, it's hard to recognize them.

This article exists to help you solve the most common CSS problems while building a website.

Let's dive into properties you cannot avoid.

1. display: flex;

Do you need to center an element?

Googling that will likely offer tens of different solutions; however, you'll need only one most of the time.

.your-class-name {
  display: flex;
  justify-content: center;
  align-items: center;
}

display: flex; will align your child elements one next to each other in a horizontal row. Tip: you can add flex-direction: column; to change it to a vertical row.

flex-direction determines your main axis. Default value is row.

justify-content: center; will align the items on your main axis. That means the item will be horizontally centered for our code snippet.

align-items controls your cross axis, i.e. your elements are vertically centered.

You can pass many attributes here, but I'll mention only one: justify-content: space-between;. This will distribute the elements across the row without any margins at the beginning or end.

2. margin

This property will determine the distance between certain elements.

.your-class-name {
  margin-top: 16px;
  margin-right: 12px;
  margin-bottom: 16px;
} 
// shorthand
.your-class-name {
  margin: 16px 12px;
}

You can directly connect properties with sides by doing margin-top, margin-right, etc., or cover everything with a single margin property:

margin: {{ top }} {{ right }} {{ bottom }} {{ left }};

If you omit bottom, it will inherit top (check out our example)! If you omit left, it will inherit right.

3. padding

At the first glance, padding looks similar to margin.

The syntax is identical as margin too; shorthand as well.

Why do we need it then?

Imagine that you have a physical suitcase. You want to write something on the case.

However, you don't want to start writing in the top-left corner. You want to indent your text a bit.

For that, you will use padding. Padding influences the inside of our element.

However, if you have two suitcases next to each other and you want to make a distance between them, you'll use margin for that.

4. background-color

This one is pretty simple and an absolute necessity. You can apply this property to most of the HTML elements.

background-color: blue;
background-color: #232323;
background-color: rgb(255, 255, 128);
background-color: rgba(255, 255, 128, 0.5);

Attributes can vary: from a simple color name, over its HEX value, to the RGB (even HSL).

RGBA is interesting here because instead of just setting a color, you can also set the opacity. Seeing that 0.5? That means that transparency will be 50%.

5. color

color is similar to background-color; the only difference is that it influences the text's color. Everything else is the same, transparency included.

6. opacity

But we can make anything transparent!

opacity: 0.1; // 10% visibility
opacity: 0.9; // 90% visibility

This is useful for disabled states or interesting effects.

7. width

This is a tricky one. Most of the time, you don't want to have fixed widths. Your design should be responsive and you can accomplish that with margins and paddings.

However, sometimes you need to be fixed. Maybe you want to set your icon with to 24px?

Or look at this article. Try to zoom out of the page. You'll see that it won't go from edge to edge.

That's because the whole page has max-width property. Useful to wrap your website with it.

8. height

height is much simpler than width due to the nature of our scroll direction.

However, you'll still want to use as few fixed heights as possible. One example where you could is your header.

All the other caveats like min-height and max-height exist here too.

9. cursor: pointer;

Hover over any button on this page. Can you see how the cursor changed into a little hand?

cursor: pointer; is the reason for that. Whenever you can induce any actions (buttons, links, etc.) you need to use it.

10. font-size

This one is pretty simple and controls the sizes of your font. If you're an absolute beginner, I recommend using only px here.

However, if you want to dig deeper, investigate rem. Basically, you set your default font size in px, and all the other fonts will be relative to that base value.

For example, if your base value is 16px, 2rem will be 32px.

11. font-family

You want different fonts, right? Google Fonts are impressive and it's so easy to pick one of them, include them in your index.html, and add its name to font-family.

12. :hover

This will add any effects to a certain element on hover.

.your-class-name:hover {
  cursor: pointer;
}

Our example will change the cursor to a pointer.

Conclusion

What if I told you that you'll solve most of your CSS problems with these 12 properties?

Sure, you'll maybe need a few more depending on your case, or you'll need to dig deeper into some of those.

But this is enough to build a solid-looking website.

Check out the bottom of the article originally published on Medium for the best CSS courses!

14 VS Code Shortcuts to Supercharge Your Productivity

Domagoj Vidovic — Tue, 27 Jul 2021 15:28:48 +0000

We, software engineers, tend to be extremely efficient beings.

Our goal is to optimize everything, not just the code.

That's why we don't want to spend 10 seconds looking for something on the GUI. We don't want to spend even 2 seconds.

Why would we, when we can do it in 0,1s by using the powerful keyboard shortcuts?

If I repeatedly do the same actions, I always Google for its shortcut. Usually, I find it.

Let me share with you the shortcuts I use every day. I bet you don't know many of them!

1. Search files by name

Ok, we'll start by listing the most common and simples shortcuts.

cmd + P (Mac) / crtl + P (Windows) will open a search field with an incredibly powerful fuzzy search. I probably use this 100+ times a day.

2. Search settings

This one is similar; after clicking cmd + P (Mac) / crtl + P (Windows), just type >. You can now type in any search term, and only settings will be affected.

3. Multiple cursors

This feature is so cool, I wish I could use it everywhere else!

Just press alt and start clicking around the editor. Multiple cursors will appear!

4. Multiple cursors v2

You can do something similar without clicking around. cmd option + arrow down (Mac) / shift alt + arrow down (Windows) will insert an extra cursor below.

Obviously, you can use arrow up to insert a cursor above.

5. Select all occurrences

This one is quite uncommon, but it's extremely powerful! First, you need to select some text.

Then,cmd shift + L (Mac) / crtl shift + L (Windows) select all occurrences of that text. It's so useful for situations like renaming a variable across the file:

Imagine manually renaming a variable repeated 30 times in the file. Nightmare.

6. Delete a line

cmd shift + K (Mac) / crtl shift + K (Windows) does the trick here.

7. Duplicate a line

Put your cursor in the line you want to duplicate.

Press cmd + C, then cmd + V (Mac) / crtl + C, then crtl + V (Windows). Voila!

8. Search in a file

This one is quite familiar across all the common apps (like browsers): cmd + F (Mac) / crtl + F (Windows).

cmd + G (Mac) / crtl + G (Windows) search for the next occurrence, while cmd shift + G (Mac) / crtl + shift + G (Windows) search for the previous one.

9. Replace in a file

If you want to replace the term you searched for, fire cmd option + G (Mac) / crtl shift + G (Windows).

Then, click enter to replace the current occurrence.

If you want to replace them all, click cmd + enter (Mac) / crtl + enter (Windows).

10. Search in all files

Nothing can exist without a good old search in all files.

cmd shift + F (Mac) / ctrl shift + F (Windows) does the trick.

If you want to match text by case, press cmd option + C (Mac) / crtl shift + C (Windows).

You can also match the whole word by pressing cmd option + W (Mac) / crtl shift + W (Windows).

11. Replace in all files

Do you want to replace all occurrences in all files across the project, i.e. search/replace?

Amazing, cmd option + H (Mac) / crtl shift + H (Windows) does the trick.

cmd option + enter (Mac) / crtl alt + enter (Windows) triggers the replacement.

12. Split editor

One tab is not enough, you need many of them! Great, just press cmd + \ (Mac) / alt shift + 0 (Windows). Repeat until you're satisfied.

13. Close tab

This one is the same as in Chrome - cmd + W (Mac) / crtl + W (Windows).

14. Switching between opened tabs

Do you want to open the previous tab? crtl + tab does the trick.

Do you want to go to a tab on a known position? crtl + [index] does that.

Finally, you can pick the tab on left/right by pressing cmd option + arrow left/right (Mac) / crtl page down/up (Windows).

Conclusion

I wouldn't suggest learning all of them by heart immediately - try with one or two of them, and slowly adapt them to your work.

Save this article in case you want to revisit it later.

Using more keyboard shortcuts will increase your productivity.

And oh, it does feel so good.

11 Git Commands I Use Every Day

Domagoj Vidovic — Thu, 15 Jul 2021 15:48:36 +0000

When I started my career, I was always afraid of losing my code changes. Sometimes, I would copy the code to text files just to be sure that I won't miss something.

That's not a great practice. If you know how to use git properly, you won't have these doubts.

Git has everything you need to make you safe. And much more.

Let's dive in.

1. Checking out a new branch

Obviously, I must use a new branch for every task I start:

git checkout -b <new_branch_name>

This command creates a new branch and automatically sets it as active.

2. Selecting files for commit

This is one of the rare cases where I prefer GUI. In VS Code (or any other better IDE/text editor), you can easily see the updated files and select the ones you want to include in the commit.

But in case you want to do it with the CLI:

git add .

This command will stage all changed files.

If you want to select a single file:

git add <path/to/file>

3. Making a commit

After you stage some files, you need to commit them:

git commit -m "Some changes"

In case you have some pre-commit rules turned on which doesn't allow you to make a commit (like linting), you can override them by passing the --no-verify flag:

git commit -m "Some changes" --no-verify

4. Revert all changes

Sometimes, I experiment with the code. A bit later, I realize that it's not the right path and I need to undo all of my changes.

One simple command for that is:

git reset --hard

5. See the latest commits

I can easily see what's going on on my branch by typing:

git log

I can see the commit hashes, messages, authors, and dates.

6. Pulling the changes from the remote branch

When I checkout an already existing branch (usually main or development), I need to fetch and merge the latest changes.

There is a shorthand for that:

git pull

Sometimes, if you're in one of your newly created branches, you'll also need to specify the origin branch:

git pull origin/<branch_name>

7. Undoing a local, unpushed commit

I made a commit. Damn! Something's wrong here. I need to make one more change.

No worries:

git reset --soft HEAD~1

This command will revert your last commit and keep the changes you made.

HEAD~1 means that your head is pointing on one commit earlier than your current - exactly what you want.

8. Undoing a pushed commit

I made some changes and pushed them to remote. Then, I realized it's not what I want.

For this, I use:

git revert <commit_hash>

Be aware that this will be visible in your commit history.

9. Stashing my changes

I'm in the middle of the feature, and my teammate pings me for an urgent code review.

I obviously don't want to trash my changes, neither I want to commit them. I don't want to create a bunch of meaningless commits.

I only want to check his branch and return to my work.

To do so:

// stash your changes
git stash
// check out and review your teammate's branch
git checkout <your_teammates_branch>
... code reviewing
// check out your branch in progress
git checkout <your_branch>
// return the stashed changes
git stash pop

pop seems familiar here? Yep, this works like a stack.

Meaning, if you do git stash twice in a row without git stash pop in between, they will stack onto each other.

10. Reseting your branch to remote version

I messed something up. Some broken commits, some broken npm installs.

Whatever I do, my branch is not working well anymore.

The remote version is working fine. Let's make it the same!

git fetch origin
git reset --hard origin/<branch_name>

11. Picking commits from other branches

Sometimes, I want to apply the commits from the other branches. For this, I use:

git cherry-pick <commit_hash>

If I want to pick a range:

git cherry-pick <oldest_commit_hash>^..<newest_commit_hash>

Conclusion

Let's be honest, I don't use all of these commands literally every day - but I use them really often.

I prefer the CLI because we'll never be able to cover all the options with a GUI.

Plus, you'll find most of the tutorials only using the CLI. If you're not familiar with it, you'll have a hard time understanding them.

I covered the basics here, but whatever you need to do, just Google it.

I'm certain that you'll find an answer easily.

How To Structure a Massive Vuex Store for a Production App

Domagoj Vidovic — Mon, 12 Jul 2021 16:47:22 +0000

When looking at Vuex tutorials, you can see most of them are quite simple.

The logic is explained well, but scalability suffers. How will this work in my production app?

Here’s a simple store example from Vuex official docs:



import Vue from 'vue'
import Vuex from 'vuex'

Vue.use(Vuex)

const store = new Vuex.Store({
  state: {
    count: 0
  },
  mutations: {
    increment (state) {
      state.count++
    }
  }
})

A simple store

There’s no need to explain this. I assume that you already have some Vue and Vuex knowledge prior to this article.

My goal is not to explain what a store, state, or mutations are.

Instead, I want to show you a massive store with 1,000+ state attributes, mutations, actions, and getters.

I want to teach you how to structure the store for the best maintainability, readability, and reusability.

It can have 100,000+ attributes. It would still be clear.

Let’s dive in.

Meet Modules

As we already said, keeping everything in one file will create a mess. You don’t want a 50,000+ LOC file. It’s the same as keeping your app in one component.

Vuex helps us here by dividing the store into modules.

For the purpose of this example, I will create a store with two modules. Note that the process is the same for 100+ modules, as well as 100+ actions, getters, and mutations within every module.




const userModule = {
  namespaced: true,
  state: () => ({}),
  mutations: {},
  actions: {},
  getters: {}
}

const organisationModule = {
  namespaced: true,
  state: () => ({}),
  mutations: {},
  actions: {},
}

const store = new VueX.Store({
  modules: {
    user: userModule,
    organisation: organisationModule
  }
})

store.state.user // -> `userModule`'s state
store.state.organisation // -> `organisationModule`'s state

Updated store

The namespaced attribute is incredibly important here. Without it, actions, mutations, and getters would still be registered at the global namespace.

With the namespaced attribute set to true, we divide actions, mutations, and getters into the modules as well.

This is really helpful if you have two actions with the same name. Having them in a global namespace would create clashes.



const userModule = {
  namespaced: true,
  state: () => ({}),
  mutations: {},
  actions: {
    'SET_USER'() {},
    'SET_USER_LOCATION'() {}
  },
  getters: {}
}

store.state.user['SET_USER']() // correct ✅

stote.state['SET_USER']() // wrong ❌

Namespaced module

As you can see, the module is completely “local” right now. We can access it only through the user object on the state.

Exactly what we want for our massive application.

Cool, now we have a store divided into modules!

However, I don’t like the hardcoded strings for actions. It’s definitely not maintainable. Let’s address this issue.

Types To Save You From Headaches

We don’t just want to access every property from every module in every file. That sentence sounds like hell.

We want to import them first. Then use mapGetters, mapActions, or mapMutations to achieve that.



// userModule.js
export const SET_USER = 'SET_USER'
export const SET_USER_LOCATION = 'SET_USER_LOCATION'

const userModule = {
  namespaced: true,
  state: () => ({}),
  mutations: {},
  actions: {
    [SET_USER]() {},
    [SET_USER_LOCATION]() {}
  },
  getters: {}
}

// vue file
import { mapActions } from 'vuex'
import { SET_USER, SET_USER_LOCATION } from './userModule.js'

...mapActions({
  setUser: SET_USER,
  setUserLocation: SET_USER_LOCATION
})

Access actions with mapActions

This gives you a clear view of store attributes used by your Vue file.

But that’s not enough. Everything is still in one file. Let’s see what we can do to scale it properly.

Folder Structure

Ideally, we want to split modules into different folders. Within those modules, we want to split their mutations, actions, getters, state attributes, and types across different files.

The desired folder structure

Folder store will be created in the root folder of our project.

It will contain two things:

index.js file
modules folder

Before explaining the index.js file, let’s see how we divide a single module. Let’s check the user module.

All of its actions, mutations, and getters should be listed in the types.js file. So, something like:



// actions
export const SET_USER = 'SET_USER'
export const SET_USER_LOCATION = 'SET_USER_LOCATION'

// mutations

// getters

store/modules/user/types.js

We’ll have a clear view by importing those consts every time we want to use them.

Let’s look at the actions now. We want to move them to the actions.js file.

To do so, we only need to copy the actions object within the module and export default it, while importing the types:



import { SET_USER, SET_USER_LOCATION } from './types.js'

export default {
  [SET_USER]() {},
  [SET_USER_LOCATION]() {}
}

store/modules/user/actions.js

We will do the same thing for mutations and getters. The state attributes will remain in index.js (within the user module folder):



import actions from './actions.js'
import mutations from './mutations.js'
import getters from './getters.js'

const state = {}

export default {
  namespaced: true,
  state,
  actions,
  mutations,
  getters
}

store/modules/user/index.js

Now we have all of our modules divided into multiple files.

The one thing remaining is to link all those modules in the index.js file within the store folder:



import Vue from 'vue'
import Vuex from 'vuex'

// Modules import
import UserModule from 'modules/user'
import OrganisationModule from 'modules/organisation'

Vue.use(Vuex)

const state = {}
const actions = ({})
const mutations = ({})
const getters = ({})

const modules = {
  user: userModule,
  organisation: organisationModule
}

export default new Vuex.Store({
  state,
  actions,
  mutations,
  getters,
  modules
})

store/index.js

Conclusion

By using this architecture, we had zero problems with scalability in our massive production app.

Everything is so easy to find.

We know exactly where all the actions are triggered.

The system is highly maintainable.

If you have any recommendations for the improvements, please let me know. I would love to hear your opinion.

Why is the Virtual DOM So Fast?

Domagoj Vidovic — Wed, 07 Jul 2021 14:04:09 +0000

When you start learning about the frontend world, you’ll almost immediately stumble across the term “Virtual DOM”.

Most of the popular frontend frameworks use it and want to prove their speed with it.

But what makes it so fast?

And what makes the real DOM so slow and inefficient?

Understanding Browser Rendering

This topic is quite complicated, but you need to know the basics to understand the DOM.

Let’s assume that we request a simple HTML/CSS page from the server; we won’t need JS here.

After we receive a response in the form of HTML/CSS, this happens:

1. Parsing the HTML

The browser parses the HTML file and stores it in memory as an efficient tree structure.

That representation is called DOM — Document Object Model. You can see it by opening the DevTools, and selecting the “Elements” tab.

Just to be clear, DOM is not HTML! It’s just an interface for HTML and XML files.

2. Parsing the CSS

This step includes parsing the CSS — and storing it as a tree structure. It’s referred to as CSSOM.

3. Creating the Render Tree

When you combine DOM and CSSOM, you get a render tree. It’s made out of HTML nodes and their styles, and it represents what is rendered in the browser.

This won’t include every HTML node — e.g.<head>, but also elements with display: none;. Just the ones that are actually visible on the screen.

4. Layout Stage

The purpose of this stage is to calculate the positions of every node in the render tree. The browser will begin at the root and traverse the tree.

As you can imagine, this process can be expensive because it has to do loads of calculations for every node in the tree.
At the end of this stage, the browser knows each element’s exact position and size.

5. Paint Stage

Finally, we can fill the empty skeleton we’ve got after the Layout Stage.

The browser literally has to go through every pixel in the viewport which has to be filled. Sounds expensive, right?

Well, it is. This is definitely the most computational heavy step.

You can inspect the Layout and Paint Stages in DevTools under the “Performance” tab.

Let’s Do the Math

As you probably already know, tree structures are incredibly efficient. The algorithms we have can traverse the enormous trees without too much effort.

It’s really cheap to do it. And that’s what steps 1–3 are all about.

On the other side, steps 4 and 5 can be incredibly expensive because we have additional steps of manipulating every pixel on the screen. Those algorithms are efficient, but still so slow compared to a tree structure.

Obviously, our initial page render will take a bit longer and Virtual DOM won’t help us much. We don’t have anything on the screen yet, right?

But later, when we make updates, Virtual DOM will go through steps 1–3. It will compare the new render tree with the previous one, and do steps 4–5 only for the modified nodes.

That’s what makes it so fast!

It doesn’t need to do a whole process from the scratch. It will re-render (steps 4 and 5) only the modified nodes!

The best thing is — you don’t need to take care of it. Your magical FE tool does that for you.

If you read about Optimizing Performance in React’s official docs, you can see:

“Internally, React uses several clever techniques to minimize the number of costly DOM operations required to update the UI. For many applications, using React will lead to a fast user interface without doing much work to specifically optimize for performance.”

So don’t make unnecessary optimizations. Most of the time, the complexity behind those optimizations will result in a slower code.

Love and praise the VDOM.

How I Prioritize My Work as a Software Engineer

Domagoj Vidovic — Mon, 14 Jun 2021 14:15:41 +0000

Somewhere in the middle of my career, my coding skills started to grow rapidly.

I surrounded myself with the best engineers. I got the best mentorship.

Every pull request was an invaluable lesson.

However, being a great developer is much more than writing amazing code. We are team players, and we must act like it.

Soft skills, if you focus on them, can improve your career more than your technical skills.

Just a few engineers who work closely with you will be aware of your code quality. However, if you’re a great team player, everyone will know it.

Let me share a few things I changed at my work that completely transformed my career.

What I Was Doing Wrong

At the time, I was obsessed with deep work and the flow state. I put my noise-canceling headphones on, started coding, avoided all distractions, and let the code fill my mind.

Sometimes, I succeeded in retaining that state for hours. It was amazing. I was learning so much and it felt so good.

Today, I have nothing against the flow state. Hey, I’m currently in it while writing this article. I have no distractions. My phone is on silent mode and I know I won't speak to anyone before I finish.

But there’s a huge difference. When writing, I’m all alone.

When coding for a company, I’m a team player.

I can’t snooze all my notifications. I can’t be unresponsive. My team needs me in the same way I need them.

And that’s exactly what I was doing. Sometimes, it took me an hour or even longer to respond to a simple Slack message.

When people asked me to do something that would take five minutes, I ignored that task for days.

I was constantly pursuing that magical flow state. I didn’t want to let any distractions come to my mind.

In my head, I had a right to do that. I was writing the best code possible and focusing just on that. What’s the problem?

What My Colleagues Thought About Me

If we take a different perspective and look at it from the eyes of my colleagues, we will see that my behavior wasn’t justified.

They needed to do something for work, so they asked me for help. However, those requests always landed at the bottom of my priority list.

I gave them solutions hours or even days later.

Sometimes, the solution wasn’t so great. I didn’t want to spend too much time on those small tasks.

“Let me keep my flow state!”

Why I Changed

Every once in a while, we have anonymous team reviews. Basically, you write about the people you work with. After the sessions, the team leaders tell you what others are saying about you.

I received many positive comments about my engineering skills.

However, some comments were quite negative, and they were all connected to my prioritization and communication techniques.

People were saying that I was unresponsive or gave them solutions that hadn’t been fully tested.

How could I test them properly when I had to return to the flow state as soon as possible?

I took that opportunity to self-reflect and change.

What I did was incredibly simple. However, it completely transformed my career.

The Simple Changes

When somebody asked me for help, I immediately responded. Their request was now my top priority.

Most of the time, it’s not a time-consuming task. It’s a question about where something is located in the app, what the expected behavior is, what that code means, etc.

I can handle those tasks in 1-2 minutes. Occasionally, it takes me 5-10 minutes if they are a bit more complex.

Besides just responding to my direct messages, I also became an instant responder in our groups. Suddenly, I became a person others rely on when they need quick information or changes.

Astonishing Effects

From being an unresponsive person who coded in the corner with his noise-canceling headphones, I became one of the most valuable people in the company.

Everyone has that feeling of trust: When they ask me something, they know the solution will be there in the shortest time possible.

People don’t expect that, so they love it even more! I often receive compliments about how great my work is and how fast I deliver it.

My colleagues have problems they need to solve. If I help them in two minutes, they will be amazed.

However, if I help them in three-plus hours, they won’t be impressed. They may even be annoyed if it’s something really simple.

The Real Benefits

For the sake of simplicity, imagine that I’m working on a task that needs six hours to be finished. I started my work at 9 a.m. If I do nothing but code, I will finish it at 3 p.m.

However, I’m not the only one who’s working. Everybody else is, and they need my help. In the period from 9 to 11 a.m., three people ask for my help.

The tasks are pretty simple. Each one will take around five minutes to complete.

We have two possible scenarios about handling this work:

In the first one, I’m the old, unresponsive team member. It takes me about one hour to respond to somebody’s message, and it goes at the bottom of my priorities list. I will do it after I finish my task. That means that I’m done with my feature at 3 p.m. However, that also means those three people waited 4-6 hours for my solutions. They are grumpy because they wanted to do something by noon. However, they were blocked by me.
In the second scenario, I respond and do the job immediately. I receive comments like “Amazing, that was so fast 🚀” or “Wow, I can do this before lunch now, thanks Dom 🏎.” Besides all that, I finish my feature at 3:15 p.m.

Can you see the difference?

Nobody cares about me finishing the feature 15 minutes later because they didn’t know when I was expected to finish it anyway.

However, they certainly care about me providing them with a solution in five minutes rather than five hours.

Again, just a few people can see your code skills. However, most of them will see your communication skills.

How Did This Influence My Coding Skills?

We, as engineers, need to solve extremely complex problems that require a lot of focus. Sometimes, context switching can destroy those solutions in our minds.

However, a context switch can also be the break you need. When you return, you’ll be able to take a step back and look at the problem from a different perspective.

If you had stayed there for a few more hours, you would have just drilled in the wrong direction.

Suddenly, you return after a break and fix the issue in a few minutes.

So those breaks actually improve my coding skills. I ship the code even faster now.

Sometimes, the best solution is to let go. A fix will quickly come after we stop being obsessed with it.

Conclusion

This is not just for your benefit — everybody’s included.

These skills will make you a great team player. A person others can rely on. You will radiate confidence and solve people’s problems in no time.

Nobody’s pipeline will be blocked because of you. Everything just flows. You make others feel happy and inspired.
You’re not alone, so stop acting like that.

You can be an incredible engineer, but if you manage to be an incredible team player as well, you’ll easily become part of the top 1%.