Thread by @jsunderhood

Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента

Для меня сейчас - это основная и фундаментальная проблема в рамках GitLab. Я ее формулирую так "как реализовывать хранение и управление состоянием так, чтобы не рос технический долг и не страдал скорость деливери фич"

Нюанс начинается уже с определения: я осознанно ставлю вопрос технического долга важнее скорости деливери фич. Это связано с тем, что в случае "кризиса срочно-надо-на-вчера" (а так бывает и это нормально), когда мы ставим технический долг во главе угла - мы можем им пожертвовать

Другими словами - фокус на "скорость деливери фич" не даёт нам существенного запаса для "критического deliverable" и одновременно систематически убивает код. Фокус на технический долг - помогает коду жить, позволяя иногда использовать запретные заклинания (не злоупотребляя)

Что для меня важно - there is EXACTLY one way to do it. В проектах, где больше одного инженера, если что-то можно сделать "иначе" - оно будет сделано, и потом все будут морщить нос от кода друг друга.

Нам нужна мощная система ограничений, диктующая подходы к написанию кода

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

Забавно, что дизайнеры, к примеру, знают, что "творить" когда заказчиком поставлены ограничения - сильно проще, чем когда просто "сделайте мне ВАУ!"

Именно поэтому, к примеру, "голый" Redux вызывает у меня боль - слишком много способов сделать одну и ту же вещь, да и в принципе поверх него каждый строит что кому нравится - thunk, observable, saga - выбирайте. И даже в рамках одного подхода можно сделать очень по-разному

В то же время, если взять допустим RTK (redux-toolkit) - то это на порядок более взрослая система, которая принудительно навязывает вам подходы "так, а никак иначе".

При этом, что важно, давая достаточное количество escape hatches, если ограничения все-таки сделают вам больно

Нет, я не фанат redux или redux-toolkit :)

Нельзя не упомянуть свежерелизнутую redux-toolkit.js.org/rtk-query/over… RTQ Query (которая вдохновлена react-query и аналогичным). Я рад что фундаментальная мысль, что КЕШИРОВАНИЕ ОТВЕТОВ СЕРВЕРА ЭТО НЕ СОСТОЯНИЕ идет в мейнстрим

Здесь я не могу не кинуть огород в камень Vuex, который является стандартом де-факто в мире Vue - там всё это выглядит как редакс лет 5 назад - совершенно "дикое поле" и мысли о том, что надо разделять состояние и кеш только-только начинают звучать среди разработчиков на Vue

Пока я писал этот пост, @themagicworldof прислал типичный ответ про состояние "в идеале его не должно быть". Как по мне, это неправильное заявление. Мы должны избегать состояния, там, где мы можем это сделать, но не должны отрицать его там, где оно по факту есть

@themagicworldof Хорошим примером "чётко выраженного" состояния является WebIDE в GitLab - где локальные сущности (открытые файлы как пример) важны для большого количества компонентов, могут изменяться разными путями и так далее.

При этом самих типов локальных сущностей у нас много

@themagicworldof Текущий уровень управления состоянием в WebIDE для человека, который пишет GitLab но не пишет WebIDE - взрыв мозга. Цепочки связей достаточно сложные, понять что где и как хранится достаточно сложно (кто сказал TypeScript?), а главное - это нереально начертить на листочке

@themagicworldof Здесь я вижу два выхода, о которых я бы хотел поговорить. Первый - дробить состояние на отдельные "атомы" и организовывать связи между ними. По этому пути к примеру движется эффектор

@themagicworldof Я не фанат эффектора, но прекрасно понимаю какие боли он решает. При этом вы еще и можете получить ряд "инженерных плюшек". Про это недавно хорошо написал @kamyshev_code в blog.kamyshev.me/effector-fork-…

@themagicworldof @kamyshev_code При этом для меня и по моему опыту консалтинга - внедрение эффектора по уровню боли и трешовости вещей, которые я вижу в коде от инженеров находится где-то на уровне такого ада от RxJS. Учитывая что команда aviasales мигрирует как раз с rx на effector - я не удивлен что им хорошо

