DEV Community: 0ro

Z-Index Trick You Might Not Know 🚀

0ro — Sun, 03 Dec 2023 16:21:24 +0000

In one of the projects where I recently worked, we had a pretty trivial task: Add a panel of buttons for our canvas editor. The design in Figma for this panel looked like this:

As you can see, there is a canvas in the design, and above it, a panel with buttons:

The buttons need to have the same gap between each other.
And you should be able to draw behind the buttons.

How to achieve it?



<button>Button</button>
<button>Button</button>
<button>Button</button>
<canvas id="canvas" />

So the first option that will satisfy our requirements is to create all buttons, add them position absolute property, then do some math and add left and top properties to every button. That's crazy, right? Especially if you have dynamic content inside of your buttons.

What is another approach?



<div class="panel">
  <button>Button</button>
  <button>Button</button>
  <button>Button</button>
</div>
<canvas id="canvas" />

Let's see the problem from another perspective and try to redefine our task. To make a panel with buttons and make them respect each other, it's better to wrap them in a container. With flex or grid properties, we will have a desirable behavior for its children. Then we need to calculate the position for that container. You can see the result in the next image:

But what about our second requirement? We already can't draw in space between buttons. Even if we make our wrapper totally transparent, the click will be caught by this panel, and the canvas will not see it.

Ideally, we need to have something like this:

Is it even possible? To somehow sneak between your sibling (panel) and its children (buttons) and achieve that rendering order?

Yes, it is. And I'll tell you how.

A bit of theory

Let's say we set a position absolute property to our panel element in CSS. What do you think will happen with its rendering order on the page?

According to MDN:

When the z-index property is not specified on any element, elements are stacked in the following order (from bottom to top):

The background and borders of the root element.

Descendant non-positioned elements, in order of appearance in the HTML.

Descendant positioned elements, in order of appearance in the HTML.

So, because our panel is already a positioned element, it will be on the top of our canvas. If we set position: absolute to the canvas, then the canvas will be on the top because it appears after the panel element in HTML.

But what if we set z-index: 1 to our buttons? Logically, it seems that they should start counting their index from their parent (panel) and still be under the canvas, but they will be on top of the canvas!!!, and our initial task is done.

You can check it here in this interactive example
But how does it work?

Explanation

The trick is, if you don't set the z-index property to your position absolute element, this element doesn't create a stacking context. We didn't set z-index to panel and the ordering of render for our elements can be represented like this:



root element // 0
  panel // 1
    button // 3
    button // 4
    button // 5
  canvas // 2

The number at the line of the element is the order of rendering. The order is defined as preorder depth-first traversal of the rendering tree. Pre-order traversal means:

Traverse the root node
Traverse sub-trees from left to right

The more detailed information about ordering and stacking context, read in CSS spec

Conclusion 🚀

In conclusion, understanding the intricacies of z-index and how it interacts with the positioning of elements can lead to clever solutions, as demonstrated in my example. Remember that an element with position: absolute without z-index doesn't create a stacking context.

Console.log it

0ro — Mon, 18 Sep 2023 15:12:48 +0000

Finding and fixing bugs in your program is a common task for every developer. In this article, I will outline the steps I follow in my daily work to identify and resolve these issues.

Let's assume that this bug has already been prioritized for you, and you don't need to validate its value for your project.

Visual Detection

Prove Bug Reproduction: Gather all facts about the bug, including when and how it reproduces. Ensure that the bug is reproducible. It's important to consider that what may seem like a bug could also be a lack of requirements. You might need to implement a new feature to address it. So, before rushing into fixing it, check if it conflicts with the requirements.

Reproducing the bug can sometimes be a non-trivial task. Bugs can occur in various places, including:

Your code
Server environment (servers)
Network problems
Client environment (browsers, applications, OS)

History

Once you have confirmed that the bug exists, the next step is to determine when it started to occur. You can either blame the file where the bug is appearing or examine the Git history and files that were changed, which can provide insights into the problem.

I personally use VSCode along with the GitLens extension. It makes it easy to blame a file line by line and it offers a Commit Graph feature to navigate through your Git history and view changed files.

Remember that not only the code can be the cause of the bug. Be aware of recent changes in updates of your server environment.

Google it

Consider searching for solutions online. You can use Google, stack overflow, or even ask questions to AI models like ChatGPT, which sometimes are not quite well for it, so I stopped doing it, but maybe for getting a new idea when you stacked it can be good.

Bottom-Up Approach

When dealing with bugs, consider using console.log or debugging with built-in tools from where the error occurred and work your way up through the reference tree. This helps you understand the code flow and identify issues.

Note that debugging may not work well for certain scenarios, such as mouse move events, or when you need to track the difference of values between renders. So console.log can be here only one option.

Sometimes the bug can occur without throwing any errors. It can be some inconsistent behavior on UI, so try to search by word, or component name for checking the problem. I even had in my projects CSS debug rule like:

.debug {
  outline: 1px solid red;
}

It helped with the visual detection of a component where the bug is occurred.

Binary Search

For localizing and isolating the bug, employ a method similar to a binary search used in engineering. This approach helps narrow down the potential sources of the problem.

Remove dependencies from your code, and check the results, if the bug is still reproduced repeat it again.

Open-Source Contributions

If the bug is not within your codebase, consider opening an issue in the relevant open-source repository and consider making a pull request to resolve it.

Ask your teammate

You can stuck with your investigation sometimes, and if you already have done all of the previous steps, go for advice from one of your teammates. Tell him/her about your investigation, what you've already done step by step, what you've found, show some tricky points that you don't quite understand, and ask his/her opinion and ideas about it. Most of the time during your explanation you can find a solution yourself, or you will try to prove the hypotheses of your teammate. If you are not lucky try another teammate and so on.

Add tests

