Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента
Для меня сейчас - это основная и фундаментальная проблема в рамках 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 прислал типичный ответ про состояние "в идеале его не должно быть". Как по мне, это неправильное заявление. Мы должны избегать состояния, там, где мы можем это сделать, но не должны отрицать его там, где оно по факту есть