DEV Community: Marat Latypov

Just another one story how someone deployed Traefik on his pet project

Marat Latypov — Wed, 24 Dec 2025 15:51:43 +0000

These 2 days I deployed Traefik on my pet project.

What for:

Main objective: To integrate Letsencrypt in my few containers
Secondary objective: just to play with

I could paste here my configs, but I don't think it's valuable. Mainly I used this example:

https://github.com/bluepuma77/traefik-best-practice/blob/main/docker-traefik-dashboard-letsencrypt/docker-compose.yml

The main ideas which I want to be noted here

Don't hesitate to read the logs

If you use containerized Traefik - you can run
docker compose up instead of docker compose up -d.

It's great way to check what's going on if something works wrong

Don't edit `acme.json` manually

This file should be generated automatically. It's good idea to store this file in volume.

How to check if SSL keys are generated

How can you check the content of the acme.json file? Just enter the container!

$ docker compose exec traefik /bin/sh
/ # cat /letsencrypt/acme.json

Of course I assume you use traefik name for your service and /letsencrypt/acme.json as your storage.

How to set dashboard password

As shown in the example above you should set your username and password in docker-compose.yml. The password should be hashed.

To generate your new password you can use openssl command. For example

$ openssl passwd -apr1 
Password: 123 # enter your password here
Verifying - Password: 123  # repeat your password here
$apr1$MNPbfepz$SoqRD8ruMR09G/IP8cZ1g.

Remember to duplicate the dollar sign $, otherwise traefik treats it in some special way

So in our case your hashed password to paste is:
$$apr1$$MNPbfepz$$SoqRD8ruMR09G/IP8cZ1g.

Understanding the PostgreSQL Crosstab Function

Marat Latypov — Sun, 13 Jul 2025 16:45:20 +0000

Usually piece of data in SQL is represented as a row in a table. But often it's convenient to represent it as a cell in pivot table. And crosstab could help us in it.

Let's see how it works.

Preparing data

First of all let's prepare data. Here I created tables a and b, and so-called "join table" c, which is related to a and b.

create sequence myseq start 1;
create table a
(
    id   bigint default nextval('myseq'::regclass) not null primary key,
    name text NOT NULL
);

create table b
(
    id   bigint default nextval('myseq'::regclass) not null primary key,
    name text NOT NULL
);

create table c
(
    a_id bigint not null references a(id),
    b_id bigint not null references b(id),
    value text
);

Now let's seed our tables with data.

insert into a (name) values ('a1'), ('a2'), ('a3');
-- Result:
-- +--+----+
-- |id|name|
-- +--+----+
-- |1 |a1  |
-- |2 |a2  |
-- |3 |a3  |
-- +--+----+

insert into b (name) values ('b1'), ('b2'), ('b3');
-- Result:
-- +--+----+
-- |id|name|
-- +--+----+
-- |4 |b1  |
-- |5 |b2  |
-- |6 |b3  |
-- +--+----+

I used one shared increment sequence for both tables, which is why the id in table b starts from 4 instead of 1.

Just keep this in mind.

Next let's populate the join table c.

insert into c (a_id, b_id, value) values
(1, 4, 'v14'),
(1, 5, 'v15'),
(1, 6, 'v16'),

(2, 4, 'v24'),
(2, 5, 'v25'),
(2, 6, 'v26'),

(3, 4, 'v34'),
(3, 5, 'v35'),
(3, 6, 'v36');

Case #0 Cartesian product

Now let's make a simple inner join.

select 
    a.name as a_name, 
    b.name as b_name, 
    c.value
from c
inner join a on a.id = c.a_id
inner join b on b.id = c.b_id
order by 1, 2;
-- Result:
-- +------+------+-----+
-- |a_name|b_name|value|
-- +------+------+-----+
-- |a1    |b1    |v14  |
-- |a1    |b2    |v15  |
-- |a1    |b3    |v16  |
-- |a2    |b1    |v24  |
-- |a2    |b2    |v25  |
-- |a2    |b3    |v26  |
-- |a3    |b1    |v34  |
-- |a3    |b2    |v35  |
-- |a3    |b3    |v36  |
-- +------+------+-----+

In the output result we see all the data in rows. Each row is a piece of information.

There is nothing special here

Case #1 Our pivot table using `crosstab`

Now let's make a pivot table from it

select *
from crosstab(
    'select
        a.name as a_name,
        b.name as b_name,
        c.value
    from c
    inner join a on a.id = c.a_id
    inner join b on b.id = c.b_id
    order by 1',
   'select name from b order by 1'
) as crosstab_alias (a_name text, b1 text, b2 text, b3 text);