Having tests in your code is the most important thing on the way do not repeat the same bug in the future. I cannot advise using TDD methodology from the start of your project, but when you are fixing the bug, it is great to use it. Write your test to prove the bug, and then make it green. Writing unit tests for some startups in my opinion doesn't give significant results, and sometimes it is difficult to sell this idea to a business. Instead, consider using e2e testing libraries like Playwright, Cypress, and so on, they give you results immediately, and you will never again repeat this bug.

Communication with Managers

Stay in constant communication with your project managers. They are not interested in wasting time, so keep them updated on your progress, share the results, and set reasonable deadlines. Let them make a decision to continue your investigation. If necessary, discuss the possibility of implementing Plan B. Sometimes, reworking a specific part of the product might be more cost-effective than fixing a complex bug.

Conclusion

I really like finding bugs in the code, especially when you eventually solve them. So here is the short plan for you to fix any bug in your code:

Reproduce the bug (it is not always the codebase)
Gather all available information about the history of the bug
Google by error
Console.log from bottom to up
- Binary search
- Time to contribution to open-source
- Ask your team mate (explain it)
Add tests to cover the bug
Always be in touch with your managers

And remember Catching A Pokémon Is Not About Skill.

The Mentor Dilemma: Finding Your Way in IT 🚀

0ro — Thu, 14 Sep 2023 17:42:34 +0000

In my 10-year journey in the world of IT, I've never had the privilege of a mentor.

Who is a Mentor?

In my view, a mentor is an expert in a particular field who's eager to share their knowledge, set strategic goals for your development, and ensure you stay on track. They are both an expert and someone who's willing and eager to mentor. Since they're already established professionals, their time is precious, making it quite rare to encounter such a gem casually.

So, where can you find one? In many companies, the practice of assigning a more experienced developer within your team or a team lead as a mentor is common. You interact with them through work, they conduct code reviews, and occasionally, they mentor you. However, finding someone truly motivated to share their knowledge and nurture your growth is not an everyday occurrence. Unfortunately, luck hasn't favored me in this regard.

The Easier Path with a Mentor

Yes, having a good mentor can save you a ton of time in mastering your craft. They can offer guidance, help you do not step on the wrong path, set the direction for your growth, and ensure you don't miss the essentials. If you find a mentor in your circle, hold onto him/her tightly; you're incredibly fortunate.

As I mentioned at the beginning of this article, I never had a mentor, at least not as a dedicated individual. Instead, I consumed all available information, attempting to sort and comprehend it on my own. I scoured technical websites, followed all popular bloggers on YouTube and Twitter, listened to podcasts, and watched conference videos available online. This path was entirely unsystematic, undoubtedly taking more time than it would have with a living, breathing mentor.

Becoming a Mentor Yourself?

At one point in my career, I became a mentor to a couple of people. Let me share one of those experiences.

A colleague at work asked for help in teaching one of his friend HTML and CSS. I had never done this before, but I agreed to assist. I crafted a plan, found a suitable design (back when it was still in Photoshop), monitored their progress, organized calls, explained what I would do, what else they needed to learn in parallel, and addressed all their questions. In essence, I tried to be the mentor I had always wanted. Sadly, a couple of weeks later, my mentee disappeared, leaving the project unfinished. This unfair, right? Nevertheless, I took many valuable lessons from this and other experiences, which helped me organize my own knowledge and learn how to interact more effectively. The "do as I do" method yields quick results but isn't sustainable over the long run. On the other hand, an educational approach based on open-ended questions—why? how?—sparks curiosity and transforms learning into an exciting journey.

Being a mentor is beneficial; it allows you to look at the familiar from a different perspective, enhancing your understanding of the subject.

You Don't Need a Mentor

Mentors are fantastic, but if you don't have one, don't despair. The programming field is all about continuous learning and seeking the right information. It's better to learn to navigate this journey on your own from the beginning. We learn best from our own mistakes, so make them and draw conclusions. If you feel the YouTube content isn't sufficient, and you're accustomed to more structured information like in university, you can always find a program for the course you're interested in, like MIT, and then search for videos on individual topics sequentially, for instance, 6.1020 mit. Codes may have changed by now; previously, this course was labeled as 6.006, but finding the topic by name shouldn't be a challenge. Lectures from one of the world's top institutions are at your disposal; you just need to find the time to watch them and dissect them thoroughly.

Conclusion

So, remember, while mentors are invaluable, your thirst for knowledge and determination can carry you far in the realm of programming.

Whether you have a mentor or not, your journey in IT is defined by only your curiosity, dedication, and the willingness to learn from both successes and failures.

🤔 How I Choose Fabric.js Again

0ro — Sun, 03 Sep 2023 16:48:46 +0000

If you don't know, Fabric.js is the library that helps you manipulate canvas elements in the browser and even on Node.js servers. It is very popular and has more than 25.7k stars on GitHub (one of them from me). But is it still the best option for you? Let's find out.

Why do we need libraries?

I can advise using canvas libraries, and even any library, in two main cases:

When you create something simple.
When you create something that is very complicated.

When you try to create something that is simple, you usually don't need to use any libraries at all. In our case, you can start with the native built-in Canvas API for browsers or use the canvas npm package, which allows you to use the same API on the Node.js environment.

This option is also valid if you want to learn something new, like Server Sent Events, Websockets, or the Canvas API. Starting with learning a library's API before the native API is always a bad idea. From a long-term perspective, it puts you in a losing situation. It's similar to learning JQuery before JavaScript or React.js before JavaScript. It will be difficult for you to sell your expertise in the future and help you with onboarding in any new library.

When you create something that is complicated, use the native API. This case is valid if you're trying to create something like Figma, Excalidraw, Miro, or something else that requires a new approach to working with graphics on the web. From a business perspective, it will be much easier and even cheaper to create your own library that is definitely based on the native Canvas API and covers your internal demand. Open-source libraries are sometimes not very customizable.

