Серия «Пятничное чтиво»

Проблемы React Context

Проблемы React Context Кросспостинг, Pikabu Publish Bot, React, Frontend, Текст, Программирование, IT

Использование контекста реакта и хуков, упрощает управление состоянием приложения. В небольших проектах уж и вовсе позволяет отказаться от использования менеджеров состояний. Но у него есть ряд проблем, о которых необходимо знать.

1️⃣ Дизайн по умолчанию, не совсем безопасен.

1. Логика хранения стейта и его изменения разбросана между контекстом и использующими его компонентами
2. Значение value контекста необходимо мемоизировать с помощью useMemo
3. Если компонент, не нашёл контекст в родительских узлах — он будет молча использовать значения по-умолчанию. Мы не увидим никаких предупреждений или ошибок

Эти проблемы и их решения рассматривается в статье React: How I learned to create optimized contexts

✅ Вместо использования контекста напрямую, нужно:

- Указать null в качестве значения по-умолчанию для контекста
- Реализовать useSafeContext — кастомный хук, который будет проверять, что значение не null
- Реализовать SafeContext — компонент, который содержит логику инициализации значения реакт контекста

2️⃣ Отсутствие атомарных обновлений — компоненты или хуки, которые используют контекст, перерендеривается каждый раз, когда контекст изменяет состояние. Даже если ваш компонент использует лишь одной свойство из контекста, которое никогда не изменяется — компонент будет перерендериваться при изменении любого другого свойства в контексте.

✅ Как решить проблему?

- Не класть всё в один большой контекст, а разбить его на несколько маленьких
- Использовать библиотеку для управления состоянием, например, zustand
- Минимизировать использование контекста. Например, можно использовать контекст в родительском компоненте, а дочерним передать нужные значения через пропсы.

Проблемы и решения описаны в статье The Problem with React's Context API (тут перевод на русский).


https://t.me/cherkashindev/130

Показать полностью

Архитектура фронтенда на основе вертикальных слайсов

Архитектура фронтенда на основе вертикальных слайсов Кросспостинг, Pikabu Publish Bot, Frontend, Архитектура, Текст, Архитектура по, Программирование, Длиннопост

Сегодня порекомендую статью о структуре фронтенд проектов на основе вертикальных слайсов.

Автор начинает рассказ с описания структур первых проектов, где использовался подход “Разделения по техническим слоям”, в котором мы группируем файлы по функциональности, а не по доменной области:

- api/services
- components
- stores
- constants
- и т.д.

и затем описывается, как этот подход всё ещё используется внутри “вертикальных слайсов”.

Разделение по техническим слоям

Плюсы подхода

- хорошо работает для маленьких проектов
- у слоев есть однонаправленный поток использования, и нельзя импортировать файлы из слоев, находящихся на уровне выше (например сторы могут использовать api, а страницы могут использовать базовые компоненты, но не наоборот).

Проблемы подхода

- Даже для небольших продуктовых фичей приходится править код по всему проекту, так как он раскидан по разным папкам
- Неявные связи в рамках конкретных слоев: бизнес компоненты (ProductCard, UserProfile) смешиваются c UI компонентами (Link, Button) в components, то же самое касается бизнес логики

«Vertical sliced» подход

Подход подразумевает, что архитектура строится не вокруг технических слоев, а поверх конкретных слайсов проекта.

По сути, мы берём структуру “разделения по техническим слоям” и делаем разрез по фичам. То есть, создаём папку для каждой фичи, внутри которой все файлы относятся только к этой фиче и “разделены по техническим слоям”.

ℹ️ Описание папок

- shared - тут хранятся всё, что можно переиспользовать и не зависит от определённой бизнес фичи. Например в shared/components будут лежать, обычные кнопки, радио кнопки и прочее
- domain - базовый UI для бизнес-сущностей (домена) проекта, например карточка товара. Простая аналогия (но не совсем правильная) - в домене можно хранить все то, что хранится в базе данных на бекенде.
- features - самодостаточные компоненты — большие бизнес сущности приложения, например корзина. Для реализации фичи, скорее всего будет использоваться несколько компонентов из доменной области.
- pages - страницы приложения.

✅ Плюсы подхода

