DEV Community: Michael Grechka

How Crash Courses Can Hold You Back

Michael Grechka — Mon, 09 Sep 2024 21:29:43 +0000

Read the post in Telegram: https://t.me/mike_in_web/5

When I started learning frontend, like a lot of people, I went through different tutorials and courses where the goal was to build some kind of project. The problem with this approach is that you're handed a solution.

You don't really get the chance to think things through or figure them out on your own, so you end up in a situation where, yeah, you know how to do something, but your skills become so narrow that if you're asked to do anything slightly different, you fall apart over the simplest stuff. In the end, instead of becoming a web developer, you turn into a “to-do list master,” building the same app over and over, just following the video like a script.

But when you work on a personal project, you’re the one asking the questions: “How do I make this work?” And that’s when real learning kicks in. You’ve got a need, you hit roadblocks, and you end up "reinventing the wheel." Your interest and motivation come naturally because every feature actually matters to you. And then, the best part of learning happens — those "Aha!" moments 😮.

It’s when you hit those roadblocks that you finally think, “Ah! So that’s what [insert tech here] is for,” or “Now I get why you’re supposed to do it this way!” It’s not just some empty lesson you learned because “that’s just how it’s done.”

And what’s cool is that these kinds of projects really help during interviews. You’re not just showing off some tutorial code; you’re showcasing solutions you came up with on your own. That immediately sets you apart from the people who just churned through a course.

So don’t just follow someone else’s plans. Solve your own problems, and your learning will be way more interesting 💫.

Follow me in Telegram: https://t.me/mike_in_web

Is it too late to become a web developer in X year? 🤔

Michael Grechka — Sat, 07 Sep 2024 22:38:00 +0000

When I started learning web development back in 2019, I had the same doubts as everyone else. Even then, website builders were around, and people were already saying (oh no!) that they’d replace all web developers. This concern was always there, but it didn’t stop me from exploring the world of development.

By 2020, when I was finally making some progress, WebAssembly was starting to gain traction. People said it could make front-end developers obsolete by letting programmers compile languages like C# into WASM, so you could have a website written entirely in C#. Why bother learning JavaScript, right?

Then, in 2021, I noticed mobile development taking off, especially with Flutter. It seemed like you could build cross-platform apps for anything, including the web. That made me wonder if websites would even be needed anymore, with mobile apps growing so fast.

In 2022, GitHub Copilot arrived and scared everyone who saw it. Who would’ve thought a programmer could just write plain English, and the program would generate the code automatically? Yet here we are, and the world didn’t end.

Fast forward to 2023, and we started hearing more about the IT job market being oversaturated. Tons of people were coming out of boot camps claiming to have 10 years of experience after just a 3-month crash course. Job postings would get 200 applications within hours. Suddenly, just knowing how to code wasn’t enough anymore. Hiring became a mess.

Now it’s 2024. ChatGPT, Claude, Gemini… Programmers? Who needs them when AI is taking over everything?

Looking back, I’ve realized that there’s always been something to worry about. It’s human nature to doubt. And yeah, it’s scary to think you might waste time on something that could end up being pointless. But those are just fears and excuses.

People have always questioned whether web development is still worth it, and you could spend forever doubting yourself. But over the past five years, you could’ve built a solid career. There will always be reasons not to dive into web development, but the web will keep evolving. So the real question is…

... is it too late to learn web development in 2025? 🤣

Follow me on Telegram: t.me/mike_in_web

How to debug i18n? 🤔

Michael Grechka — Thu, 18 Apr 2024 10:00:00 +0000

I've worked a lot with i18n in different projects (using i18next, next-intl, etc) and what I always lacked was a playground where I could debug the complex template strings.

It was really annoying to always check the result by refreshing the page, especially when the project is too heavy (like 🐌 🐌 🐌) to refresh instantly and you have to wait forever for the page to load after adding just a single missing bracket in the template string 😭.

🎉 Fortunately, I've made the i18n Playground, a tool where you can debug template strings with less effort as you can select a quick preset and forget about reading the docs over and over again. Currently, it only support messageformat which is commonly used across different i18n libraries. 💅🏻

React types you didn't know

Michael Grechka — Wed, 08 Sep 2021 20:55:38 +0000

After working in several companies, I've noticed that the code is always typed differently and this can lead to some issues with typings in the future.

I want to show you how to make code better typed the way you probably didn't know.

Function Component type

First of all, we have to figure out what is the best way to define a function component.

Usually developers do initialise components using default functions so the code would look like this:

function SomeComponent(props: SomeComponentProps): JSX.Element {
   ...
}

Such approach has several disadvantages:

You always need to write the return type
If your component accepts any children you need to define the children property in your Props type and set the type union type like null | ReactNode | ReactNode[] or null | ReactElement – Since you need to use one of types above for your children, you have to import them too

All of these problems make your code more "boilerplaty" and make your code less readable spending more time than you can.

The best solution for this is FC or FunctionComponent types. FC is just a shorthand for FunctionComponent – You can check this here:

type FC<P = {}> = FunctionComponent<P>;

Let's see what this FunctionComponent is:

interface FunctionComponent<P = {}> {
    (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
    propTypes?: WeakValidationMap<P> | undefined;
    contextTypes?: ValidationMap<any> | undefined;
    defaultProps?: Partial<P> | undefined;
    displayName?: string | undefined;
}

Here we also need to check the PropsWithChildren type to make sure what we will pass to the component's props:

type PropsWithChildren<P> = P & { children?: ReactNode };

Now let's see how FC-typed component looks like:

const SomeComponent: FC<SomeComponentProps> = ({ message }) => (
  <div>{message}</div>
);

Current solution solves such problems:

We don't need to define children¹ type anymore
We separate values from types moving generic type to the beginning making the code more readable
We don't need to write a function return type
Since we are using arrow function², we can omit curly braces in some cases and return jsx directly
Using the same component type everywhere we prevent inconsistency of types that can lead to waste of time because of type definition instead of spending it to solve actual problems

1 - Keep in mind that it is planned to remove children as default property from FunctionComponent in @types/react@^18.0.0. In the React 18 you should define children property manually and set ReactNode type to it.
2 – If you are using React Developer Tools you should notice that arrow functions don't have displayName by default so you should define it manually:

SomeComponent.displayName = 'SomeComponent';

Type of regular HTML props / attributes

You've probably had problems with props definition for components that pass most of their props further to the regular html element.

Previously I've seen solutions like importing HTMLAttributes from react module and then passing HTML...Element type to it as a generic argument:

type SomeType = HTMLAttributes<HTMLInputElement>;

This type is not much reusable because we cannot get props of the custom component and this is where ComponentProps comes:

 // regular HTML input element
type InputElementProps = ComponentProps<'input'>;

// ComponentProps works for both regular elements and the custom ones
type CustomInputProps = ComponentProps<typeof CustomInput>;

CSS property type

If you use css-in-js solutions, sometimes you want your component to accept certain CSS-properties passed deeper to the component's styles.

You can just set the property type as a type union: number | string but it is unspecific and can lead to unpredicted behaviour because of typos when using such properties as position, flex-direction, etc.

The better solution is to use CSSProperties type exported from react module:

interface SomeComponentProps {
  display: CSSProperties['display']
}

Such little things may improve the quality of your code and prevent you from having pain with Typescript.