Только что закончился Аргументариум с ребятами из CSSSR. Обсудили сходства и отличия Reatom и Effector.


https://www.youtube.com/watch?v=Ble1JXIb_hE

Немного обсуждений в @effectorjs чате натолкнули меня на мысль изменить подход к описанию логики в effector+react.

Я стараюсь разделять представление и логику. Если взять в пример страницы, рядом с файлом компонента страницы лежал файл логики на эффекторе.
pages/counter/{index.tsx, model.ts}

В файле компонента я напрямую импортировал сторы и ивенты из модели и использовал в компонентах:

import * as React from ‘react’
import { useStore } from ‘effector-react’
import { $counter, incrementClicked, pageMounted } from ‘./model’

export const CounterPage = () => {
const counter = useStore($counter)
React.useEffect(() => { pageMounted() }, [])

// show counter and use events
}

И это работало весьма хорошо, тестировать просто (импортируем сторы в тест и setState(data)). Объявляем контрактом любые экспорты из model.ts и очень осторожно их изменяем.

View-слой (компонент) может независимо меняться от бизнес-логики, и логика может переписываться, если не меняется контракт(экспортируемые сущности).

Но если нужно маппить данные из стора по какому-то ключу или ещё какие операции со списками, то эта логика затаскивалась прям в компонент вместе с useStoreMap и useList. Это мне не очень нравится, ибо тестировать становится сложнее.

И я наткнулся на один антипаттерн, который использовал мой коллега в разработке. Но немного подумав, я понял, что это очень полезный паттерн разделения логики и представления.

Использовать хуки, для получения данных и ивентов из модели.
Я предлагаю из модели экспортировать реакт-хуки, вместо сущностей и ивентов. Этот подход имеет смысл в первую очередь для моделей страниц. Разделяемые сущности чаще всего не нужно отдельно заворачивать в хуки, так как часто хочется создавать computed от общих сторов.

Как это выглядит и что это дает: модель экспортирует хуки, которые возвращают наборы данных и ивенты. В этих хуках могут быть любые необходимые вычисления.

import { useCounter, useEvents } from ‘./model’

export const CounterPage = () => {
const counter = useCounter()
const { pageMounted, incrementClicked } = useEvents()

React.useEffect(() => { pageMounted() }, [])

// show counter and use events
}

Можно пойти дальше, и унести React.useEffect() внутрь useEvents, чтобы модель сама устанавливала нужные реакции. Но тут спорно и нужно обдумать. Возможно это нужно выделить в отдельный хук.

А теперь зачем это.
1. Семантика. Теперь, контракт выглядит как независимая сущность. Можем заменять STM как нам захочется, внутри хука может быть React.useReducer, или же Redux.useSelector, или же Effector.useStore. Все равно.
2. Сокрытие сложности. Всякие useStoreMap могут быть скрыты внутри хука, разработчику компонента теперь не нужно знать детали реализации модели, чтобы разработать компонент. Ведь теперь, чтобы рабоать независимо достаточно спроектировать контракт на хуках, описать типы и вернуть dummy-данные.
3. Тестирование. Тесты упрощаются, до мока конкретных хуков, а не сторов. Ведь теперь разработчик компонента, может спокойно написать тесты только на вью, не трогая при этом сторы модели. Логика моделей при этом может быть разработана действительно независимо.

Я пока не могу понять, имеет ли смысл разделять контракт и модель? pages/counter/{contract.ts, model.ts, index.tsx}
- contract — импорты из model завернутые в react-хуки
- model — чистая логика, без примесей хуков
- index — компонент, использующий контракт, без примесей STM

Как думаете?

Завтра в 18:00 начинается митап.

Приезжайте на м. Петроградская, зал Леонардо находится в пространстве Точка Кипения, которая возле клуба A2.

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

На всякий случай напоминаю почему Effector вообще появился и какие у него плюсы:

— децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи
— сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд
— сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения
— принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст
— возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты
— независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты
— предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch в эвентах, можно догадаться, что делает функция .watch у стора
— приложение строится из комбинации базовых элементов и возможности строить новые.
нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

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

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

