Недавно мне предложили 10_000 RUB за то, чтобы я другому человеку на алгоритмической секции в Т-Банк надиктовывал в наушник решение live-coding задач. Неплохой доход за 1 час "работы", не правда ли?

Как вы думаете, пополнился ли мой банковский счет на 10k? Конечно НЕТ!

Я всегда топлю за то, чтобы проходить собеседование своими силами. Я могу понять, что к алгоритмам нужно готовиться минимум 1 неделю, что такие задачи редко встречаются в работе Front-End разработчика. Тем не менее, это правила "игры". Многие бигтехи (да и другие айти компании) дают алгоритмические задачи на собеседованиях. Это просто нужно принять!

Да и на самом деле, алгоритмы не так уж и бесполезны во Front-End разработке. При решении багов и верстке формы их навряд ли применишь. Но в работе раз в 3 месяца встречаются задачи, где нужно проявить свою экспертизу на максимум и использовать знания алгоритмов для оптимального решения задачи.

При том базовые навыки решения алгоритмических задач помогут вам писать код с разумной сложностью алгоритма (big O). Навряд ли вашему коллеге во время код-ревью понравится, что вы написали функцию за O(N^2), когда это можно было сделать за O(N) либо O(logN).

Кстати, как раз в моем приватном ТГ канале вышел разбор всех 3-х этапов собеседований в Т-Банк! Там я вам конечно в наушник ничего не надиктую, но зато помогу самим подготовиться к собеседованиям и выйти на оффер!

Вы получите 3 видео (секции по JavaScript, алгоритмам и архитектуре) с записями моих собеседований в Т-Банк на ЗП 3000$. А также 5 видео-разборов live-coding задач на JavaScript и алгоритмы, которые мне давали в Т-Банк. Забирай все это в моем приватном ТГ канале 😉👇

@easy_jobinterivew_frontend_bot

*⚛️ *Допущения алгоритма Reconciliation в React

В продолжение к посту как работает React и его алгоритм Reconciliation хочется рассказать про допущения этого алгоритма. Допущения алгоритма Reconciliation - это те условия, которые нам как разработчикам необходимо выполнять, чтобы React рендерил компоненты оптимизировано и без пролагивания UI.

Для начала давайте поймем, какая сложность алгоритма сравнения деревьев (Virtual DOM) у React? Алгоритм React это делает за O(N), т.е. сложность линейная. В то время как браузерное API сравнивает DOM-деревья за O(N^3).

И чтобы React продолжал выполнять свою работу за O(N), необходимо знать следующее.

*1️⃣ изменился тип узла ==> происходит создание нового дерева.*
Допустим, у нас было такое дерево,

```

Users

```

а после обновления стало таким.

```

Users

```

Как мы видим, тег main изменился на section. При этом контент внутри этого элемента остался без изменений. Но React удалит и заново создаст все узлы, которые начинаются с main и идут глубже, так как у узла изменился type. Был type: 'main', а стал type: 'section'.

2️⃣ изменился key узла ==> происходит создание нового дерева.

key - полезный инструмент в React. Он позволяет оставлять нетронутыми конкретные узлы между рендерами. Вы точно использовали key при работе со списками.

```

```

Даже если из списка удалить какой-нибудь элемент, то остальные останутся нетронутыми. React сверит их ключи до и после изменения. И если ключи равны, то элемент не будет создан заново.

Более наглядный пример. В коде ниже у компоненты Content произойдет размонтирование и после монтирование. Так как при изменении checked изменился key.

```

```

Но при этом, если бы key остался одинаковым между рендерами, то никакого размонтирования не произошло. Просто случилось бы обновление компонента Content.

*3️⃣ *изменился атрибут узла ==> обновляется только измененный атрибут, создание нового дерева не происходит

Допустим у нас есть следующий JSX.

```

```

Как мы видим, у div меняется только атрибут data-testid в зависимости от состояния isVisible. В таком случае создание нового дерева и размонтирование всех дочерних узлов div НЕ произойдет. Потому что изменение атрибута не вызывает создание нового дерева.

P.S. Ставь ?, если было полезно! Больше про advanced-темы в React можно найти в закрепленном посте.