Valera Vilks Site

Tag: wordpress

  • The story of my first job as a Frontend developer

    In 2019, I took a React course. It lasted about 2 months. At that time, I had absolutely no work, and I thought that after completing this course, I would start working in Frontend. At that time, I was looking for work on the Kwork freelance exchange. Now it only evokes negative emotions. The work there is literally “for bread.” But I had no choice.

    On Kwork, I started working with one of the clients. He had a startup, and he wanted to create some service for advertisers. Something like an analytical service. I agreed to work with him as a frontend developer. There was also a backend developer who created the API. As you can guess, I started working on React for this. We agreed to work 4 hours a day with an hourly rate of $4, which at that time was about 300-350 rubles.

    I started working the first week. Everything was pretty good. The client liked everything. Anyone who has done anything in frontend or just in some kind of development understands that it is impossible to develop something in 4 hours a day. This is just some kind of start and a minimal prototype. During that week, such a minimal prototype was created that already did something. I got my money for this week.

    I started working the second week, some work was also done, and a starting UI was created. Yes, we worked without any precise prototype or design. We were displaying information based on search and examples of advertising, as we were creating an advertising service. The second week was successful, and I got my money.

    On Monday of the following week, I received a message that they would no longer continue working with me. It was quite strange to me. Everything seemed great. In the message, I read that the client had found a new frontend who had done all the work on Vue that I had done in 2 days off. I just didn’t believe it. It was quite difficult emotionally. Was I such a bad developer that someone did in 2 days what I did in 2 weeks? I couldn’t believe it. It was certainly difficult.

    Since I had the site URL, I could see how the new frontend had done everything so quickly. And, of course, to my surprise, it was my code that I had done in 2 weeks. I had access, so I saw it. No Vue at all. I immediately informed my client that it was impossible to do this work in 2 days and said that my code had been used. He gently stated that I was just not competent enough and was jealous of the “expertise” of the new frontend developer.

    From an emotional point of view, I was quite offended at that moment. Now I understand that I did everything right. Yes, it wasn’t perfect, but it was workable. I felt that after hard work for 2 months, I couldn’t do anything in React, or I was doing it incredibly slowly. When this is your only income, when there is no alternative, it is quite stressful to lose your last earning opportunity.

    After that, I followed the URL of this project for a few more weeks (although, in truth, I visited this URL every day). The project stopped at what was done in those “incredible weekend”. I don’t know what happened after that; I forgot about this project.

    What conclusions did I draw from this work? Not only you can be a beginner in your business, but also the client. He may not understand or have inflated expectations. I don’t blame this client; he fulfilled all his obligations to me. He paid everything as agreed. I also understand that if a project does not have money to start, then its owner probably does not fully understand what is happening. When you go into something like this, there is a high percentage of inadequacy towards you.

    In such a situation, it is easy to lose the motivation to move on. My main mistake in this story is that you don’t need to lose your source of income until you have achieved a good knowledge in a new business. This is very important. I had a job at a factory. Yes, I didn’t like it, but it gave me a steady income.

  • One complex or many simple components?

    What is the best approach for component development? Is it one complex component or many simple ones? Let’s consider it in this article.

    One complex component

    There is no doubt that there is a fairly common approach that is used all the time. You can see this approach in a lot of libraries.

    <x.button type="primary">
   This is button
</x.button>

<x.button type="secondary">
   This is button
</x.button>

    This component is stored in one file button.blade.php. Here is an example of this file

    @props(['type' => 'primary'])

@php
    $classes = $type === 'primary' 
        ? 'bg-blue-500 text-white px-4 py-2 rounded'
        : 'bg-gray-500 text-white px-4 py-2 rounded';
@endphp

<button {{ $attributes->merge(['class' => $classes]) }}>
    {{ $slot }}
</button>

    As you can see, here we have conditions inside the component. Imagine that you need to add several more types of buttons to the button, then you need to add an icon, and also animation. You need to understand how complex this component will be.

    Also, the downside is that you have to be very careful with this component. If you add something, you need to be sure that you did not break other options. This requires some attention.

    Let’s also think about working in a team. Your colleagues see a Pull Request with changes in the button.blade.php file. Everyone also needs to carefully check that other button options are not broken in this file.

    Of course, the advantage is that there is less Copy/Paste and you can combine something common in the buttons. Speaking from my experience, some of these components turn into very complex components that are incredibly difficult to understand.

    Lots of simple components

    Now let’s make an example for creating 2 components in different files.

    <x.button.primary>
   This is button
</x.button>

<x.button.secondary>
   This is button
</x.button>

    button/primary.blade.php

    <button {{ $attributes->merge(['class' => 'bg-blue-500 text-white px-4 py-2 rounded']) }}>
    {{ $slot }}
</button>

    button/secondary.blade.php

    <button {{ $attributes->merge(['class' => 'bg-gray-500 text-white px-4 py-2 rounded']) }}>
    {{ $slot }}
</button>

    There are no conditions inside the components. Everything is simple, just layout.

    Of course, the advantage here is the simplicity of the component and that it is quite clear at first glance.

    Also, if someone makes a Pull Request with a change to the primary button, you will only see the changes in the primary.blade.php file. You can accept such a PR quite easily, since you will be sure that the changes apply only to one version of the button and do not affect other options.

    I would like to be more detailed here. In practice, I see that it is difficult for me personally when I see a lot of changes in different files in a Pull Request. It is difficult for me to be sure that everything is in order there. If we have simple components, then we can lower the importance of some Pull Requests. For example, we can devote more time to those Pull Requests that do something more complex. Simple Pull Requests can be accepted much faster and without much checking.

    Of course, there are also disadvantages. The main one is that we do not reuse some code. You can notice that the buttons are quite similar and the code base will be larger. Imagine how many button options you can have. Incredible.

    Summary:

    These 2 approaches have a right to exist. You can choose any of these approaches, if used correctly, it works great.

    If we talk about my opinion, then I like the approach of using simple components more. It looks more transparent and beneficial when working in a team.