-- Result:
-- +------+---+---+---+
-- |a_name|b1 |b2 |b3 |
-- +------+---+---+---+
-- |a1    |v14|v15|v16|
-- |a2    |v24|v25|v26|
-- |a3    |v34|v35|v36|
-- +------+---+---+---+

Wow! This result looks much better!

Let's look at the query

crosstab(text source_sql, text category_sql)

Crosstab function produces table and have 2 parameters : source_sql and category_sql.

source_sql - SQL used to retrieve the source data, in our case it's our previously written query with inner joins.
category_sql - SQL used to retrieve the category names that will be used as column headers.

Source data has some restrictions:

The first column must be the row identifier (in our example a_name). It should be unique for each row in pivot table.
After row identifier column could be some extra fields. In our example we don't have them.
The next mandatory column is the category identifier (in our example b_name). It should be unique for each column in pivot table.
The last mandatory column is the value (in our example value). It can be any data type.

One more important thing is table alias and column aliases in our example it's the line

as crosstab_alias (a_name text, b1 text, b2 text, b3 text)

The alias crosstab_alias is quite common thing in SELECT queries. It's nothing special — aliases are often assigned to tables in queries for easier reference later on.

The next mandatory thing is column description with types. So it should contain:

row identifier (for ex. a_name text)
optional extra fields, if you have some
categories columns (for ex. b1 text, b2 text, b3 text)

That's it!

Case #2 Nonexistent data in the pivot table

Now let's play with the data. What if we don't have full table?

delete from c; --delete previous data
insert into c (a_id, b_id, value) values 
   (1, 4, 'v14'),
-- (1, 5, 'v15'), removed line
   (1, 6, 'v16'),
   (2, 4, 'v24'),
   (2, 5, 'v25'),
-- (2, 6, 'v26'), removed line
-- (3, 4, 'v34'), removed line
   (3, 5, 'v35'),
   (3, 6, 'v36');

When we run our previous crosstab query on such data, we will get:

-- Result:
-- +------+----+----+----+
-- |a_name|b1  |b2  |b3  |
-- +------+----+----+----+
-- |a1    |v14 |null|v16 |
-- |a2    |v24 |v25 |null|
-- |a3    |null|v35 |v36 |
-- +------+----+----+----+

So now we see that empty slots with no data are replaced by NULLs!

Looks great for me!

Case #3 Duplicated data in pivot table

Previously we noted that

row identifier of pivot table should be unique
category column of pivot table should be unique It's quite reasonable! Otherwise what should be shown in the cell?

But what if in our database we have two entries for the same row and column?

delete from c; --delete previous data if you need
insert into c (a_id, b_id, value) values
       (1, 4, 'v14'),
       (1, 5, 'v15'),
       (1, 6, 'v16'),
       (1, 6, 'v16 duplicate'),
       (2, 4, 'v24'),
       (2, 5, 'v25'),
       (2, 6, 'v26'),
       (3, 4, 'v34'),
       (3, 5, 'v35'),
       (3, 6, 'v36');

What does mean this duplicated data entry in our case, it looks like a nonsense as for me.

But assume we have something like that and let's see what will happen.

Our crosstab query will return result:

-- Result:
-- +------+---+---+-------------+
-- |a_name|b1 |b2 |b3           |
-- +------+---+---+-------------+
-- |a1    |v14|v15|v16 duplicate|
-- |a2    |v24|v25|v26          |
-- |a3    |v34|v35|v36          |
-- +------+---+---+-------------+

Ouch! From two data entries for relation a1-b3 only the latest is shown.

Why the latest? Why not the first? No idea, I don't know, it's on PostgreSQL implementation. Maybe it uses the latest value, maybe chooses randomly.

Anyway it sounds bad. You shouldn't have any duplicated entries in you table. Maybe entries should be aggregated somehow, or filtered.

That's all!

Tagged services in Symfony new look

Marat Latypov — Wed, 09 Jul 2025 12:25:43 +0000

A few years ago, I wrote an article titled Strategy pattern in Symfony. It was good for its time and is still relevant, but now it's a bit old-fashioned.

Using attributes

Now I'd rather define services using attributes instead of services.yml:

#[AutoconfigureTag(self::TAG)]
interface ImageResizeStrategyInterface
{
    public const TAG = 'image_resize_strategy';
    public function supports(string $imageType): bool;
    public function resize(string $filename, int $newWidth, int $newHeight);
}

Using support method