1. Сбор требований к проекту (что входит в ближайший релиз и в следующий)
2. Макетирование (дизайнеры собирают карту взаимодействий)
3. Нарезка на библиотеку компонентов (на карте взаимодействий)
4. Определение зависимостей компонентов для всех экранов
5. Выделение паттернов дизайна (общая разметка, повторяющиеся блоки, тянущаяся верстка, адаптивная верстка)
6. Первая реализация библиотеки компонентов (карта состояний в storybook, поверхностное unit-тестирование)
7. Определение необходимых данных для каждого экрана
8. Определение требований к бекенду (методы API)
9. Первичная сборка 1-3 разных экранов по внешнему виду
10. Составление диаграммы процессов приложения (1-3 сценария по выбранным экранам)
11. Имплементация выбранных сценариев предметной области (на языке программирования)
12. Прототипирование экранов с привязкой к сценариям (моки API, graybox реализация без глубокой обработки ошибок)
13. Ретроспектива прототипа (анализ сценариев, анализ прототипов, анализ ошибок, анализ библиотеки компонентов и паттернов)
14. Составление карты сущностей и отношений
15. Составление карты ролей, политик и разрешений (RBAC / ABAC / ACL / ...)
16. Отображение карты взаимодействий на карту роутов (доступ, параметры, переходы)
17. Последовательная имплементация основных сущностей, роутов и прав доступа (тестирование)
18. Параллельная имплементация сценариев, сгруппированных по области ответственности (тестирование)
19. Ретроспектива релиза (список неудачных решений, список полностью решенных задач, список узких мест производительности и архитектуры, список удачных архитектурных решений, что можно улучшить перед реализацией следующего релиза)

Немного запоздалых новостей:

- На GitHub появилась коллекция JavaScript State Management Tools, в которой на первом месте Effector
- GitHub наконец-то одобрил добавление топика effector
- Я сделал шаблон Effector SSR, для быстрого старта разработки на TypeScript, React, Effector, Razzle, StyledComponents
- Часто вижу вопросы, как сделать debounce на Effector, и поэтому сделал библиотеку для этого 👀. Вообще, это больше в качестве примера написания библиотек для эффектора. В репозитории есть тесты на сам debounce, а также на корректность работы в fork.
- Я продолжаю писать генератор кода из Swagger/OpenAPI в ActixWeb

Оказалось, что я переношу несколько функций между проектами на Effector.

Не так давно я вынес debounce, throttle и reshape в отдельные пакеты. И вот, на работе родилась функция splitMap, а за ним затащил и spread.
Начав новый проект, я осознал, насколько мне стало лениво устанавливать и обновлять столько модулей.

Представляю сборник effector функций — Patronum.

github.com/sergeysova/patronum

Сейчас реализовано 5 функции помеченные 🧁: debounce, throttle, delay, condition, reshape. Всем желающим предлагаю закидывать в issues или PullRequests свои частоиспользуемые функции для effector.

Написал значит я тесты для patronum/delay. Хочу убедиться, что delay действительно корректный, мол на правильное время откладывает. Прогнал тесты на своем маке и запушил релиз.
И тут всё сломалось. https://github.com/sergeysova/patronum/runs/619547616?check_suite_focus=true

Тесты на ubuntu кричат:
expect(start.diff() > 100).toBe(true)
Время delay было меньше 100 миллисекунд.

Думал, я думал. Логгировал, логгировал, да не перевылоггировал.
Оказалось, что в некоторых случаях setTimeout срабатывает раньше указанного срока, хотя я всегда предполагал, что позже.

Как же тогда писать тесты красиво и удобно. Да так, чтобы время было корректным? Всего лишь нужно ввести так называемую проверку с порогом:
if (received < expected + threshold && received > expected - threshold)

И благо, jest позволяет добавить кастомные матчеры, чтобы такие проверки не дублировать в каждом тесте. Результат выглядит так:

expect(start.diff()).toBeCloseWithThreshold(100, 30)
— Жест, будь так добр, проверь, что полученное значение, находится в районе 100 миллисекунд, плюс/минус 30мс.

Реализацию можно поглядеть здесь:
https://github.com/sergeysova/patronum/commit/1aa43c48d81b54b8a85099d889e49604a0148ae7

