Что используете в проде с react?

▪️ 34% (158) Классы

▫️ 40% (184) Хуки

▪️ 14% (67) ХОКи

▫️ 9% (44) recompose
🔠 Можно выбрать несколько вариантов
👥 453 (310) - всего голосов

На днях меня позвали пообщаться о расте в подкаст "Цинковый прод".
Высказал немного своего мнения.
Подписывайтесь, ребята интересные темы задвигают.

https://soundcloud.com/znprod/010-rust-i-rifmy-pochemu-funktsionalnoe-vazhno-kogda-indeksy-reshayut-go-i-realnyy-mir

Сколько времени тратить на личные проекты?

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

Каждый день мне не хватало времени. Я не успевал записать хотя бы одну идею, а их рождалось очень много. Со временем, я научился формулировать каждую идею в 2-3 предложениях. Стал выписывать их в тетрадки. В какой-то момент количество тетрадей перевалило за третий десяток. Пришло осознание, что я делаю что-то не так: я только придумываю новые идеи, но не реализовал ни одной. Надо это менять.

Казалось бы, возьми любую идею и реализуй. Но не всё так просто. Даже самая простая идея, потребовала бы для запуска серьезных финансовых вложений, не говоря уже о навыках. Тогда я познакомлся с кучей подходов по созданию и управлению проектами: SMART, SCOPE-PAK, PMBoK и т.д. Но ни один не приносил результатов. Да, я составлял план и пытался оценить свои возможности. Да, я оставлял только самое необходимое от каждой идеи. Да, я устанавливал минимальные сроки для реализации каждой вехи.

Я думал, что достаточно хорошо описать проект, составить план, а дальше всё пойдет как по маслу, само собой. Найти единомышленников будет легко, ведь идея глубоко расписана и распланирована разработка. Инвесторы будут в восторге от бизнес-плана с покрытием всех рисков. Реальность дала о себе знать на первой встрече с представителем группы инвесторов: "План, покрытие рисков, желание, это всё конечно хорошо, но где опыт? Откуда нам знать, что Вы действительно сможете реализовать тот план, который описали. В вашем послужном списке нет сильных навыков управления компанией".

Это не был удар сваливший меня в депрессию. Это была твердая рука опытного человека, усадившая меня в кресло подумать. Я долго не мог понять, как же сделать проект самому, без финансов и совета опытных людей. Где быстро набраться опыта, прежде чем приступить к полноценным проектам. Я думал, что мне нужна "песочница", проекты на которых я мог потренироваться, прежде, чем начать работать "по-взрослому".

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

Нет никакой песочницы и игрушечных проектов. Играя только с песком, научишься строить только дома из песка. Чтобы строить настоящие проекты "для взрослых", нужно постоянно делать именно такие проекты. Да, возможно, кто-то скажет, что ты ничего не умеешь и не сделаешь, но пока он говорит, ты будешь учиться и развивать свои навыки. Ты будешь совершать ошибки, которые будут тебе дорого стоить. Ошибки научат тебя как строить.

Так сколько же времени тратить на личные проекты, чтобы выйти за рамки наёмного работника. Чтобы понять это, невозможно обойтись без определения своих целей. Может быть Вы счастливы приходя в офис и получая свою зарплату. Зачем в этом случае отправлять в неизведанные воды?
Если Вы каждый день просыпаетесь с мыслью, что жизнь не такая, как Вам хотелось бы — пора менять свою жизнь.

Начните делать то, что приблизит Вас к вашей цели. Тут всё просто, есть две категории дневных дел: полезные и развлекающие. Нужно избавиться от людых занятий, которы отдаляют Вас от своей цели. А также необходимо сбалансировать полезные дела и развлекающие, отдых невероятно важен для прогресса. Если нехватает времени в сутках, попробуй вставать в 6-7 утра, а ложиться в 22-23. Утром мало отвлекающих факторов, мозг ещё свеж и чист, можно начать планировать свой день или выполнять работу по личным проектам. Если сложно проснуться и заставить себя работать, поход в спортзал приведет организм в тонус.

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

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

Я начинаю каждое утро с планирования дня, оценки планов на неделю, месяц и год. Заканчиваю день, легкой ретроспективой, что успел, а что нет и почему. Очень хочу начать читать книги регулярно, но пока не решил когда это делать лучше всего. На самом деле, я ещё не выработал в себе дисциплину полностью соблюдать план на день. Возможно, я слишком много планирую и мне нужно научиться выполнять 100% поставленных задач, пусть их будет 3. А уже после переходить к большему количеству.

Спасибо, что читаете!

Я записал тестовую дорожку.
Послушайте и напишите комментарий с пожеланиями, предложениями или замечаниями: https://podcast.sova.dev/

Написал заметку о структуре frontend-приложения.

https://sova.dev/ru/application-structure/

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

Уже несколько дней подряд думаю о нейронках и ДНК. Не могу написать ни строчки кода или сценария...

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

Натренировать на этой базе нейронные сети распознавать каждый пункт анкеты. Сложно даже представить какие результаты будут. Ведь нейронка не определяет факты, она лишь найдет корреляции. Например, схожесть ДНК курильщиков. А может это не схожесть и действительно заложено в нашей наследственности?

Только что закончился Аргументариум с ребятами из 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