Another change, I prefer supports method to check if the strategy is applicable to the case.
Every time, every case. This way I don't have to spend any time thinking of naming :)

class ImageJpgResizeStrategy implements ImageResizeStrategyInterface
{
    #[\Override]
    public function supports(string $imageType)
    {
         return 'JPG' === $imageType;
    }
    #[\Override]
    public function resize(string $filename, int $newWidth, int $newHeight)
    {
      ...
    }
}

Using support method our resizer looks quite different now

class ImageResizer
{
    public function __construct(
        /** @var ImageResizeStrategyInterface[] */
        #[TaggedIterator(ImageResizeStrategyInterface::TAG)]
        private readonly iterable $strategies,
    ) {
    }

    public function resize(string $filename, string $extension, int $newWidth, int $newHeight) 
    {
        foreach($this->strategies as $strategy) {
            if($strategy->supports($extension)) {
                $strategy->resize($filename, $newWidth, $newHeight);
                return;
            }
        }

        throw new \Exception('Unhandled extension');
    }

That's it

Removing orphaned Parents with Doctrine

Marat Latypov — Fri, 17 May 2024 09:54:53 +0000

Previously, we considered a common real-life case where, to maintain referential integrity, we might delete all child entries when the parent entry is deleted. For example to delete author with all his articles.

But what if we have to remove author, when article is to be removed?

I know. It sounds crazy! It sounds like a nonsense!

Or no?

Real-Life Case

Here is a real-life case where we'd rather remove parent entry with child entry.

⚠ Warning! This situation looks like a mistake in DB structure design, but who said that all DB's in our universe are flawless?

Suppose we have an Attachment entity and attachments table, which contains a data about attachment files, sizes, paths, extensions, etc. Suppose your project has a bunch of entities, which could have an attachment. For example in the blog application Author can have some profile photo, the same time Post can have a specified cover image, or thumbnail image or something else.

The most obvious way to use attachments in Author and Post entities is to create attachment_id field and foreign key for it.

And here we have two questions:

Could one attachment be shared by several authors or posts in our case?
What should be done with attachment entry when related author or post is to be removed?

In theory this DB structure allows the same attachment to be used multiple times in different places. And from this point of view you should not remove attachment entry when you delete the related entry.

But in practice when building application forms it's much easier to create Upload new attachment field than Upload new attachment, or select existing one. And if your app is built this way, there are no options for attachments to be shared. And in this case, if you delete some post, the orphaned attachment will stay in DB.

Is it Ok? In my opinion it should be removed too!

Of course it can be done manually. But let's use Doctrine

Remove parents with Doctrine

Now we're going to try remove attachment entries related with some post. And we assume attachment entries are not shared with any other post or author or anything else! It's important!

With this assumption Doctrine association attributes in Post entity could look like this:

#[ORM\ManyToOne(targetEntity: Attachment::class, cascade: ['remove'])]
#[ORM\JoinColumn(nullable: true, onDelete: 'SET NULL' )]
private ?Attachment $attachment = null;

Here we use cascade attribute of ManyToOne. I think Doctrine developer had added the cascade attribute to the ManyToOne association, thinking of cascade persist, not cascade remove. But it works this way too 😈.

So now we can try to delete the post:

$post = $posts->find(1); // Suppose we are going to delete post number 1
$entityManager->remove($post);
$entityManager->flush();

This will cause Doctrine to execute the next queries:

SELECT attachment_id FROM posts WHERE posts.id = 1; 
-- Suppose we found attachment_id = 10
DELETE FROM attachments WHERE id = 10;
DELETE FROM posts WHERE id = 1;

First of all Doctrine fetches attachment ids, then tries to delete found attachments, and finally tries to delete the article.

Important! To allow the removal of an attachment before an article, it should probably set onDelete: 'SET NULL' on the $attachment field. And the field should be nullable of course.

And it works!

Instead of a conclusion

So we used non-standard feature of Doctrine to solve a non-standard problem, which probably should not exists in well designed DB structure.

Sounds like a piece of useless job.

Maybe in our case we should think of DB structure refactor...

Let me know in comments, what do you think about it.

Thanks for reading 😀

Database referential integrity with Doctrine

Marat Latypov — Tue, 07 May 2024 12:42:36 +0000

Here could be extensive AI-generated introduction about Database referential integrity, but not today. Suppose you know what is it. The subject of this article is how you can deal with it using Doctrine.

Actually Doctrine can deal with it in several ways and sometimes it's not so obvious as we want.

Example #1

Suppose we have a blog, entities User and Post, and every post has some author which is one of users.

In the most simple case we create unidirectional 'many-to-one' association

#[ORM\Table(name: 'posts')]
class Post {
    ...
    #[ORM\ManyToOne(targetEntity: User::class)]
    #[ORM\JoinColumn(nullable: false)]
    private User $author;
    ...
}

On MySQL we will get the post table with one foreign key. Everything is easy

create table posts
(
    ...
    author_id  int  not null,
    constraint FK_58A92E65F675F31B
        foreign key (author_id) references users (id)
);

create index IDX_58A92E65F675F31B
    on posts (author_id);

So what we have now?

Now we have a constraint on DB level, which blocks any attemts to delete user which is linked as an author to some blog post

[23000][1451] 
Cannot delete or update a parent row: a foreign key constraint fails 
(`database`.`posts`, CONSTRAINT `FK_58A92E65F675F31B` FOREIGN KEY (`author_id`) REFERENCES `user` (`id`))

There are no difference do you try to delete it directly in database or through your application. It's database constraint and it works this way.

Example #2

So now we can't delete a guy who has a post in our blog. But what if we must be able do it sometimes?

First of all we have to decide what to do with posts of deleted author? For example we could want to delete them too. I this case we can add onDelete option:

#[ORM\Table(name: 'posts')]
class Post {
    ...
    #[ORM\ManyToOne(targetEntity: User::class)]
    #[ORM\JoinColumn(nullable: false, onDelete: 'CASCADE' )]
    private User $author;
    ...
}

In this case our foreign key will get on delete cascade

create table posts
(
    ...
    author_id    int          not null,
    constraint FK_58A92E65F675F31B
        foreign key (author_id) references users (id)
            on delete cascade
);

create index IDX_58A92E65F675F31B
    on posts (author_id);

This means if we delete user all his posts will be removed too.

But remember, some posts can have comments. Do you want remove them too? All the comments to the posts written by this guy? In this case you probably should the same cascade trick with comments

One important thing here is that all this logic is done by DB server. Doctrine does nothing with it. From doctrine level everything you do is just about removing user.

Example #3

Let's think about application logic. Is it so bad if some post will not have author? If the only effect there will be no author on the page from some point of view it could be acceptable. So we can just clear author field in this case.

In this case we need to make it nullable first, and then change onDelete parameter