Тем временем я расширил реализацию spread от @ZeroBias, написал тесты и добавил документацию.

https://github.com/sergeysova/patronum/tree/master/spread

spread(source, {
first: $targetFirst,
second: targetSecond,
third: targetThirdFx,
})

source({ first: "Hello", second: 123, third: true })

Если в source передан не объект, то падения в рантайме не будет.
Spread будет вызывать только те таргеты, для которых нашлись ключи. Например:

source({ first: "Hello" })
Здесь будет вызван только $targetFirst

Монтирую выпуск о моём опыте проработки продукта. Надеюсь сегодня будет готов и смогу выложить.

Первый выпуск подкаста «Сова говорит...» о проработке продукта.


https://podcast.sova.dev/episodes/1-0-product-development

Яндекс.Музыка опубликовали подкаст у себя


https://music.yandex.com/album/8469435

Как же меня сейчас разбомбило!

Итак, почему CRA это отвратительная штука:
- невозможно просто так подключить babel плагины
- заставляет юзать свой eslint-config-react-app, и env ESLINT_EXTEND
- вокруг него есть десятки расширителей rewired, customize-cra, craco…. и всё это работает не очень хорошо и имеет проблемы с обновлениями CRA
- он насильно исправляет tsconfig при запуске (WTF?)
- подключить postcss плагин уже проблема
- env переменные обязаны начинаться с REACT_APP_

Я думаю вы сможете накидать ещё десятки комментариев о проблемах с CRA. Но у меня весь процесс “БЫСТРОГО” старта выглядит так:
1. yarn create react-app my-app
2. исправить все косяки CRA (3-4 коммита)
3. писать немного код
4. понять, что нехватает расширения
5. пытаться жить с craco/rewired+customize-cra
6. получить какой-то баг при обновлении
7. сделать eject и исправить всё что нужно руками
8. переписать все конфиги

Итого, просто на мучения с CRA в сумме уходит несколько рабочих дней и 2000±500 строк изменений. Это неправильно. Такую систему невозможно называть УДОБНОЙ или УПРОЩАЮЩЕЙ. Оно даже для старта ничего не упрощает.

Зачем было навязывать свои еслинт плагины?
В чем проблема сделать как Razzle? Он решает одну задачу — конфигурирует webpack для SSR, и делает её очень хорошо. При этом позволяя легко кастомизировать и расширять любую часть, что бабель, что вебпак, что энвы, что еслинт.
Но авторы CRA это дичайшие вахтеры, навязали десятки спорных решений, и называют это хорошим решением для новичка. Притом новичок не может использовать инструменты вроде eslint и postcss по документации этих инструментов, CRA ломает использование инструментов.

Так не должно быть. Я собираю голоса на создание нормального инструмента для бутстрапинга react приложений. Пишите в комментариях всё, что думаете про CRA и его проблемы. Какие плюсы лично вам нравятся в CRA и их нужно перенести в адекватную реализацию?

Несколько интересных статей про Rust:

Что делает Rust универсальным языком — https://habr.com/ru/post/504622/

Передача намерений — https://habr.com/ru/post/326896/

Парсите, а не валидируйте — https://habr.com/ru/post/498042/

ESLint Overrides

Заметил, что часто требуется настроить ESLint для разных директорий по разному. Иногда, вообще нужно выключить некоторые правила в отдельных директориях (например, tests).

Не так давно в eslint config завезли параметр overrides. Позволяет переопределить правила для определенных файлов или директорий.
Выглядит так:

{
overrides: [
{
files: [“PATTERN”, “ANOTHER”],
excludedFiles: “EXCLUDE”,
...CONFIG,
}
]
}

- Вместо PATTERN и ANOTHER можно вписывать relative glob patterns выбирающие файлы, к которым применяются правила описанные в CONFIG.
- CONFIG это буквально такой же конфиг как и обычный eslint конфиг.
- excludedFiles опциональный параметр, позволяет выкинуть некоторые файлы из выбранных раннее.

Примеры

Включить JEST окружение для тестов:
{
files: [“**/*.test.ts”, “**/*.test.tsx”, “tests/**.ts”, “tests/**.tsx”],
env: { jest: true },
}

Включить плагин и конфиг для моделей:
{
files: [“**/model.ts”],
plugins: [“@company-name/eslint-plugin-model”],
extends: [
“plugin:@company-name/eslint-plugin-model/recommended”,
],
}

