Комментарии 9
За прошедшие годы командой Redux была собрана обратная связь и проделана огромная работа по улучшению библиотеки. Так на свет появился Redux Toolkit (RTK), а вместе с ним слайсы и RTK Query:
И что? Это всё равно все то же иммутабильное и примитивное убожество, чутка под другим соусом и всё так же с лишним кодом, хоть его стало чутка по меньше. До MobX ему как раком до Китая.
Ну почему же. В большинстве случаев менеджер состояний используется для хранения данных с бэкенда. Если использовать RTK Query, то просто в коде пишешь что-то типа:
const { data: citiesData, isLoading: isCitiesLoading } = useGetCitiesQuery()И всё, одна строчка кода и ты получаешь список городов, состояние запроса, кэширование по типу Apollo GraphQL, где не нужно задумываться о том, пришли у тебя данные с бэкенда или из стора.
Реально, одна строчка кода, никого бойлерплейта, а вся редаксовская дичь происходит где-то под капотом. При этом сама API генерируется автоматически из swagger схемы, то есть ничего не надо делать руками, всегда актуальные типы и нет несогласованности бэка с фронтом. Так что для общения с бэком очень удобно.
Да, если писать классические модели данных, записывать туда бизнес логику, то естественно MobX. Но это разные цели. И для большинства проектов за глаза хватит того общения с бэкендом, которое я описал выше
Вы описали проект по типо сайта визитки, где просто в тупую именно из реактовских компонентов достаточно дергать запросы без какой либо логики.
Но мы живем в реальном мире и в нормальных проектах всегда это логика есть, более того, запросу нужно дергать из любых мест, а не только из реактовских компонентов и быть полностью к ним прибитым гвоздями, а просто в тупую голые JSON'ы не гоняются. Поэтому вы изначально проект превращается в утопическую помойку когда используете redux, потом вы понимаете что всё, вы упали в бездну и начинается самая боль по выпиливанию этого недоразумения и замены его на MobX. Так вот, нафига все эти лишние телодвижения если можно сразу не канфилоть мозг ни себе, ни окружающим, ни проекту и сразу взять MobX.
Да и вообще всё остальное управление состоянием проекта вы как себе представляете? Использовать для этого средства реакта? - Это максимально нелепо и не разумно. Использовать для этого redux? - Точно так же, максимально нелепо и не разумно. MobX просто идеально для этого подходит, предназначение реакта одно, это тупо View слой, всё что он может это рисовать HTML в зависимости от состояния(которым конечно же не он должен управлять).
Реально, одна строчка кода, никого бойлерплейта
Ага, разве что в розовом мире и в розовых проектах без валидацией, без всевозможных условий формирования запросов, без цепочек запросов, без логики и т.д. и т.п.
Так что "аргумент" мягко говоря абсурдный
Вы описали проект по типо сайта визитки, где просто в тупую именно из реактовских компонентов достаточно дергать запросы без какой либо логики.
Да и вообще всё остальное управление состоянием проекта вы как себе представляете?
Этого более чем достаточно для написания всевозможных лендингов и админок, которые составляют немаленький процент от общего числа сайтов. Для всяких корпоративных порталов с формами и списками, где все остальное управление состоянием состоит из работы с данными форм.
в розовых проектах без валидацией, без всевозможных условий формирования запросов, без цепочек запросов
Для хранения данных форм и валидаций мы используем Formik, вполне устраивает, а условия формирования запросов и завязывать один запрос на другой RTK Query умеет.
Для вас MobX - золотой молоток, но тем не менее он нужен далеко не всегда
Для хранения данных форм и валидаций мы используем Formik
Мда, теперь всё встало на свои места, вам просто абсолютно всё равно на то, какой код вы пишете, поэтому просто берете первую попавшуюся поделку которая "решает" задачу и в путь.
Про то, что можно эти задачи решить гораздо лучше и удобнее че те "инструменты" которые вы используете вы даже не думаете, потому что это удел настоящих инженеров, которые много лет назад уже сами написали для себя инструменты для работы с такими тривиальными вещами как формы и их валидации, запросы к апи и т.п.
Mobx до Effector ему как раком до Китая
Вы извините конечно, но какой смысл всей этой статьи? Взять постфактум технологии которые вы используете и сказать что они хорошие потому что не плохие, при этом приводя в качестве аргументов оксюмороны вроде "Он простой и не переусложненный, но в тоже время мощный".
Мне бы, как читателю, было бы интересно прочесть - какие боли есть у технологий, которые вы используете, и почему, ни смотря на эти боли, вы любите и используете именно эти технологии.
Конечно все понимаю, но вроде бы какой никой IT блог а не флудилка.
За что мы любим Go, Ruby, React Native, ReactJS и Redux