    #[ORM\JoinColumn(nullable: true, onDelete: 'SET NULL' )]
    private ?User $author = null;

In this case our field in database will look like this:

    constraint FK_58A92E65F675F31B
        foreign key (author_id) references users (id)
            on delete set null

And this is enough.

Just want to note again, all these cases will be handled by DB server. Doctrine has nothing to do here

Example #4

Let's step back and now we want to remove posts with author. We want the same effect, but using Doctrine. Here we will need bidirectional association

So in Post entity we put this:

  #[ORM\ManyToOne(targetEntity: User::class, inversedBy: "posts")]
  #[ORM\JoinColumn(nullable: false)]
  private ?User $author = null;

And in User entity this:

  #[ORM\OneToMany(targetEntity: Post::class, mappedBy: 'author', cascade: ['remove'])]
  private Collection $posts;

Of course we'll have to add constructor, and getters/setters if you need. But in general this code will work!
It acts like onDelete: 'CASCADE'. The main difference is that now Doctrine does all the things.

Actually now Doctrine generates a bunch of sql-queries to delete user, something like this:

-- fetch post IDs for the author
SELECT post.id FROM posts as post WHERE post.author_id = AUTHOR_ID;
-- delete posts one by one
DELETE FROM posts WHERE id = POST_ID_1;
DELETE FROM posts WHERE id = POST_ID_2;
...
DELETE FROM posts WHERE id = POST_ID_N;
-- finally delete the author
DELETE FROM users WHERE users.id = AUTHOR_ID;

Example #5

Absolutely the same effect will be using orphanRemoval: true

Just use it in User entity