So, both cases favor the native API. For projects in the middle, you can use the built-in API too, but it will probably cost you a lot of resources. I'm sure everyone remembers that bad feeling when one day you decided to create your own Select, Datepicker, or Checkbox on a commercial project, and something went wrong with them because you didn't figure out how many edge cases you needed to cover in your code. The same applies here: if you're working on a commercial project and your task is not very simple, first consider using an open-source library. Only if you didn't find something that is really needed for your project should you then switch to a hand-made solution (or take the opportunity to create your own open-source package because you've found something that doesn't exist).

Defining the simplicity of your task or project is up to you. It is a subjective term, of course, and it depends on your experience. You can expedite gaining experience faster by reading articles and watching videos about programming. People are sharing their experience for free; please use it.

This is a fundamental concept that everyone should know. Let's continue.

My first time with Fabric.js

It wasn't like on the picture; it wasn't comparable to hanging, but it wasn't a great time for me. Because I made that mistake, I started learning the Fabric.js API before I was very familiar with all the concepts of the native canvas API. But, to be fair, Fabric.js is very friendly for geniuses like me. I almost never touched the canvas API on that project because everything was already implemented in Fabric.js. It's good for a library, right? And, of course, during the investigation of some bugs, I learned the Canvas API anyway because if you think you can avoid something, fate will surely punish you.

High-level architecture

So, after 7 years, I needed a library again for creating a graphic editor. One of the requirements was a Canvas-based approach. So, of course, I considered using Fabric.js because I was already very familiar with it. But I wanted to discover the current state of affairs in the world of Canvas-based libraries on the web and check the state of Fabric.js.

First of all, don't even think about libraries that are bound to some popular frontend framework like React.js, Vue.js, and others. You don't need them because you will still use only <canvas> there and somehow connect it to your desired canvas library. The high-level architecture for such an editor can look like this:

From left to right, you can see:

Frontend framework, it can be anything you use, React.js, Vue.js, and others, or you can even avoid using frameworks altogether.
Editor component. A component where you're going to store your canvas tag, and where you are going through your state management to initialize your library.
State management. Here, you can use anything you want to sync the canvas state with your component state. It can be Zustand, MobX, Jotai, or even Redux.
Adapter is going to store the methods and properties that you will use to describe the logic for your Canvas Library and customize the standard behavior of that library.

Now, we can focus on finding the Canvas-based library.

Some libraries are dead

There are a lot of libraries that work with the Canvas API, and I would divide them into two big groups:

Visualization libraries.
Whiteboard/drawing libraries.

Visualization libraries are the ones that help you with visualizing your data on canvas or animating it to make it more like a game. So, they are not my case.

Whiteboard/drawing libraries are what I'm looking for to create my graphic editor.

I don't have all the time in the world to check and try each library because the real development experience of working with a library is the most important and valuable. Only when you create something using a library you see its problems and limitations. So, as I said, I don't have time. Instead of creating a proof of concept with every library, I tried to find all the candidates and make a decision based on these points:

Open-source
GitHub stars
NPM downloads
Stack Overflow questions
Date of the last release
Documentation

Based on this, I found that some of the libraries are dead and no longer have any support. Only two libraries are still alive and have significant amount of stars on GitHub and downloads on NPM. They are Fabric.js and Konva.js.

	Fabric.js	Konva.js
GitHub stars	25.7k	9.7k
NPM downloads	140,574	276,004
Stack Overflow questions	9,806	986
Date of the last release	2 weeks ago	3 months ago
Documentation	Good	Good

Conclusion

As you can see, Fabric.js is dominating in all metrics. The most interesting moment is that they are preparing a new release with a lot of new features, which is a very good sign because it means that the library is still alive and has a lot of contributors.

I would really like to try Konva.js too, but I don't have time for it, and I'm not sure that it will be better than Fabric.js. So, I decided to use Fabric.js, and after a few months of active usage I have no regrets about it.

Nobody knows how to estimate software projects

0ro — Fri, 01 Sep 2023 18:31:39 +0000

Disclaimer. This article is a joke. Only me and God know how to estimate software projects. And I am not sure about God.

The Great Unknown

Let's imagine you are a Tech Lead, and recently you were asked to estimate a software project. You were given a list of features and asked to estimate how long it would take to implement each feature and the entire project. You were given a couple of days for it...

A couple of days! Really? Estimate the entire project. It cannot be enough. Even for the best of us. Even if you have done it before many times. But how much time do you need? A week? A month? It always will not be precise anyway. So, maybe a couple of days is a good option, at least you will not waste a lot of time on it.

And be sure, your managers will tell you, "Don't worry, no need to dive deep into details, we just need a rough estimate and nothing more, you will manage to do it, come on buddy".

And of course, they lie. They will use your estimation to plan the project, to plan the budget, to plan the team, to plan the deadlines, to plan the marketing, to plan the sales, and to plan the future of the company. And they will use it to blame you later when you will not be able to deliver the project on time.

The Burden of Responsibility

The customer needs to know how much it will cost to implement the project. It is a good reason, right? They need to prepare money for their amazing start-up, or maybe find investors, who will pay for it. And the amount of money they will ask depends on you. So, it is a big responsibility, including the fact that only you know how you came up with the numbers.

Usually, customers ask for estimates from several companies, and then they will choose someone. It is not always the cheapest one, there are a lot of factors that influence the decision, but the price is one of the most important factors. And here is the catch:

On your side, if you will give a price that is too high, for the customer, you will usually lose because the project is not on you. If you give a price that is too low, you will usually win the battlefield, but you will lose this war later, when you are working on the project every night.

On the customer side, if you provide them with a budget that is too low, they will not be able to implement the project, and they will lose. If you provide them with a budget that is too high, they will lose, because they will not be able to find investors.

The Illusion of Technique

So, how to estimate the project? There are a lot of techniques and maybe you know some of them. There are countless methods: expert judgment, story points, bottom-up estimate, three-point estimating - you name it. They all promise to unveil the magic number. But guess what? None of them have the Midas touch.