- Когда необходимо внести изменения в фичу — все изменения происходят внутри одного слайса.
- На выходе получаем высокое зацепление (high cohesion) внутри слайса и низкую связанность (low coupling) между разными слайсами
- Сохраняется правило однонапревленного использвания: pages ⇒ features ⇒ domain ⇒ shared
- Фичи не могут напрямую использовать друг друга
- На самом нижнем уровне используется “разделение по техническим слоям”

Чтобы обеспечить однонаправленный поток использования можно взять eslint c плагином import/no-restricted-paths.

https://t.me/cherkashindev/128

Показать полностью

Неделя после пуска или Cooldown week

Как часто после очередного спринта вы чувствуете, что

- в одном месте не успели отрефакторить
- в другом месте не успели дописать документацию
- где-то осталось пару багов, которые было бы неплохо пофиксить
- нужно рассказать команде о важных (или не очень) архитектурных изменениях или базовых компонентах, которые были добавлены

Кроме того, вам в любом случае нужно время между релизами, чтобы

- подвести итог прошлого релиза
- запланировать следующий

В этом случае вам подойдёт Cooldown Week подход (Неделя после пуска), который поможет вам закрыть все недоделки (или, по крайней мере, самые важные из них), прежде чем погрузиться с головой в новый спринт.

“Неделя после пуска” — это не какой-то набор обязательных активностей, вы можете применять её в своей компании под ваши собственные нужды.

Такой подход используется в Basecamp и в Бюро Горбунова

- Basecamp — How we work — Cooldown
- Бюро Горбунова — Как оценивать доработки после запуска?

https://t.me/cherkashindev/104

Показать полностью

Backend-Driven UI

Сегодня посоветую доклад с HolyJS — Виталий Полещук, Стёпа Михайлюк — Server-driven UI в вебе. Не пиши, а описывай свой фронтeнд

Backend-Driven UI Кросспостинг, Pikabu Publish Bot, Frontend, Архитектура, Текст, Backend, React, Программирование, Рекомендации

https://t.me/cherkashindev/102


Парни в докладе рассказывают, как можно не заниматься формошлёпством, точнее как его упростить, чтобы создавать новые формы можно было проще и быстрее.

Backend Driven UI представляет собой подход, в котором бэкенд говорит клиенту, как должен выглядеть интерфейс. В случае с формами, например, может передаваться массив элементов, где у каждого элемента есть тип:

- header
- select
- checkbox
- …

клиент проходится по этому массиву и рендерит соответствующий UI компонент. Таким образом реализация компонентов находится на фронте, а их расположение и взаимодействие на бэке.

👍 Основные преимущества Backend Driven UI

- Возможность делегировать создание форм бэкендерам или аналитикам
- Мгновенные релизы, достаточно обновить данные на сервере для изменения формы сразу на всех устройствах

Ещё по теме:
- Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом

#fridayreading #frontend #architecture

Показать полностью

Не трогайте разработчиков. Отстаньте. Просто не беспокойте

Не трогайте разработчиков. Отстаньте. Просто не беспокойте Кросспостинг, Pikabu Publish Bot, Текст, Программирование, Командная работа

Статья описывает настройку процессов таким образом, чтобы по минимуму отвлекать разработчиков. Для этого назначается дежурный, который отдувается за всех. Например, у вас есть команда поддержки, которая постоянно дергает разработчиков, когда не может справиться самостоятельно. Можно назначить дежурного — именно этого человека и будут дергать, а он будет стараться решить проблему самостоятельно, и дергать команду только в крайнем случае, таким образом остальные могут быть сконцентрированы на своих задачах.

Возможные обязанности дежурного:
- Защищать команду, чтобы её никто не отвлекал лишними вопросам или созвонами
- Менеджер обращается к дежурному, заказчики также ходят с вопросами к дежурному
- Следить за метриками
- Писать постмортемы
- Проверять написанную документацию за разработчиками
- Следить, чтобы не было повторяющейся работы. Если вам часто нужно делать одно и тоже, то дежурный это всё запишет и составит задачи на автоматизацию
- Выкатывать релизы

Плюсы:
- Дежурный погружается в специфику работы команды и продукт более глубоко
- Снижается нагрузка на команду и она может спокойно заниматься своими задачами
- Дежурства помогают навести порядок там, куда обычно не доходят руки. Зачастую дежурный делает то, что должен разработчик, но ему всегда некогда.
- Смена деятельности