  #[ORM\OneToMany(targetEntity: Post::class, mappedBy: 'author',  orphanRemoval: true)]
  private Collection $posts;

Here are described the most common cases.

How to hydrate trees in Doctrine

Marat Latypov — Sun, 12 Nov 2023 12:55:05 +0000

Few sprints ago I had an interesting task. I should get from database a tree structure and render it using Twig.

This tree was stored in the table with parentId field, nothing special, and the most obvious way to get the tree is to fetch root element first. The best for rendering is ORM, it allows to render tree recursive from parent to children. And here I could stop writing this article, because this will work.

The only thing I don't like here is that it will cause additional SQL request for every tree node children. At SQL level it will look like like this:

SELECT * FROM table_name WHERE parent_id=0; 
-- for example return a record with ID=1 

SELECT * FROM table_name WHERE parent_id=1;
-- here we get a bunch of records with different IDs

SELECT * FROM table_name WHERE parent_id=X;
-- and so on for every tree node
...

Is it problem? Probably not, if you have a small tree. And if you're sure it always will be small. Otherwise executing unpredictable count of SQL request from PHP could be a big deal.

So probably we have to find some way to hydrate whole tree by a single SQL request.

At first sight we could recursively join the table to itself on parent_id field. But we can't predict join count. That's a problem, and it could be better to fetch nodes by one.

So what can we do?

How Doctrine hydrates objects

First of all let's look how hydration works in Doctrine and how objects are hydrated. This is a quote from the

Object Hydration
section of Doctrine manual

Objects fetched in a FROM clause are returned as a Set, that means every object is only ever included in the resulting array once. This is the case even when using JOIN or GROUP BY in ways that return the same row for an object multiple times. If the hydrator sees the same object multiple times, then it makes sure it is only returned once.

What does it mean? Let's fetch the same post from Blog table twice

/** @var Post $post1 */
$post1 = $postRepository->find(1);
/** @var Post $post2 */
$post2 = $postRepository->find(1);

if($post1 === $post2) {
    dump('It is the same object');
} else {
    dump('It is NOT the same object');
}
// Output: "It is the same object"

Wait, wait!

We could expect that variables $post1 and $post2 contain the same post data, but it's not just a copy!
Actually these variables are links to the same object in the memory!

Let's play with it.

Experiment #1

If you change title of $post1, what will be with the title of $post2?

Spoiler: It will be changed too :)

$post1->setTitle('Some title');
if($post2->getTitle() === 'Some title') {
    dump('Title is the same: "Some title"');
};
// Output: 'Title is the same: "Some title"'

$post1->setTitle('Some title 2');
if($post2->getTitle() === 'Some title 2') {
    dump('Title is changed to: "Some title 2"');
};
// Output: 'Title is changed to: "Some title 2"'

Experiment #2

What will do this time:

fetch $post1
change title to some new title
fetch $post2

Question: What title will it have?
Spoiler: the changed title.

/** @var Post $post1 */
$post1 = $postRepository->find(1);
$post1->setTitle('Some new title');

/** @var Post $post2 */
$post2 = $postRepository->find(1);
if($post2->getTitle() === 'Some new title') {
    dump('Title is: "Some new title"');
};
// Output: 'Title is the same: "Some new title"'

Wow! It means, Doctrine thinks the title is already fetched and doesn't overwrite it! It doesn't overwrite defined properties at all!

Ok. What about undefined properties?

Experiment #3

We know usually ORM uses lazy fetch mode and that means, that related entities will not be fetched before use. Let's check our $post1's tags

/** @var Post $post1 */
$post1 = $postRepository->find(1);
dump($post1->getTags());
// Output:
// #collection: Doctrine\Common\Collections\ArrayCollection {#577 ▼
//   -elements: []
// }

So, as expected, the tags collection is empty because of lazy fetch mode.

Now let's fetch $post2 with joined tags

$post2 = $postRepository
    ->createQueryBuilder('post')
    ->addSelect('tag')
    ->innerJoin('post.tags', 'tag')
    ->where("post.id = :id")
    ->setParameter('id', 1)
    ->getQuery()
    ->getSingleResult();

dump($post2->getTags());
// Output
//   #collection: Doctrine\Common\Collections\ArrayCollection {#577 ▼
//    -elements: array:3 [▶]
//  }

Here we can see, tags collection is NOT empty. Ok. This is expected too.

And finally go back to $post1 and check tag count:

dump($post1->getTags());
// Output:
//  #collection: Doctrine\Common\Collections\ArrayCollection {#577 ▼
//    -elements: array:3 [▶]
//  }

Surprise! It's changed! Amazing!

We did literally nothing with $post1 but it's changed because of $post1 and $post2 are the same object in memory!

Ok. This was funny, but could we find a usage for this knowledge?

Back to our trees

