Короткая заметка про встроенную в chromium инструмент для трейсинга загрузки страниц. Это достаточно низкоуровневый инструмент (навигация через wasd и использование внутренних терминов chromium), который может пригодится. когда вам не достаточно мощности стандартных дев-тулзов хромиума. Например, tracing позволяет найти медленные css-селекторы и по профилировать влияние работы внутренних подсистем (например, проверка орфографии).
Вряд ли много кому придется это использовать, но знать о такой возможности - полезно
Статья про вред родмапов в agile разработке. На мой взгляд, статья немножко opinionated, но тем не менее хорошо подсвечивает вред, который могут принести родмапы
Типичные проблемы от родмапов:
- Топ-менеджмент придумывает родмапы без участия разработки. В итоге команды не понимают, почему родмап именно такой, как его достичь и хватит ли у них сил (и что делать, если им кажется что не хватит). Вполне вероятно, что такой родмап не будет выполнен и в итоге пострадают все участники - и топ-менеджмент и разработка
- Родмапы фокусируются на фичах, а не на результате. Как правило, родмапы составляются из фичей. Фичи, конечно, нацелены на какой-то результат. Но команды, имея фичи в родмапе, не имеют возможности даже подумать о том, а как еще можно достичь аналогичный результат.
- В родмапах нет места для совместной работы.
Короткая статья от shopify про борьбу с zoom-созвонами.
Один их посылов статьи можно обозначить с помощью известной шутки: "Розы гибнут на газонах, пацаны - на зум созвонах".
После перехода на повсеместную удаленку количество zoom созвонов значительно увеличилось. При переходе на удаленку все ожидали, что будет легко сосредоточится, а люди научатся в асинхронное общение. Но вместо этого все поставили себе разные плагины чтобы создавать встречи в календаре в 1 клик.
Как следствие, возник эффект усталости от созвонов. Сотрудники не могут сосредоточится и продуктивно поработать, т.к. у них весь день созвоны.
Некоторые компании принимают это во внимание и вводят дни без созвонов.
В статье рассказывается про опыт Shopify. Они пошли немного дальше:
- Среда - день без созвонов для всей компании
- Каждую среду (если я правильно понял) все повторяющиеся митинги с более чем двумя людьми удаляются. Это действие они название "очисткой календаря".
- Также они мотивируют сотрудников отказываться от участия в созвонах с большим количеством людей и выходить из больших чат-групп.
- Все созвоны с более чем 50 участниками можно проводить только в течение 6 часов в четверг.
Звучит, на самом деле, круто. Очистка календаря позволяет не захломлять календарь и мозг встречами по инерации. А окно в четверг для больших встреч мотивирует оценивать полезность встреч как для организаторов, так и для участников и отказаться от ненужных созвонов.
Статья про миграцию Shopigy на React Native. Пока одни компании решают, что React Native - это тупик, друие вот наоборот ускоряют свой переход на RN. В статье описан интересный и живой опыт миграции большой кодовой базы с одной технологии на другую.
Shopify начал переход на React Native в 2020-м году. Миграция большого приложения - это достаточно долгий процесс и он сопряжен с определенными рисками. Самый большой риск это то, что приходится поддерживать решение на трех архитектурах: android, ios, RN. Как следствие, нужно иметь крутых разработчиков для всех архитектур одновременно.
Чтобы минимизировать этот риск, shopify решили мигрировать кодовую базу итеративно. Т.е. стараться делать так, чтобы весь логический блок переписывался сразу на RN, чтобы поддерживать его только в RN.
Shopify также подумали об обучении сотрудников и организовал программу обучения RN, состояющую из 5 пунктов:
- JS и TS
- React
- React Native
- React Native в Shopify
- Продвинутые техники
Т.к. приложение большое, то миграция займет много времени. Поэтому необходимо было продумать, что же переписывать в первую очередь. Для приоритезации фичей и экранов они использовали фреймворк для приоритезации RICE. ИМХО, немного странное решение, но тем оно и интересно :)
Какие преимущества уже заметны от перехода на RN:
- Уменьшена разница в реализации между ios и anroid
- Т.к. раньше нужно было иметь для реализации каждой фичи минимум двух разработчиков (android и ios), то после перехода на RN они оба становились RN-разработчиками и теперь можно делать в 2 раза больше фичей единовременно.
- Веб разработчики могут делать фичи в мобилке.
- Код стал проще
Также в статье рассказано о некоторых проблемах, с которыми столкнулись разработчики при переезде с нативных платформ на RN.
В общем, shopify активно переезжает на RN чтобы ускорить свой TTM и им нравится.
Библиотека с react-компонентами для интерактивной математики. Библиотека позволяет строить всякие разные интерактивные графики. Возможно вам это не понадобится - но рекомендую поиграться с их примерами. Выглядит завораживающе.
Structura.js - аналог immer, но в 22 раза быстрее (по бенчмаркам авторов) и только в окружениях, поддерживающих ES6.
Structura.js позволяет работать с имутабельными стейтами, используя при этом обычный мутирующий синтаксис.
Structura старается быть заменителем immer, поэтому используется аналогичный API для создания новых стейтов
```
const originalState = {
innerState: { test: true },
prop: false
}
const newState = produce(originalState, (draft) = {
delete draft.prop;
draft.newProp = true;
})
console.assert(originalState !== newState, "это разные состояния");
console.assert(originalState.innerState === newState.innerState, "innerState является пошаренным объектом для обоих стейтов");
```
В результате данного сниппета мы получим 2 разных объекта - `newState` и `originalState`, но которые при этом используют общее вложенное поле `innerState`. Т.к. мы знаем что `innerState` остался неизменным, то оба стейта просто ссылаются на один и тот же `innerState`. Эта фича называется structural sharing.
В статье описывается, как с помощью Copilot писать юнит-тесты. Пример достаточно простой, но тем не менее выглядит впечатляюще.
Автор покрывает тестами простую чистую функцию. Автор описывает название сценария, а сам код теста описывает Copilot. Copilot понимает, что от него хотят и генерирует корректный jest-код. При этом автор сначала описал тесты с помощью coplilot, а только потом пошел делать реализацию.
Обзор фреймворка Solid с точки зрения React-разработчика.
Статья очень короткая, но показывает основную разницу между фреймворками:
- Solid построен вокруг реактивных сигналов. Solid запоминает как сигналы друг с другом связаны и строит на этом разные оптимизации. Например, может обновить конкретный DOM-элемент при изменении определенного сигнала
- в Solid JSX работает по-другому. Поэтому, например, для условий и циклов нужно использовать отдельные элементы
- Деструктурировать пропсы в начале компонента - антипаттерн (т.к. Solid отслеживает использование пропсов)
Также разобран аналог Next.js - Solid Start.
В общем, как обзор Solid.js - достаточно неплохая статья - коротко, объяснены ключевые моменты, даны ссылки для последующего чтения.
Достаточно хорошая статья, разбирающая как и зачем использовать ref-колбеки для элементов в React/
В статье рассказываются основные юзкейсы, нюансы основы работы React с ref-колбеками и как эти нюансы можно использовать.
Разобранные юзкейсы:
- Вызов метода DOM-элемента при его вставке в DOM-дерево. Т.к. ref-колбек вызывается при вставке элемента в DOM, то этот колбек можно использовать для DOM-сайдэффектов типа "didMount". Например, ставить фокус или вызывать скрол.
- Получать данные о DOM-элементе
- Объяснено, почему, если хочется сохранить ref на элемент для дальнейшего доступа, лучше использовать `useState`, а не `useRef`. Тлдр: react не умеет следить за изменением ref, а значит использовать то, что хранится в ref в рендере - концептуально неправильно и небезопасно. В статье про это написано несколько экранов текста, я лишь очень утрировал
- Общий доступ к DOM-элементу
Если вам интересен React, рекомендую к прочтению. Лично я как-то не задумывался, что можно сразу в ref-колбеке делать нужную мне логику.
Методология как конструктор: инструкция по сборке / Филипп Дельгядо
Достаточно старый, но популярный в определенных кругах, доклад от Филиппа Дельгядо про процессы разработки.
Основной посыл доклада - нельзя просто так взять какой-то готовый рецепт (скрам, канбан) и просто применить его к команде и жить с этим годами. Команда меняется, бизнес меняется, контекст меняется. При этом все команды и контексты - разные. Поэтому в каждом отдельно случае нужно уметь проектировать особые процессы, которые затем нужно уметь адаптировать под изменения, которые неизбежно происходят.
Статья от команды разработки приложения Standard Notes про их борьбу с мультиплатформенностью с помощью React Native. Standard Notes - это приложение для ведения заметок. Достаточно хорошее даже.
У них изначально был небольшая команда разработки и три платформы - веб, который контейнизировался в электрон для публикации десктоп приложения, android и ios. В начале разработки, в 2016 году, приложения дла мобилок писали нативные. Но тут встала проблема поддержки трех платформ - сложно поддерживать паритет по фичам (это когда на всех платформах есть одинаковый набор функциональности) и работоспособности, когда у вас 3 разные кодовые базы. В 2017 году они переехали на React Native и это позволило иметь 2 кодовые базы весто трех. Изначально их все устраивало, но дальнейшая практика показала, что достичь паритета по фичам для веба и мобилки оказалось сложно.
В итоге, они приняли решение уйти от React Native в пользу веба для всех платформ. Но при этом приложения для мобилок все равно используют React Native - в нем открывается webview с вебом. При этом React Native предоставляет для веб-приложения фичи нативных платформ, а общение между вебом и React Native-оберткой устроено через PostMessage.
Статья хороша тем, что показывает цену кросс-платформенной разработки с соблюдением паритета функциональности, а также рассказывает реальную историю и реальные проблемы, с которыми столкнулась команда разработки при разработке на React Native. Также достаточно интересно, что в итоге они, пока, решили оставить React Native для доступа к нативным API.
Мо небольшое имхо, если хочется иметь рпиложение на нескольких платформах то либо:
- Смириться с тем что это будет дорого
- Отказаться от паритета функциональности
- Использовать кроссплатформенные технологии
Продолжаем следить за Bun, у которого вышел релиз 0.4
В этом релизе:
- bunx - аналог npx но в 100 раз быстрее
- флаг --bun позволяющий интерпретировать все вызовы nodejs через shebang (`#! /usr/bin/env node`) как вызовы Bun. Это делается через создание временного алиаса node = bun
- Добавлены хуки в инструментарий для тестирования
Статья от автора Reatom про Reatom. Это первая обучающая статья в серии статей про Reatom.
Статья очень короткая, но показывает основы Reatom:
- вокруг чего основная идея (сюрпрайз, атомы и реактивность)
- основное API для создания и изменения атомов
В комментариях засветились свидетели mobx и nin-jin (автор $mol)
Надеемся на продолжение серии статей. Контента в текущей, объективно, мало, чтобы понять что за зверь этот Reatom и стоит ли начать его использовать.
Статья на хабре от компании Ozon про их путь от небольшой команды разработки до огромной компании со своей командой платформы.
Статья очень большая и, похоже, является текстовой расшифровой доклада.
Что описано в статье:
Внедрение конвенций и стандартов разработки. Это общие договоренности, о том как следует писать микросервисы - какие логи и куда писать, как обмениваться друг с другом данными. Также конвенции есть и для конкретных языков программирования.
Достаточно интересно, что как стандарт для общения в ozon используют GraphQL и grpc. И т.к. это является стандартом в компании, то появляется простор для разного рода оптимизаций. Например, в некоторых языах что-то полезно вшито прямо в бинарник.
Также, платформа предоставляет командам удобный API для создания сервисов и БД. Вы хотите запустить новый микросервис? Выбери язык, потыкайся в настройки и платформа сгенерирует тебе кучу базового кода. Нужна постгря? Нажми еще пару кнопок и будет у тебя свой инстанс БД.
Также много внимания уделено телеметрии - метрикам и трейсингу. Платформа помогает командам получать различные средства мониторинга высокого качества, при этом не уделяя настройке этого всего много времени.
Еще в статье много внимания уделено своей реализации service mesh.
В общем, очень объемная и достаточно неплохая статья про роль платформенной команды в большой компании. Есть много вариантов, что может делать платформенная команда и как помогать разработке. И вот Ozon поделился своим опытом использования паттерна "Платформенная Команда".
GlitchTip вместо Sentry. Как мы бесплатно настроили мониторинг ошибок
В продолжение предыдущей ссылки: статья на хабре, про то как и почему компания, DevOps из компании Constanta решили взять GlitchTip вместо Sentry.
Статья очень короткая и в целом сводится к следующему:
- GlitchTip не хуже Sentry
- GlitchTip потребляет меньше ресурсрв
- GlitchTip проще деплоить и сопровождать
К сожалению подробностей реального использования не рассказывается. А было бы интересно про это почитать (насколько легко исследовать ошибки, какую держит нагрузку и тд и тп)
GlitchTip - опенсорсный аналог Sentry. Вплоть до совметимости с API sentry, что позволяет легко перейти с sentry на glitchtip.
В чем основная фича и Sentry и GlitchTip: они предоставляют из себя системы трекинга ошибок приложения. Т.е. вы подключаете систему через SDK к приложению, а затем можете отправлять туда ошибки. Система же умеет:
- Показывать конкретную строчку кода в репозитории, которое привело к ошибке, а также отображать полный стак-трейс
- Показывать действия, которые перед этим делал пользователь. Для веб-приложений обычно собирается инфа о сетевых запросах и действиях пользователя. Также можно настроить кастомные "хлебные крошки", например, выводить исполненные redux события
- Показывать, в каком релизе или коммите впервые появилась данная ошибка
Короче, если использовать с умом, то такие системы очень мощные. Хорошо, что появляются опен-сорсные альтернативы.
⚛️ Applying Design Patterns in React: Strategy Pattern
Статья про применение шаблонов проектирования в React.
Это хорошая обучающая статья, описывающая, как проблема Shotgun Surgery (хирургия дробовиком?) решается с помощью паттерна Стратегия.
Что такое Shothub Surgery - это когда 1 фича "расплескивается" на кучу файлов, и когда приходит время что-то в ней изменить, необходимо сделать изменения в куче файлов разом.
В статье есть конкретный пример - это карточка цены на продукт (base, pro, premium уровни), в которой ценообразование располагается везде разом. Это нарушает принипы S и O из SOLID.
Чтобы решить эту проблему, предлагается использовать паттерн Стратегия. В данном случае мы можем инкапсулировать всю логику, связанную с ценообразованием и тарифами в отдельный класс и его уже предоставлять компонентам. Тогда компоненты будут отвязаны от тарифов, а все изменения по тарифам будут теперь делаться только в реализации Стратегии.
Если нам нужна будет новая стратегия ценообразования и тарифов, нам не потребуется править никакой существующий код, достаточно будет создать новую имплементацию Стратегии.
В общем, хорошая обучающая статья про хорошие практики.
Часто мы обсуждаем скорость и качество как противоположное. Типа надо выбрать или качество или скорость, но не оба вместе.
Однако на самом деле выбор стоит между быстро и качественно и некачественно. Скорость генерирует качество, а не ухудшает его.
Как это работает?
Статья начинается с притчи про мастера гончарного дела. Он разделил учеников на 2 группы: первая группа оценивается по тому, сколько вещей они произведут, а вторая группа оценивается по качеству того, что они произведут. Когда пришло время оценить работу групп, то оказалась, что первая группа сделала 50 первоклассных горшков, 40 хороших горшков и так далее. Вторая же группа сделала всего 1 первоклассный горшок.
Пока вторая группа обдумывала и теоретизировала как же сделать идеальный горшок, первая группа быстро производила горшки и училась на своих ошибках.
Притча немного странная, но как пример - очень хорошая. Она достаточно точно отражает процесс создания чего либо, в том числе ПО. Идти быстро маленькими инкрементами и собирать обратную связь получается качественнее, чем быть осторожным, продумывать все заранее и делать сразу идеальный продукт.
В целом в индустрии есть вера, что чем лучше мы все продумаем, тем качественее будет продукт, тем больше продукт понравится пользователям. Однако, все забывают, что качество - это соответствие потребностям. Пока ты не выпустишь что-то и не отдашь это пользователям и не получишь от них фидбек - ты не узнаешь их истинные потребности, а значит, просто напросто не имеешь возможности сделать по-настоящему качественный продукт.
При этом надо отличать "делать быстро всякую ерунду" и "делать быстро маленькими шагами". В фразе "Speed generates quality" cкорость - это прежде всего про маленькие итерации и процесс обучения. А процесс обучения ведет к качеству.
Как изменить мнение человека по какому-то вопросу? Часто случается, что люди расходятся во мнениях и они пытаются изменить мнение опонента по вопросу. Однако тактика переубеждения в споре работает далеко не всегда - как правило все остаются на своём.
Статья помогает разобраться, почему так, и как по-другому подходить к изменению мнения человека по какому-то вопросу.
Статья начинается с ссылки на интересное исследование. В нем говорится, что изменить что-то, во что человек верит и что является частью самоидентификации человека - очень сложно. Это ведет к тому, что человек ставит персональные убеждения превыше совместного поиска истины.
Но это исследование было в оффлайне - где люди видят мимику друг друга, жесты, интонации. В онлайне же все гораздо хуже и несогласие с мнением чаще бывает распознано как атака на идентичность.
Немного офтопа. Вы, наверное, уже сталкивались с таким феноменом, когда общаясь с человеком через чат считаешь его полным чудаком на букву М, и он также считает в ответ. А когда все таки встретишься с ним в оффлайне, то как-то так выходит что в принципе хороший чел, адекватный, просто вы были не на одной волне. Поэтому я считаю важным офлайн сборы команды хотя бы раз в полгода. Люди есть люди и нам нужно офлайн общение для понимания друг друга.
Вернемся к статье. Статья объясняет что у людей, в следствие их различного бекграунда, могут сильно различаться базовые ценности. Но, в какой бы культуре и контексте человек не вырос, есть 2 ценности, разделяемые всеми:
- Приченение вреда без причины - это плохо
- Справедливость - это хорошо
Также стоит иметь в виду эффект бумеранга. Это когда вы высказываете несогласие с опонентом, но другие люди начинают симпотизировать ему больше. Т.е. высказывания несогласие, даже аргументированное, можно сделать свою позицию более шаткой.
Как же все таки подходить к коммуникациям когда мнения расходятся?
1. Не разделяйтесь на "мы" и "они". Это провоцирует разделение, в том числе психологическое. Будьте в одном круге коммуникации чтобы слышать мнения друг друга.
2. Не принимайте возражения персонально. Помните, что возражения к вашему мнения - это не атака лично на вас.
3. Слушайте. Исследования говорят, что слушание более эффективно чем разговор в плане изменения мнения другого человека. Внимательное слушание с задаванием хороших вопросов работает намного эффективнее, чем разговор. Спор же, согласно тем же исследованиям, особо не влияет на мнение других людей по вопросу.
В общем, если вы столкнулись с проблемой недопонимания, то ни в коем случае не разделяйтесь на "мы" и "они" и активно слушайте друг друга. Это поможет вам быстрее обрести общее понимание вопроса.
Вышел Bun 0.3.0.
Пока что Bun достаточно быстро развивается и приносит новые интересные фичи.
В релизе 0.3.0 было уделено много внимания перформансу и потреблению памяти. Теперь Bun под нагрузкой кушает в разы меньше памяти (30МБ против 146МБ в 0.2.2). Также, по их собственным бенчмаркам, аналогичный код в Node.js и Deno кушает 71 и 91 МБ соответственно. Предлагаю и дальше относится к бенчмаркам Bun как к маркетинговой истории, но отмечаю, что работу по уменьшению потребления памяти они все же проделали.
Также в релизе:
- улучшено форматирование console.log
- енкодирование текста ускорено в 3 раза
- добавлены еще фичи для совместимости с node.js
- Bun автоматически устанавливает пакет из npm при вызове import. Пакеты устанавливаются в глобальный кеш, пост инсталл скрипты не запускаются
- Появился FileSystemRouter. Т.е. теперь можно описывать роутинг к хендлерам на уровне путей в файловой системы. Как, например, в next.js. Собственно там и есть такой параметр `style: "nextjs"`
- Также появилась возможность считывать ввод консоли через async итератор. Выглядит это весьма интересно
```
for await (const line of console) {
console.log("Received:", line);
}
```
Статья про самые распространенные проблемы при использовании useState в react. В статье каждой проблеме приводится подробное описание в структуре:
- Пример кода
- Почему это проблема
- Как исправить
Сами проблемы:
- Лишнее или избыточное состояние (Redundant State)
- Дублирующее состояние (Duplicate State)
- Обновление состояния через useEffect (Updating State Via useEffect)
- Подписка на изменения состояния через useEffect (Listening To State Changes Via useEffect)
- Конфликтующие состояния (Contradicting State)
- Состояние с глубокой вложенностью (Deeply Nested State)
React Bricks: React CMS with Visual editing for Next.js, Gatsby, Remix
React Bricks - CMS для Next.js, Gatsby, Remix.
Какую проблему решает React Bricks? Допустим, у вас есть создатели контента, которые не являются разработчиками. Они делают, например, лендинги или статьи в блог. Сейчас вам нужно решать, какой удобный инструмент им дать и как с ним интегрироваться. Вы, скорее всего, увеличите технологический стек, возможно завендорлочитесь на каокй-то инструмент, и не будете иметь достаточно контроля над ним.
React Bricks предоставляет подключаемое в Next.js, Gatsby, Remix, решение, которое позволяет описывать такой контент (статьи, лендинги) неразработчикам. Это готовая CMS, в которой уже есть базовые блоки для контента (кнопки, ссылки, тексты, картинки). Но также вы, как разработчик, можете добавлять туда кастомные блоки, реализовав их React.
В итоге вы получаете CMS, которую полностью контролируете и можете легко расширять на текущем технологическом стеке.
Tao of Node - Design, Architecture & Best Practices | Alex Kondov - Software Engineer
Тао of Node - opinionated список бест практиксов для разработы сервисов на node.js.
Большинство практик действительно несут объективную пользу. Остальные являются скорее выбором автора среди альтернатив (поэтому список и opinionated).
Некоторые практики описаны достаточно подробно (с примерами кода), некоторые слишком утрировано. В целом получается скорее обзор на практики.
Практики разделены на 4 группы.
Общие. Например, валидируйте запросы, разделяйте приложение на слои, обрабатывайте ошибки. Они практически все хороши и являются бест практисами в разработке в целом, даже не привязываясь к nodejs)
Далее идут инструменты. Тут советы уже весьма opinionated, но в целом все равно хороши
Затем идет блок про тестирование, который, достаточно короткий, но на мой взгляд, содержит очень правильные рекомендации по тестированию nodejs - вкладываться в test coverage, тестировать интеграционными тестами, бизнес-логику покрывать юнит-тестами.
Заключительный блок про перформанс. Он достаточно короткий, но сводится к тому, что перформансом надо заниматься тогда, когда увидел где и от чего он страдает.
Могу рекомендовать к прочтению тем, кто окунается в nodejs разработку. Опытные разрабы также могут просмотреть список, но большую часть они скорее всего уже знают
Cypress V12 Is A Big Deal | Better world by better software
Вышел 12 релиз Cypress. В нем применили CQS и разделили команды на 2 вида - query и command. Query только лишь запрашивают данные, command - что-то делает.
Это позволяет Cypress в случае падения асерта делать ретрай начиная от последней _команды_. Собственно статья подробно рассказывает, как работают подобные ретраи.
Очередной пост в блоге Dr. Axel Rauschmayer. На тот раз про новый пропозал - хелперы для работы с итераторами.
Как обычно, статья описывает все тонкости объявленной темы. Начинается все с объяснения как же работают итераторы и генераторы, что у них происходит с прототипами
А затем автор переходит к новому API.
`take(n)` знаком всем, кто погружался в ФП - метод сгенерирует новый итератор, который отдаст только N элементов от исходного итератора. Что-то типа `slice`, но с учетом основного смысла итераторов
Из стандартных методов массива были перенесены: filter, map, forEach, reduce, flatMap, some, every, find
Также добавлены методы `from` и `toArray`, что позволяет прыгать между представления iterator = array = iterator.
Если вы работаете с генераторами или итераторами - рекомендую прочесть подробно.
Вышел SevelteKit 1.0. Я из новости не до конца понял, что там нового вышло, но то, что они зарелизили первую стабильную версию - уже достойно внимания.
Весь блог-пост посвящен краткому знакомству со SvelteKit - что это такое, для кого, для чего, какие основные фичи есть, ссылка на гайд по миграции из бетки в 1.0.0
GitHub - tjkandala/baahu: 🐘 (fast) state machine-based UI framework
UI Framework основанный на стейт машинах. Про то, что UI хорошо проектируется через стейт машины не говорил только ленивый. Но готовых инструментов не так много. `baahu` исправляет это, предоставляя API, в котором state machine и компонент очень тесно переплетены.
Выглядит интересно
Пост про то, как реализован внутри react query, в серии постов про react query
Хорошая короткая статья с визуализацией. Рассказывается про работу кеша и как компонент получает данные