You might meticulously break down the project into user stories, assign story points, and create impressive Gantt charts. You might consult with your team and reach a consensus. You might even throw in some past project data for good measure. Yet, when the deadline day arrives, you're either ahead of schedule with nothing left to do or drowning in an ocean of bugs and scope changes.

Conclusion

In the wild world of software project estimation, one thing is clear: it's an art, not a science. It's a complex dance of uncertainty, expectations, and a dash of wishful thinking. So, next time you're asked to estimate a software project, remember to take it all with a grain of humor and a pinch of humility. After all, in the ever-evolving realm of software development, the only constant is the unpredictability of estimation..

📜 Length of String in TypeScript

0ro — Thu, 31 Aug 2023 18:06:19 +0000

I'm very like typescript and I always try to learn something interesting there. I thought that it is impossible to know the length of the string in typescript, but I was wrong. Today during solving typescript challenge I found a way to do it. If you don't know about typescript challenges, you can read about it here, it is a very interesting project, and I highly recommend you to try it, if you, like me, obsessed with typescript.

Let's start with example where in real life it can be useful. Imagine you have a function for getting a country by its code, and you want that function to accept only strings with length 2. It will be nice to have something like this:

function getCountryByCode<T extends string>(
  code: isLength<T, 2>
) {
  return "Belarus";
}

getCountryByCode("BY"); // "Belarus"

In the code above we declared a generic type T which extends string and we want to check that the length of this string is equal to 2. Unfortunately, typescript doesn't have a built-in type for getting the length of the string, but if it had, it would look like this:

type IsLength<
  S extends string,
  N extends number,
> = Length<S> extends N ? true : false;

You can see here that I declared a generic type that accepts two parameters, and then I'm using the Length type to get the length of the string and compare it with the second parameter via extends keyword.

But Length type doesn't exist in typescript, so we need to create it by ourselves. There is a trick that allows us to do it. We can use the infer keyword to get the length of the string. If you don't know how infer keyword works in Typescript I can recommend you my article about it here. So let's create our Length type:

type StringToTuple<S extends string> =
  S extends `${infer Char}${infer Rest}`
    ? [Char, ...StringToTuple<Rest>]
    : [];

type Length<S extends string> =
  StringToTuple<S>["length"];

It's crazy, right? But let me explain how it works.

First of all, we need to convert our string to tuple, and we can do it with the StringToTuple type. It accepts a generic type S which extends string and then we are using the infer keyword inside the template literal type, that allows us to get the first character of the string and the rest of the string. Then we use the spread operator to add the first character to the tuple and call the StringToTuple type again with the rest of the string. We are doing it until the string is empty, and then we return an empty array.

It means that if we have a string like "BY" it will be converted to the tuple ["B", "Y"]. And then we can get the length of the tuple with the Length type, it is possible because the tuple type knows exactly how many elements it has. You can read more about tuples here.

So, the full way to get the length of the string will look like this:

type StringToTuple<S extends string> =
  S extends `${infer Char}${infer Rest}`
    ? [Char, ...StringToTuple<Rest>]
    : [];

type Length<S extends string> = StringToTuple<S>["length"];

type IsLength<
  S extends string,
  N extends number,
> = Length<S> extends N ? true : false;

So, but I'm not done yet, based on this we already can create more utility types:

// check if string is empty
type IsEmpty<S extends string> = IsLength<S, 0>;

// check if string is not empty
type IsNotEmpty<S extends string> = IsLength<
  S,
  0
> extends true
  ? false
  : true;

// check if string is shorter than N
type IsShorter<
  S extends string,
  N extends number,
> = IsLength<S, N> extends true ? true : false;

// check if string is longer than N
type IsLonger<
  S extends string,
  N extends number,
> = IsLength<S, N> extends true ? false : true;

Honestly I don't know we're it can be useful, but it is possible to do it, and it is cool. 😎

On my projects I have a special place for my utility types. It is pretty handy and I always can hope that they will be useful in the future. So, I added this types to my utility types, and I hope that they will be useful for you too.

I hope you enjoyed this article, and if you have any questions or suggestions, please feel free to ask.

Enabling Dark Mode in React.js with SCSS Modules 🌙

0ro — Tue, 29 Aug 2023 09:38:04 +0000

In one of my recent projects, I needed to add support for dark mode to a React.js Single Page Application (SPA). Since we were using SCSS modules to style our elements, let's explore how to implement dark mode in a React.js project with SCSS modules.

Switching Color Schemes

With widespread browser support for CSS variables, I don't see any alternative to using the body class + CSS variables approach. This means that when a user enables dark mode in your application, a .dark class is added to the body tag, and the variables are overridden based on the presence or absence of this class.

CSS Variables

If you're not already familiar, CSS variables (custom properties) are entities in CSS that allow you to store values and then use them in your styles. For example:

body {
  --text-color: #ccc; // define a CSS variable
}

h1 {
  color: var(--text-color); // get a variable
}

p {
  color: var(--text-color); // get a variable
}

Variable names should always start with a double hyphen (--), and you access a variable by using the var() function.

The var() function will attempt to find the --text-color variable within its scope or from its parents. In our case, that's the body. However, you can redefine this variable so that, for example, h1 and p elements inside sections have a different color:

section {
  --text-color: #ddd
}

In our case, this trick will help override variables for dark mode.

Real case

First, declare all the variables your designers use in layouts on the :root pseudo-class and add them to a global.scss file in your project:

:root {
  --black: #000;
  --gray: #ccc;
  --white: #fff;
  --blue: #0085f2;
}

In this case, I suggest not tying variable names to the entities where you plan to use them. For instance, don't name them like --text-primary-color: #ccc, because we're going to define this at the level of React component styles. For example, you have a component:

import classNames from "classnames";

import styles from "./Text.module.scss";