So here we need some example table. Suppose it's categories in our blog application, suppose it has parent_id field, something like this:

  #[ORM\Entity]
  #[ORM\Table(name: 'categories')]
  class Category
  {
      ...
      #[ORM\ManyToOne(targetEntity: Category::class, inversedBy: 'children')]
      private readonly Category $parent;

      #[ORM\OneToMany(targetEntity: Category::class, mappedBy: 'parent')]
      private Collection $children;
      ...

And let's try fetch and hydrate all categories in the most stupid way:

  $categories = $categoriesRepository
    ->createQueryBuilder('category')
    ->getQuery()
    ->getResult();

Ok. Using this code we fetch and hydrate all the categories. But because of lazy fetch mode we will not get children

So what next? What if we join and fetch children in the most stupid way?

$categories = $categoryRepository
     ->createQueryBuilder('category')
     ->addSelect('children')
     ->leftJoin('category.children', 'children')
     ->getQuery()
     ->getResult();

So now we have hydrated children for each category. But could we use this query result for categories tree recursive render?

We don't need just every category children been hydrated. We need every child children been hydrated too!

And the core question is: will doctrine hydrate every child's children too?

Yes, of course!

We hydrate ALL the categories
Children are categories too
As we know the hydrator will not create new brand new empty child category instance, just return previously fetched category

Instead of summary

What I have to say - it blows my mind!

This problem in real world demands

fetching root first, then children of root, then children of children and so on
or fetching root with joined children of root, then joined children of children and so on ...

But thanks for the known feature of Doctrine hydrator we did it in a simple request with ONE join!

Amazing!

Have a nice day!

Strategy pattern in Symfony

Marat Latypov — Fri, 29 Sep 2023 14:37:45 +0000

In general, we use the Strategy Pattern when we can do something in several ways depending on some condition. Suppose we have to create some image resize class using GD library.

We could create some code like this:

class ImageResizer
{
    public function resize(string $filename, string extension, int $newWidth, int $newHeight) 
    {
        switch ($extension) {
            case 'PNG':
                $source = imagecreatefrompng($filename);
                $dest = imagescale($source, $newWidth, $newHeight);
                imagepng($dest, $filename);
                return;
            case 'JPG':
                $source = imagecreatefromjpeg($filename);
                $dest = imagescale($source, $newWidth, $newHeight);
                imagejpeg($dest, $filename);
                return;
            case 'BMP':
                $source = imagecreatefrombmp($filename);
                $dest = imagescale($source, $newWidth, $newHeight);
                imagebmp($dest, $filename);
                return;
            default:
                throw new \Exception('Unhandled extension');
        }
    }

This code will work, but it's not perfect. Everything is written in the same class in a single method. This code does too many things.

First of all let's create separate classes for each resize strategy.

Here is an easy and clean example for JPG resize strategy.

class ImageJpgResizeStrategy implements ImageResizeStrategyInterface
{
    public function resize(string $filename, int $newWidth, int $newHeight)
    {
        $source = imagecreatefromjpeg($filename);
        $dest = imagescale($source, $newWidth, $newHeight);
        imagejpeg($dest, $filename);
    }
}

The rest strategies can look similar. Because of this, it's a good moment to create common interface for all these strategies:

interface ImageResizeStrategyInterface
{
    public function resize(string $filename, int $newWidth, int $newHeight);
}

So our image resize class could be changed now:

class ImageResizer
{

    private ImageResizeStrategyInterface $strategy;

    public function resize(string $filename, string $extension, int $newWidth, int $newHeight) 
    {
        switch ($extension) {
            case 'PNG':
                $strategy = new ImagePngResizeStrategy();
                break 
            case 'JPG':
                $strategy = new ImageJpgResizeStrategy();
                break 
            case 'BMP':
                $strategy = new ImageBmpResizeStrategy();
                break 
            default:
                throw new \Exception('Unhandled extension');
        }

        $strategy->resize($filename, $newWidth, $newHeight)
    }

And that's Strategy Pattern for! We moved our resize logic for each image type somewhere else and made our code clearer!

What about Symfony

➡️ This part of the article is a bit old-fashioned. Updated walk-through is here

But could we get rid of this ugly switch-case construction?

Yes! In Symfony we can use reference tagged services.

Put in your services.yml these lines

_instanceof:
    App\SomePathHere\ImageResizeStrategyInterface:
        tags: [ 'image_resize_strategy' ]

App\SomePathHere\ImageResizer:
    arguments:
        - !tagged_iterator { tag: 'image_resize_strategy' }

This will cause that our ImageResizer class will get an array or strategies as a parameter in constructor:

class ImageResizer
{
    private array $strategies;

    public function __construct(iterable $strategies)
    {
        $this->strategies = $strategies instanceof \Traversable ? iterator_to_array($strategies) : $strategies;
    }
   ...

But now all strategies are in a plain array and there is no sign what is each strategy for. To separate them we need some method in each strategy which will give us some information about it

Let's change our interface and add getImageType method there:

interface ImageResizeStrategyInterface
{
    public function resize(string $filename, int $newWidth, int $newHeight);
    public function getImageType(): string;
}

Then we have to add this method in each strategy. Something like this:

public static function getImageType(): string
{
    return 'JPG'; // Or something else
}

Now we can rewrite our resize method using getImageType function:

public function resize(string $filename, string $extension, int $newWidth, int $newHeight) 
{
    foreach($this->strategies as $strategy) {
        if($strategy->getImageType() === $extension) {
            $strategy->resize($filename, $newWidth, $newHeight);
            return;
        }
    }

    throw new \Exception('Unhandled extension');
}

Or we can add index to the strategies array, just add default_index_method option in your services.yml

  - !tagged_iterator { tag: 'image_resize_strategy', default_index_method: 'getImageType' }

This will make your strategies array indexed. So the resize method of the class can look this way:

public function resize(string $filename, string $extension, int $newWidth, int $newHeight) 
) {
    if(!isset($this->stategies[$extension])) {
        throw new \Exception('Unhandled extension');
    }

    $strategy = $this->stategies[$extension];    
    $strategy->resize($filename, $newWidth, $newHeight)
}

Easy reading, clear and beautiful code!

Make your state safe

Marat Latypov — Fri, 26 May 2023 08:42:58 +0000

Imagine you have a simple component Post which just renders a post page.

export const Post = (): JSX.Element => {
  const [value, setValue] = useState<string>()
  const url = 'http://somewhere.com/something'

  useEffect(() => {
    axios.get(url).then<string>((response) => {
      setValue(response.data)
    })
  }, [])

  return <div>{value}</div>
}

Just for simplicity purpose let's output just a single string.

And now a question: What will be if we go to another page (or Post component will be unmounted in some other way) before the data load finish?

In this case we will get this warning in the console:

Nothing is broken. The app still works. App users may not even notice any problems except for the red warning in the console.

You can leave it as is, but you should know that each such event causes a memory leak. At some point, it could become a problem.

The easiest solution is to use the useSafeState hook from the ahooks package. Just replace your useState with useSafeState, and everything will work out of the box.

const [value, setValue] = useSafeState<string>();

I highly recommend to check the source code of useSafeState and research how it works. The code is not too large, so it's not a big deal.

By the way useSafeState under the hood uses highly usefull useUnmountedRef hook, which checks if component is unmounted.

However, that is a topic for another story :)

useQuery: isFetching vs isLoading

Marat Latypov — Mon, 10 Apr 2023 10:01:40 +0000

In additional to query status useQuery has so called fetchStatus and isFetching flag. It causes very frequent question about the difference of these flags so I'm trying to explain it.

isFetching and isLoading are not the same

Yes. Mostly if you load data - you fetch data. But in useQuery terms it's become more complicated for some special cases.

To be precise flag isFetching is actually about fetching process, it includes fetching itself or refetching data in some cases.

The same time flag isLoading is more about state from application point of view.

So what does it mean?

Loading does not always mean Fetching

Let's look at the case loading state of dependent queries in version 4

From the very beginning dependent query is in loading state, but is not fetching before another query success

In this case we have:

isLoading: true
isFetching: false ⚠️

So in this case we have set loading, but not fetching status!

And vice versa

Fetching does not always mean Loading

This is the case when we have set fetching status, but not set loading status!

Do you remember, that useQuery can fetch some data after loading state, being in success state? It's so called refetch and could be catched using flag isRefetching. In this situation we have flags

isLoading: false ⚠️
isSuccess: true
isFetching: true
isRefetching: true

That's it!

Conclusion

These cases are not very obvious, but still can happen at any time. So better to know!

Explaining useQuery states

Marat Latypov — Mon, 10 Apr 2023 08:53:29 +0000

In the world of React.js useQuery is well-known fetching tool with great documentation. However, often developers have some problems with status understanding, so I had to clarify it for myself.

Preparing

Before we start research useQuery statuses we should have some hook using it. Let's create one.

interface Quote {
  id: number,
  quote: string,
  author: string,
}

export const useRandomQuote = (): UseQueryResult<Quote> => {
  const url ='https://dummyjson.com/quotes/random';
  const fetchData = (): Promise<Quote> =>
    axios.get(url).then<Quote>(response => response.data);

  return useQuery<Quote>({
    queryKey: ['quote'],
    queryFn: fetchData,
  });
}

In my example I used API to get random quote. Or course it's just an example, it could be any other API.

Using the hook

Let's try use it now:

export const SomeComponent = (): JSX.Element => {
  const result = useRandomQuote();

  // result.data can be undefined
  return <h1>{result.data?.quote}</h1>
}

Here we are fetching some random quote and rendering it. The hook returns UseQueryResult type, which has data field with our quote, which has type Quote.

The point is that at the beginning data probably is not loaded yet, so it could be undefined. That's why we have to use result.data?.quote instead of result.data.quote.

And here is a good place for a placeholder.

  const result = useRandomQuote();

  if(result.isLoading) {
    return <h1>Loading ...</h1>
  }
  // but result.data still can be undefined
  return <h1>{result.data?.quote}</h1>

Ok. We handled isLoading status, but result data still can be undefined. It's because there could be a error during data fetch.

Let's add some check

  const result = useRandomQuote();

  if(result.isLoading) {
    return <h1>Loading ...</h1>
  }

  if(result.isError) {
    return <h1>Error ...</h1>
  }

  return <h1>{result.data.quote}</h1>

And now data is defined and we can safely use it. Cheers!

If you use useQuery ver.3 you probably should handle isIdle flag in addition to isLoading and isError to be sure that the data is properly defined.

Suppose you have some error handler, in this case you probably don't want to handle error in components. In this case you can use isSuccess flag:

  const result = useRandomQuote();

  if(!result.isSuccess) {
    // We use isSuccess flag
    // So we have to deal with "loading" and "error" statuses here
    // But we handle here only "loading" case here, 
    // Because the "error" case is catched somewhere else
    return <h1>Loading ...</h1>
  }

  return <h1>{result.data.quote}</h1>

It looks the problem is solved now!

Query States summary

Let's look closer at the states of useQuery

Loading state	Success state
This is the query state while data is loading	This is the query state when data has been successfully fetched
isLoading: true	isSuccess: true
data: undefined	data: is fetched, defined and could be safely used

In addition there are two error states

It's a bit complicated. Sometimes useQuery fetches data, and sometimes re-fetch it. So error could be thrown in two cases

Loading error state	Refetch error state
isError: true	isError: true
isLoadingError: true	isRefetchError: true
data: undefined	data: is fetched before and cached, so it could be safely used

Idle state should be noted.
This state had place in useQuery version 3 and removed in version 4.
It was about state of dependent query which has to wait for some another query before start loading

Continuation is here:

useQuery: isFetching vs isLoading

Clear as the sun explanation of De Morgan's laws

Marat Latypov — Sat, 01 Apr 2023 12:38:17 +0000

Sometimes, novice developers struggle with basic logic expressions, especially De Morgan's laws. To help with this, I have prepared a simple explanation.

The following examples were made using a small React app that I created for this article. You can choose to download and play with it or not 😀️. The following text doesn't require the app installation.

Step 1. Where are we from

Ok. Let start with the basics. How looks a&&b result? I think everybody knows:

Step 2. Let's play with it

What if we negate b in this expression? Just imagine the column where b was true will changed to false, and vice versa. The matrix will be flipped horizontally, like reflection in a mirror!

And if we negate a, it will be flipped vertically:

Step 3. Try a little bit harder

What if we negate both a and b the same time? Right! The matrix will be flipped in both directions - horizontally and vertically:

Step 4. The Final

Nice, and what if we negate the entire expression after negating a and b? In that case the values in the matrix will change from true to false, and vice versa:

But wait! It looks like matrix for a||b!

Actually that's the de Morgan's Law

!(!a&&!b) === a||b or !a&&!b === !(a||b)

I hope this article was helpful.

Sprinters vs marathonians

Marat Latypov — Sat, 01 Apr 2023 08:21:34 +0000

It's amazing, but developers are different! And I don’t mean different programming languages or stacks. I mean a programming philosophies.

Some programmers, let’s call them “sprinters”, write code that just works. This is the only internal acceptance criterion.

Others , let’s call them “marathonians”,write code not only to make it work, but also to be able to maintain it for years.

The main difference is that “sprinters” don't write tests and actually don't care about coding style. The “marathonians” are obsessed with coding style and tests writing to the point where sparks fly, keeping in the mind SOLID and other dev tricks.

The “marathonians” don't like “sprinters” - they write sloppy code, "just to get it done".

The “sprinters” don't like the “marathonians” - they are doing tons of “useless“ work, “art for the sake of art”.

At first sight, long-term maintenance-focused programmers do things the best way. However, they often come at a higher cost and spend more time on coding.

Who knows? Maybe for short-term, low-budget projects, we should act more like "sprinters"?