Особенности процесса
- Кажется что производительность команды снизится, но на самом деле этого не должно произойти — ведь остальные будут сосредоточены на решении задач и будут более продуктивны
- Дежурят только желающие, никого не заставляют
- Для обучения можно назначать двух дежурных, один — опытный, второй — новичок. Опытный ничего не делает руками, кроме ЧП ситуаций, так происходит обучение новичка.
- Может быть несколько дежурных: кто-то отвечает за релизы, кто-то за поддержку
- У дежурного не должно быть релизных задач, если у него появляется свободное время:
- Он дописывает документацию
- Работает над техническим долгом
- Автоматизирует бизнес процессы
- Фиксит баги

Как начать вводить
- Выписать всё, что может отвлекать
- Начать автоматизировать то, что можно
- Создание метрик
- Релизы
- На релиз другой уменьшить количество продуктовых задач и заняться автоматизацией и внутренними инструментами, чтобы увеличить продуктивность команды в будущем
- Начать вводить дежурства с опытным наставником

https://habr.com/ru/company/gazprombank/blog/678000/


https://t.me/cherkashindev/88

Показать полностью

Пятничное чтиво — Getting Things Done

Я купил книгу Getting Things Done (GTD) около 3 лет назад и только в этом году у меня дошли руки, чтобы прочесть её. Вчера наткнулся на статью GTD за 15 минут: прагматическое руководство. Неплохо подходит, не только чтобы освежить всё это в памяти, но и как краткий экскурс в GTD. Поэтому рекомендую к прочтению.

Основные моменты:

- GTD - это методика организации и отслеживания задач и проектов
- Цель GTD — сделать так, чтобы человек полностью доверял бы системе сбора задач, идей и проектов
- Техника GTD основана на ведении списков:
- Входящие (Инбокс)
- Следующие действия
- Список ожидания
- Проекты
- Когда-нибудь/может быть
- Основная цель инбокса — разгрузить мозг. Просто записывайте все мысли, задачи, проекты, которые приходят вам в голову в инбокс.
- Инбокс необходимо обрабатывать регулярно.
- Определение следующего действия, которое должно быть физическим, видимым действием, приближающим проект к его цели — самое важное «правило» GTD.
- Если вы делегировали задачу другому человеку, если вы отправили email и ждёте ответа — внесите это в “Список Ожидания”
- Проект — это любая цель, для достижения которой нужно выполнить более одного действия
- Контексты действий — это «теги», которыми снабжают элементы в списках Следующие действия. Они представляют собой сведения о том, где может быть выполнено то или иное действие, или о том, что именно нужно для его выполнения.
- Еженедельный обзор — актуализация списков следующих действий и проектов. Что-то нужно перенести из списка Когда-нибудь/Может быть в список следующих действий, что-то необходимо удалить совсем, потому что это больше не актуально.

Показать полностью

Пятничное чтиво

Сегодня не чтиво, а скорее смотриво. Приближаются выходные, самое время для сериалов, но коротких, чтобы успеть досмотреть и не отвлекаться в течении рабочей недели.

Пару месяцев назад посмотрел сериал Выбывшая. Рекомендую посмотреть, чтобы понять, как начинаются стартапы, и на что приходится идти чтобы они не потонули. Правда в этом случае, основатели зашли слишком далеко. Фильм основан на реальных событиях.

#fridayreading

Пятничное чтиво

В статье "Как быть более продуктивным, не заставляя себя" есть следующая фраза

Есть группа людей, которые работают и получают от своей работы удовольствие. Давайте назовем этих людей *деятелями*. Под этим понятием мы не имеем в виду трудоголиков, которые не живут, а лишь работают целыми днями. У деятелей здоровый баланс работы и отдыха. Что же особенного есть у них, чего нет у тех, кто ненавидит свою работу?

В первую очередь, они по-другому относятся к работе.

Для них работа — это приятный цикл позитивной обратной связи. Деятели воспринимают работу как источник энергии и удовлетворения. С их точки зрения, работа позволяет им по-настоящему насладиться заслуженным отдыхом. Отдых делает их счастливее и мотивирует затем снова заняться работой.
Похоже именно работа позволяет мне по-настоящему насладиться отдыхом, в конце выходных обычно всегда появляется желание вернуться к работе.

А это на прошлой неделе я был в Нижнем Новгороде, а сейчас замотивированный уже работаю.


#fridayreading

Пятничное чтиво Отдых, Путешествия, Путешествие по России, Эффективность
Показать полностью 1
Отличная работа, все прочитано!