interface ITextProps {
  type?: "primary" | "secondary";
  children?: React.ReactNode;
}

export const Text: React.FC<ITextProps> = ({ type = "primary", children }) => {
  return (
    <p className={classNames(styles.root, styles[`${type}Type`])}>{children}</p>
  );
};

As you can see, this is a simple React Component that can have one of two types, which we intend to handle in the style file.

The style file (Text.module.scss) for this component will look like this:

.primaryType {
  --text-color: var(--blue);

  color: var(--text-color);
}

.secondaryType {
  --text-color: var(--black);

  color: var(--text-color);
}

Here, for each text type, I've defined my own variable whose value is taken from the :root pseudo-class.

Now, to enable dark mode for text, we need to use the body.dark class. We can do this as follows:

.primaryType {
  --text-color: var(--blue);

  color: var(--text-color);
}

.secondaryType {
  --text-color: var(--black);

  color: var(--text-color);
}

:global(.dark) {
  .primaryType {
    --text-color: var(--gray);
  }

  .secondaryType {
    --text-color: var(--white);
  }
}

:global(.dark) allows us to use global SCSS modules classes. Here, we simply override variable values, which, due to the nesting within the .dark class, will take higher priority than the ones declared above.

Since we are using SCSS, we can create a mixin based on this approach. Let's also add a media query to apply dark mode based on the user's operating system settings.

Here's what the mixin will look like:

SCSS Mixin

@mixin dark-mode {
  @media (prefers-color-scheme: dark) {
    @content;
  }

  :global(.dark) {
    @content;
  }
}

And here's how you can use this mixin:

@import "../styles/mixins";

.primaryType {
  --text-color: var(--blue);

  color: var(--text-color);
}

.secondaryType {
  --text-color: var(--black);

  color: var(--text-color);
}

@include dark-mode {
  .primaryType {
    --text-color: var(--gray);
  }

  .secondaryType {
    --text-color: var(--white);
  }
}

This way, dark mode styles for your components will be isolated and conveniently located at the end of the file, making it easy to navigate through them. 🌙

🚀 How would I start a React project now? 🤓

0ro — Sat, 26 Aug 2023 19:04:55 +0000

I work at an outsourcing company, and we often have to create projects from scratch. Every time before starting this process, I try to conduct research on what needs to be chosen. Since I have more experience in the React ecosystem, in this article, I would like to answer the question: how would I start a React project now? 🤔

Disclaimer: The following article reflects my personal opinions and experiences. Please consider project-specific factors and team expertise when making technology choices.

Gathering Requirements 📝

Let's imagine that you, like me, are a developer at an outsourcing company or a freelancer, and you have received an order to create a new project. You need to work on the frontend part. Where should you start, and how should you approach choosing a framework? 🧐

What to Ask? 🤷‍♂️

Which browsers need to be supported? 🌐
Which devices need to be supported? (mobile, tablets, desktop) 📱💻
Language support? 🌎
Do you have any design or mockups? The choice of framework depends on this. 🎨
Dark theme? 🌙
Is there a backend? 🌐
Do you need server-side rendering? This is important for SEO. 🚀
Tests? 🧪
Are there any special integrations with other services or APIs? 🤝
Accessibility? ♿

These questions apply to any project. This forms the foundation, and from these answers, you can build a dialogue with the client. However, the functional requirements for all applications are different. They will determine the internal content of your project and the architecture of the system's internal parts. For example, if it's a banking application, it will involve many forms, whereas if it's a shopping app, it will have many product cards. If it's a graphic editor, you'll need to think about choosing a library for working with graphics, and so on. In general, gather as much information as possible about the project. 📊

Common Requirements 📦

Functional requirements differ, but the skeleton of the application is usually the same. Here's an approximate list of what needs to be done in any project:

Authentication/Global state ✅
Routing 🚏
State management 📂
UI components 💎
i18n (internationalization) 🌍
Styling 🎨
Linting, formatting 🧹

This is where it gets interesting for me. What tools should you choose for each of these points? 🛠️

Frameworks 🛡️

Every time, I start this story from scratch and try to make a fresh decision about the framework.

It's worth mentioning that the choice of framework depends on your team's experience and your own. If you and your team haven't worked on React.js projects before, starting a new project for which you're being paid can be a risky endeavor. If you value your client's money and your reputation, it's better to develop in something you already know well. Save experimentation for your own projects. 💼💡

In my case, I have experience with create-react-app and Vite + React.js, and unfortunately I've never had a chance for working with Next.js. 📚🔍

It seems obvious to everyone that Vite has won in this showdown. But I wouldn't completely dismiss create-react-app, and here's why. 🥊

Create-react-app? 🎉

In my most recent project, I needed to build an application with micro-frontends. Starting my research in this area, I found that the Vite plugin for supporting Module Federation is not stable. In particular, I faced an issue that is still open, raising doubts about its usage. Meanwhile, create-react-app works with Module Federation without any issues. I had to make this difficult decision back then, endure the slow webpack build in favor of stability. 😓

So, at this stage, if you need Module Federation support, it's better to go with create-react-app + craco. Yes, Next.js also has support for Module Federation, as far as I know, there's a paid plugin for it, but why use Next.js for lightweight micro-frontends? Micro-frontends are always about customization and flexibility, while Next.js is more of a monolithic framework. Additionally, rspack looks promising, theoretically allowing migration from webpack when Module Federation is ready there. 🏗️

Next.js? 🌐

Next.js is an excellent framework. I always want to start a project with it because it's at the forefront of the React.js ecosystem, and it's satisfying to stay up-to-date. I've identified a few cases where I would choose Next.js for my projects:

SEO. 📈
Small backend 🌐

If your site is a sales page, a portfolio page, or something similar where SEO is crucial, then choosing Next.js seems justified. Also, if your backend isn't too complex, and you don't need a lot of server-side logic, which is generally suitable for portfolio sites, then Next.js can be a good choice. In other cases, I would consider different options.