@themagicworldof @kamyshev_code Другими словами - в моей картине мира, rx и effector - примеры систем, требующих ощутимого изменения мышления, и, что немаловажно, не дающие инструментов как делать это "постепенно". Вы просто в один момент должны начать видеть поток фотонов вместо волны :)

@themagicworldof @kamyshev_code Если вы и ваша команда понимаете и осознаете фундаментальные основы (а это сложнее чем кажется) - вы будете писать крутой и продуктивный код и будете счастливы. При этом найм программистов тоже придется вести с учетом этого понимания

@themagicworldof @kamyshev_code А вот к примеру как онбоарднуть абстрактную фронтенд команду, развращенную, к примеру Vuex и Apollo в мир эффектора так, чтобы у меня не дергался глаз - я просто не представляю. Я пытался сделать это два раза - оба раза вернул деньги за консалтинг ибо провал

@themagicworldof @kamyshev_code При этом внедрить эффектор в проект "с нуля" заходит достаточно хорошо - не имея "вредных примеров" и жестко контролируя на входе качество "первых решений" мы создаем эффективную проектную базу копи-пасты и получается хорошо даже с теми, кто не осознает эффектор в полной мере

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

@themagicworldof @kamyshev_code А мы продолжаем. Вторым подходом в борьбе со сложностью является построение иерархических систем. Основное отличие - не всё связано со всеми, а у нас дерево состояний (или лес)

@themagicworldof @kamyshev_code Последний год я на личных проектах (остатки роскоши от аутсорсинговой компании) очень активно использую xstate от DavidKPiano и мне кажется, что если мы говорим о next big thing в стейт менеджменте - то вот это ближе всего. Для меня это музыка (оцените отсылку)

@themagicworldof @kamyshev_code Мне нравится идея использования давно известного механизма (statecharts) для решения задачи и нравится двумя вещами: строгостью и визуализацией

XState как раз прекрасный пример того, как при описании системы накладываются ЖЕСТОЧАЙШИЕ ограничения на то, что мы можем делать

@themagicworldof @kamyshev_code И именно эти жесточайшие ограничения приводят к тому, что в среднем на одну проблему ты видишь ровно одно нормальное решение. К сожалению, это решение не всегда сразу очевидно (мечты, мечты), но "виртуальный" фидбек "это решение плохо" не дает ошибаться даже в процессе обучения

@themagicworldof @kamyshev_code Пример из реальной жизни. Я очень люблю давать это упражнение на тренингах внутри компаний. Возьмите штук 15 спичек, сложите из них фигуру. Посадите программиста и попросите его давать инструкции другому программисту как сложить списки. Сравните результаты

@themagicworldof @kamyshev_code О чем это я и при чем здесь XState? Когда я даю домашние задания студентам, я часто вижу разные решения, а вот с xstate решения получаются "как под копирку" :) И это просто замечательно

@themagicworldof @kamyshev_code Конечно у XState есть недостатки. Если взять то же WebIDE (я использую ее как пример очень сложной системы), то наружная стейт-машина там будет состоять из малого количества "внешних" состояний и огромного количества вложенных стейт-машин

@themagicworldof @kamyshev_code То есть фактически, на каждую открытую вкладку мы будем создавать стейт-машины, которые точно так же надо будет координировать между собой. Иерархические отношения работают плохо в ситуации, когда в реалиях задачи всё это "тесно связанный клубок" :)

@themagicworldof @kamyshev_code Справедливости ради - большинство задач сильно проще и не требуют хардкора. И для меня гораздо важнее знание, что мой коллега ФИЗИЧЕСКИ не сможет позвать сайд-эффект в коде машины. Закон Парето как он есть :)

@themagicworldof @kamyshev_code TL;DR этого треда:

- хотите "скучный мейнстрим" - берите redux-toolkit
- хотите "новый" и другой подход - берите effector, но внимательно следите за тем, как ваши инженеры решают задачи, чтоб не допустить говнокода
- не готовы принять новую религию? Попробуйте старую - xstate!

@themagicworldof @kamyshev_code Особняком от этого подхода стоит Apollo Client - странный graphql-клиент с кешированием и зачатками стейт менеджмента. Про него я хочу сегодня чуть-позже поговорить отдельно, так как это совсем другая философия :)

Stay tuned, а я пойду поработаю :)