Документация

Пример конфига из моего проекта

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

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

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

Я начинал свои потуги планирования с разных инструментов: Trello, Productivity, Jira, Yandex.Tracker, Things3 и т.п. И везде одна и та же проблема — тупость. Они не могут подсказать как выполнить мои задачи, они не могут сами двигать сроки, подсказать какие задачи срочные и уместить их в свободное время. Это всё трекеры задач, а не менеджеры.

Сегодня снова услышал про Airtable. У него есть крутейшая апишечка и штука вроде блоков, которая позволяет автоматизировать работу с задачами. Airtable это такой Excel + Trello на мощнейших стероидах. Для табличек можно выбирать различные вьюхи, вроде календаря и канбана, разные отображения строк и колонок. Насколько я понял, есть продвинутая автоматизация. no-code во все поля. Надеюсь мне повезет и этот инструмент поможет мне планировать ровно так как мне нравится.

Как вы планируете свою жизнь? И вообще, нужно ли это?

Тем временем я решил немного рассказать о FeatureSlices. Но на крайне непривычной для меня платформе.

В течение недели буду выкладывать посты по теме. Ну и прикладывать к тексту совершенно рандомные фотки и картинки из айфона.


https://www.instagram.com/p/CBOVF2LK_OY/?igshid=r153a0q0jqmg

Как я планирую

Ощущение, что мне нужен сервис реализущий услуги секретарши и органайзера вместе. Чтобы лучше понять мою боль, расскажу как я сейчас планирую свою работу и личные проекты в Things.

У меня есть две секции для проектов Work и Personal.

В Work у меня есть проект с названием компании — REDMADROBOT. Это что-то вроде беклога, здесь размещаются все поступающие для меня задачи, в том числе задачи создать задачи команде в JIRA.
Задачи разбиты на секции по проектами и тимлидским обязанностям. Также задачи в каждой секции помечены одноименным тегом. Секции помогают разделить задачи при просмотре общего списка в проекте, а теги создают фильтры в виде табов, а также помогают увидеть к чему относится задача, после переноса в другой проект.

Каждое воскресенье в секции Work появляется повторяющийся проект «Рабочая неделя». Это конкретный план на каждую неделю. Я стараюсь заполнять его в воскресенье вечером или же утром в понедельник. Проект разделен на секции по методу Эйзенхауэра https://t.iss.one/sergeysova/32: «Важно и Срочно», «Важно и Не Срочно», «Не Важно и Срочно», «Не Важно и Не Срочно». Могу как-нибудь расписать подробно как я понимаю этот метод разделения задач.
В этот проект попадают задачи из проекта REDMADROBOT. Здесь же я ставлю задачам время исполнения и дедлайны. Задачи на сегодня появляются в отдельной секции в Things, а также на часах. Задачи у которых срок исполнения будет завтра-послезавтра, появляются в секции Upcoming.

Такая же схема с секцией Personal. Но там у меня больше проектов, ибо есть планирование на весь 2020 год (которое похерилось по всем известным причинам <на самом деле не поэтому>), различные идеи, которые я только собираюсь реализовать, проекты в разработке и у них тоже есть свои внутренние задачи. Также генерируется еженедельный проект «План на неделю» с такой же структурой.

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

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

Но пока что я ощущаю себя раздолбаем. Часто забываю про трекер задач, смотрю, что у меня 4 задачи с прошедшим сроком выполнения, приходится садиться и сдвигать все задачи недели, некоторые убирать в беклог. Иногда приходится двигать вручную задачи из годового планирования. И вот эта вся ручная работа раздражает до безумия. Из-за этого совсем отпадает желание заниматься планированием.

Как с этим справляются другие люди?

Продолжаю тему FeatureSlices. Скоро полетят примеры.

https://www.instagram.com/p/CBQ7nZFqVTj/?igshid=c54psp7z8tbk

Всё таки React изживает себя. Интересно, когда он совсем остановится в развитии, и потребует рефакторинга? А может нужно будет рефакторить основную идею?