For me, at this moment, the server in Next.js is a backend for frontend developers. In other words, it's suitable for something simple, but if you have complex business logic, you'll reach a point where you need a separate backend, and then all the advantages of Next.js will disappear. Especially when nowadays everyone goes to serverless backend on lambda functions. 🦄

Vite + React.js? 🚀

Vite + React.js is currently a good compromise for starting a new project. The community around Vite continues to grow, and most likely, all the typical problems you'll face during development have already been solved. You can enjoy fast builds and hot reload. The only drawback at the moment is Module Federation, as I mentioned in the create-react-app section. 🚀

State Management 🧠

It's worth mentioning that state management needs to be divided into two parts: Server state management and Client state management. In my current applications, I separate these two concepts and use different tools for them.

Server state management

When choosing a tool for Server state management, you need to consider what you're using on the backend. For GraphQL, Apollo is suitable, and for REST API, there are several options:

RTK Query 🚀
SWR 🕸️
react-query ⚛️

The react-query website even has a comparison table of these tools.

In my projects, I've long abandoned Redux, so I'm not inclined to choose RTK-query. Right now, I would choose react-query for my project because it offers more features than SWR. I make this choice to avoid risks in the future since this layer of the application is usually challenging to change during development. 🧐

Client state management

For client state management, you need to choose the most suitable tool for the specific situation. Just think about how many questions regarding state management react-query has already answered for you. Data loading, loading states, and more are already handled. This means you only need to handle interactivity and UI element behavior, which are not usually very complex in most applications. Native React.js solutions will work in most places. However, if you need to solve more complex tasks, like a code editor with many states and actions, you'll need to choose a tool that helps manage those states. Here's a list of tools I would consider:

Zustand 🏗️
Jotai 🧙‍♂️
Recoil 🌀

Since my requirements for client state management are not very complex, I would choose Zustand. It has a simple API and is suitable for most of my tasks. However, there's no problem using different approaches in different parts of the application. For example, using Zustand in one part and even MobX in another. 🔄

UI Components 🎨

When choosing a library for working with UI components, you should always start with design layouts and requirements. If you have a design, choose a library that allows you to implement it. If you don't have a design, select a library that lets you create UI components quickly and customize them easily later. Here's a list of libraries I would consider:

Ant Design has almost everything you need, but it can be challenging to customize at times. Plus, it comes with tools for form handling and validation, so you don't have to think about that separately. That's why I often choose it. Of course, there's another option: creating your own component library. But I don't think any of your clients can afford that.

It's also crucial to document your component library using Storybook. It doesn't take much time, but it will be incredibly helpful for you and your team in the future. 📚

Styling Approach 🎩

Customizing your UI components depends a lot on the component library you choose. In the case of Material UI, you'll have to live with their CSS in JS approach, which I'm not entirely fond of. Because in some cases, you'll need to use components from other libraries, and then you'll have to mix different styling approaches. It looks terrible in a project! Therefore, I would choose a library that allows the use of CSS modules, such as Chakra UI or Ant Design. This way, you'll achieve a consistent styling approach throughout the project.

TailwindCSS?

I personally like Tailwind, and if I had to create my component library, I would definitely choose it because it's convenient. But, as I mentioned earlier, having consistency in my project is essential to me, and I can't afford to write some things in CSS Modules and others directly in markup. So, I wouldn't choose it for my project. Still, I can say with confidence that it's a good tool, and if you're not afraid of experiments, you can try it in your project. 🛠️

Conclusion 🎉

Starting a React project involves key considerations:

Requirements: Gather comprehensive project details, from browser support to design assets.
Common Components: Include authentication, routing, state management, UI elements, internationalization, styling, and code quality tools.
Frameworks: Choose wisely based on team expertise and project requirements. Experimentation is best suited for personal projects.
State Management: Divide state management into server-side and client-side. Tools like Apollo, RTK Query, SWR, and react-query can be invaluable.
UI Components: Select libraries like Material UI, Chakra UI, Ant Design, or Tailwind UI based on design needs.
Styling: Prioritize consistent styling. Consider tools like Chakra UI or Ant Design with CSS modules for uniformity.

In summary, make informed choices aligned with project goals. Document decisions, and stay adaptable to evolving project needs. 🚀

Infer keyword in TypeScript 📜

0ro — Tue, 22 Aug 2023 22:13:56 +0000

TypeScript's infer keyword is your secret weapon for effortlessly deducing types, simplifying code, and unlocking the full potential of type inference. In this article, we'll explore how infer can make your TypeScript development smoother and more efficient. 🚀

Type inference in TypeScript is used to provide type information when there is no explicit type annotation. This usually occurs when you haven't added types to your variables:

let str = "Hello, World!"; // str is a string here

Everything is fine with this; TypeScript handles it for you. 👍

If you want to try type inference yourself you can use the infer keyword, and it will look like this:

let str = "Hello, World!"; // str is a string

type GetType<T> = T extends infer S ? S : never;
type T1 = GetType<typeof str>; // string

Of course, this example may seem strange and not interesting, but it can give you an idea of how the infer keyword can be used later. 🤔

As you can see, we used infer within a conditional statement, and this is a limitation of using infer in TypeScript. Also, you cannot use it outside of an extends clause.

If you want to extract the type of an element inside an array, you can do it like this:

let arr = [1,2,3];

type GetTypeOfArrayElement<T> = T extends (infer S)[] ? S : never;

type T1 = GetTypeOfArrayElement<typeof arr>; // number

Here, the infer keyword allows you to extract the type within the array and then use it. It's like defining a reference that you can use later.

That example, also might not seem very interesting because, in the end, you can achieve the same with this approach:

type T2 = typeof arr[0]; // number

However, TypeScript has more complex structures that you cannot work around with simple syntax. Let's consider promises. What if you need to determine the type of the value returned by a promise? Here is where infer can also help you:

let promise = Promise.resolve([1, 2, 3]); // Promise<number[]>

type GetTypeOfPromise<T> = T extends Promise<infer S> ? S : never;

type T1 = GetTypeOfPromise<typeof promise>; // number[]
type T2 = GetTypeOfPromise<Promise<number>>; // number
type T3 = GetTypeOfPromise<Promise<string[]>>; // string[]

By the way, Typescript itself already have a built-in utility for it that has more powerful functionality 👏:

type T4 = Awaited<typeof promise> // number[]

Let's go further. The gaining access to function arguments can be defined like this:

type GetTypeOfFirstArgument<T> = T extends (arg: infer U, ...args) => any ? U : never;

type T1 = GetTypeOfFirstArgument<typeof document.getElementById>; // string
type T2 = GetTypeOfFirstArgument<(arg1: string, arg2: number) => void >; // string

And in the end, maybe the most practical example with React component function.

It can happen that in some libraries, they didn't export the props for their component. But in your code, you really need it. So with infer keyword getting the prop type is possible, and will look like this:

const OutsideComponent: React.FC<{ name: string }> = () => null;

type InferProps<T> = T extends React.FC<infer P> ? P : never;

type Props = InferProps<typeof OutsideComponent>;

This technique allows you to infer the prop types of a React component function even if they aren't explicitly exported

Conclusion

Incorporating infer into your TypeScript toolkit can significantly streamline your code, simplify complex type manipulations, and boost your development productivity. Embrace this powerful keyword to unlock the true potential of type inference in TypeScript. Happy coding! 🚀

🎯 300+ LeetCode Problems are solved: What I Discovered! 💡

0ro — Thu, 17 Aug 2023 16:53:01 +0000

A year ago, I began solving problems on LeetCode. 🚀 Since then, I have successfully finished 300+ problems, and here are my thoughts and conclusions about this journey. 💡

I'm a technical leader in an outsourcing tech company. The last time I attempted a job interview was three years ago, with this company. Now, I've decided to update my interview skills, not necessarily to change my current job, but to explore something new. Frankly, I wasn't entirely new to algorithms, but I had never systematically learned them on a daily basis.

My previous interviews were more like improvisations on unfamiliar problems within a one-hour timeframe. Due to this approach, my results lacked consistency, and most of the time I failed. If you find yourself in a similar situation, this article could be helpful, as I aim to provide a plan. 🎯

So, as mentioned earlier, a year ago, I decided to change this situation, gain confidence, and improve as a specialist. I wasn't aiming for FAANG or any specific destination; I just wanted to handle interviews with minimal stress. I didn't set a concrete goal, so I wasn't afraid of failure. It might not be the typical motivational advice, but it worked for me. 💪

Advice 1: Keep it Simple and Light ✨
I can't claim a 100% success rate in coding interviews now, but luck isn't the only factor anymore.

Everyone learns at their own pace; don't compare yourself to those who solve problems faster. There will always be someone better. I'm not the most productive person, and I was unsure where to start learning algorithms. After some research, I found lists of LeetCode patterns that others had compiled and collected. I used one of these lists, but there are many others available that you can find in the google.

Advice 2: Choose a Problem List as Your Guide 📚
All problems have underlying similarities, and people have already categorized them into patterns. Learning these patterns enables you to recognize them during interviews. Therefore, focus on learning patterns rather than how to solve individual problems.

Advice 3: Learn Patterns, Not Problem Memorization 🧩
Surprisingly, the "Easy" problems on LeetCode aren't always easy. In my experience, LeetCode problems can be classified as follows:

Easy level: Problems with simple patterns and common use cases, or even problems lacking a clear pattern.
Medium level: Problems with patterns that require additional techniques or data structures for solving, or problems with non-trivial use cases for simple patterns.
High level: Problems that combine two or more patterns and data structures.

As you can see, without understanding basic patterns, solving "Easy" problems efficiently on LeetCode becomes a challenge, especially when you need to solve them with optimal time and memory complexity. 🤔

I used this list of patterns for my preparation, but you can use another; it's just an example of what it usually looks like. 😊

Here is my top list of patterns that I didn't know, and I would have never arrived at them during an interview. So, if you learn them, it increases your chances of passing the interview. I've ordered them by the number of problems you can solve by learning each pattern: 📈

BFS/DFS/backtracking - these patterns are amazing; once you understand them, they will stay with you for the rest of your life. Many problems on LeetCode can be solved using these patterns, even problems from the dynamic programming section (not optimally, but still). If you have limited time, focus on learning these patterns – it's your best shot. 🌟
Search algorithms, including binary search, merge, bucket, divide and conquer, and quick sort. 🔍
Heap/Priority Queue. This is an interesting data structure that I had only heard about before and didn't know how it worked internally. Since it was entirely new to me, this pattern seemed very useful, especially if it's not available in your programming language. ⚙️
Trie. Another data structure pattern that's very helpful to know; you definitely can't invent it during an interview. 🌳

I followed this strategy when solving LeetCode problems:

Read the problem. 👀
Do not start coding. ❌
Understand the problem. 🤔
Do not start coding! ❌
Examine the constraints. 📋
Do not start coding!! ❌
Find the pattern for solving it. 🧩
Do not start coding!!! ❌
If you discover a pattern and solution, talk it out loud, and finally, write the code. If not, explore related topics – it might spark an idea; if that doesn't help, proceed to submissions. 💡

As you can observe, the most challenging part is refraining from immediately starting to code a solution.

Advice 4: Find the solution, then code it. 💡👨‍💻

There will be times when you feel slow and frustrated, but remember that some algorithms are built upon problems that were previously solved by scientists who might have even received Nobel prizes for their work. 🥇🧠

Conclusion

I enjoyed the time I spent solving these problems. Of course, if you don't use it, you quickly forget it. However, I'm confident that if you tackle it once, the next time will be faster. Leave a comment how many problems you already solved on Leetcode, share your strategy, I will really appreciate it. Good Luck! 🚀🍀

🚀 VSCode + Vim: The Perfect Match for Coding Domination 💪

0ro — Tue, 15 Aug 2023 18:58:43 +0000

There are already many stories about Vim, detailing how it is useful for developers' lives. It makes screen sharing easier during the interview process or when pair programming at your current job, as familiarity with Vim makes you faster at coding. This enables you to quickly test all your ideas and select the best one. This is my story of adopting Vim and how I grew to love it.

  First attempts 👶

When I began my journey as a programmer, I used to work in the Sublime Text editor—almost everyone at that time used it. And I was content. Only now do I realize how slow I was. However, back then, I wasn't very proficient in programming; I had just started. The pace of my thoughts matched the speed of my typing. So, everything was satisfactory for me—I had never been hindered by typing speed or my efficiency.

  After several years of active programming, I switched to VSCode and began to realize that something was amiss with my efficiency—not due to VSCode itself, but due to how I worked and wrote my code. This was despite the fact that I had learned all the hotkeys that my teammates had never heard of. One day, I came across a video on YouTube showcasing a person performing editor magic. It seemed like he was a hacker character from those movies where they never touch a mouse and just type incredibly fast. It was at that moment I comprehended how slow my speed was and that I needed to make some changes. That experience provided me with motivation; I wanted to be like that guy.  

So, I discovered that the best way to learn Vim is through vimtutor. I'm using macOS, and if you are too, you already have it on your computer. Simply run this command in your terminal:

  

> vimtutor

 It's a nice starting point if you want to give Vim a try. By the way, in lesson 1.2, they will explain how to exit from Vim, so you will not be lost. Don't worry.

  I gave it a try as well, attempting to integrate it into my actual coding workflow, but I found myself uncertain about the next steps. It seemed that everyone in the Vim world had their own Vim configuration with plugins and customized settings. For me, this complexity felt like a challenge—it wasn't user-friendly, and I couldn't even locate the starting point for this journey. So, I abandoned it and returned to VSCode. Nevertheless, thoughts of Vim lingered. I tried it time and again, but without success, ultimately leading me to give up.

After several months of tormenting myself, feeling ineffective, I finally reached a compromise.

 The compromise 🤝

 The compromise came in the form of the Vim extension for VSCode. It seemed to offer the easiest way to integrate Vim into my real-life workflow; all I needed was familiarity with vimtutor. So, I installed it and began using it. Admittedly, my initial progress was slow—slower than my regular mouse movements and VSCode shortcuts. However, I was determined to improve. After two weeks of consistent effort, my speed surpassed what I had achieved without Vim. 

Some Vim enthusiasts, who are deeply attached to the Vim editor, often contend that Vim plugins are inferior versions of Vim itself. These plugins are often restricted to the code area of your editor, whereas the original Vim gives you full control over various aspects, such as navigating through your file tree using Vim commands, among other things.

I discovered a way to bring this functionality to VSCode. If you're already familiar with VSCode's keybinding system, you know that you can map keys to specific VSCode actions. Now, armed with Vim knowledge, you can adapt this to your keybinding system. For instance, if you want to move between tabs in VSCode, you can press alt+h or alt+l since h and l correspond to left and right movements in Vim. Similarly, to focus on the explorer panel, ctrl+h can be pressed as it's located on the left side of your text editor, and so on.

To make adoption for you easier, I'm happy to share my keybinding configuration with you.

Conclusion 🎉

To summarise, here's all you need to do, to bring VIM in your coding life now:

Complete vimtutor.
Install the Vim extension in VSCode.
Edit your keybindings.json file (navigate to keyboard shortcuts in Settings, then switch to the JSON version).

🚀 One Git Trick for Perfect Commits 🛠️

0ro — Tue, 15 Aug 2023 15:04:04 +0000

Are you tired of seeing vague and meaningless commit messages like:

fix: close pull request discussion
fix: fix review discussion

If you're nodding your head in agreement, it might be time to introduce the "git fixup" technique to your team's workflow, or even just adopt it for yourself.

If the concept seems complicated and overwhelming, don't worry – you're about to be pleasantly surprised. Git fixup is actually quite simple, especially if you're already comfortable with making commits. Let's jump right in! 🏊‍♂️

Imagine you've made several commits on your working branch and have submitted a merge or pull request. However, during the code review, issues were identified—whether by your peers or during your own self-review. Instead of creating separate commits to address these problems, you can simply use the git fixup command. Here's how:

Identify the hash of the commit where the problem was found.
Run the command💡:

git commit --fixup=<commit hash you want to fix>

This command will generate a new commit with the original commit's subject, prefixed with fixup!. This additional commit might seem like a slight inconvenience, but even it is already far better than having vague commit messages cluttering your history.

But we're not done yet. The next step is to incorporate the fixup commit into the original commit using the following command:

git rebase --autosquash -i main

Here's what these parameters mean:

-i: Interactive mode for the rebase.
--autosquash: A special flag that squashes fixup commits into their respective originals.
main: The branch from which your current branch originated.

!!! This is a rebasing command, and you should be aware that this command will change your Git History. So, do it only if you know how it works.

After executing this command, a text editor (VIM by default) will appear. Don't worry—there's no need to make changes. Simply close it by typing :q!.

Congratulations! Your commit history is now clean and organized. You're ready to share your changes with your team. Just use either of these commands to push your changes, depending on your circumstances:

if you work on the branch alone: git push --force 💪
if you share the branch with someone: git push --force-with-lease 🤝

To summarize:

Copy the hash of the commit you want to fix.
Run git commit --fixup=<commit hash>.
Execute git rebase --autosquash -i main.
Check the open text editor and close it if everything looks good (:q!).
Use git push --force to publish your changes.