Комментарии 100
Только вот на таком простом примере для mobx вообще не требуется отдельный стор. А при усложнении примеров совсем не факт, что оба варианта будут усложняться одннаково.
Кстати, а почему вы в примере с mobx реализовали fetchPostList, а в примере с redux импортировали его из какого-то.api?
В redux можно вообще без блоилерплейта и без redux-toolkit. Там можно как угодно, и все это работает без классов и без магии, без всяких Observable и high order component, в функциональном стиле. Максимально простая библиотека, которую можно написать за один вечер самому. Потому и популярнее чем MobX.
Согласен, да. Очень часто слышу от людей, что redux г*овно т.к. много шаблонного кода, решил посмотреть, так ли это
Ну вы можете лицезреть здесь уровень тех, кто так говорит - сплошная некомпетентность, незнание основ redux и react, ни на один мой комментарий нет конструктивной критики или диалога, только минусы.
Думаю, минусуют не из за некомпетентности, а по той причине, что вместо фактических аргументов вы скатываетесь в переходы на личности или оценочные суждения, принижающие собеседников чуть ли не всю дискуссию: "очень слабый программист и пишите ерунду", "не вам мне рассказывать" (опять намек на низкую компетентность оппонента) - лень приводить всё, но подобным чуть ли не все ваши ответы сквозят. Если бы у вас действительно были аргументы, чтобы вести эту дискуссию конструктивно, сомневаюсь, что вы бы приводили подобные "аргументы" ниже пояса.
Если у оппонента низкая компетентность, но он этого не осознает и пишет откровенно ошибочные утверждения, выдавая за истину, нет ничего плохого в том, чтобы ему на это указать. Если ты не очень хороший программист то в будущем стоит вместо утверждений задавать вопросы. А тот человек еще и целую статью написал по теме, в которой не разбирается, чем распространяет свое невежество в среде разработчиков, что я считаю очень вредным явлением.
По поводу «вместо фактических аргументов» - я уже целую лекцию тут всем провел, начиная с возможности использовать в redux несколько сторов, заканчивая нормализацией, правильным хранением данных в сторе и deep linking, и даже недостатки mobx, пока отвечал на вопросы. Можно отдельную статью писать по каждому пункту. «Если бы у вас действительно были аргументы» - многое говорит и о вас раз вы этого не заметили.
На простом примере для MobX отдельный стор не нужен.
Так, круто, с бойлерплейтом разобрались. Теперь давайте разберемся с оптимизацией. Что предлагает редакс и mobx. Чтобы было проще предлагаю посмотреть, зачем нужен observer и причем тут proxy или get/set
В дополнение, предлагаю вам рассказать, что может предложить Mobx и redux в части локальных стейтов, когда не нужна «глобальная область видимости», а нужен конкретный стор для конкретного компонента, который будет работать как useState, но не наследовать его недостатков.
Можно какой то интересный бизнес кейс, когда вам пришлось реализовывать такую логику, мне сразу в голову ничего не приходит
Конечно. У вас есть список пользователей, при клике на одном из них вы переходите к странице с личной информацией, на которой у вас есть «жирный клиент» с возможностью добавлять, удалять и редактировать поля. Хранить такой стор как глобальный плохая практика, ведь при изменении юзера вам нужно делать условный «reset” стора, чтобы данные от прошлого юзера были затерты
id пользователя передается в экран, все пользователи хранятся в глобальном сторе. Вы очень слабый программист и пишите ерунду.
Вы очень слабый программист, если получаете весь список со всеми атрибутами в одном массиве. Вы и ваши бэк энд разработчики
Я думаю он имел ввиду щапрашивать профиль отдельно и добавлять его через entityAdapter, а если он уже запрашивался, то доставать по id.
Я думаю что оба варианта реализации хороши
Я нигде не писал про то, как они получаются. Они получатся могут как списком, с экрана со списком, и это абсолютно нормально, так и по отдельности.
И получаем утечку памяти при длительном использовании приложения?
Спасибо
Городить костыли вместо useState для локального состояния это очень сомнительная идея.
А можно подробнее про недостатки useState? Я вообще противник того, чтобы класть в redux то, что никогда не пригодится за пределами конкретного компонента. И описанную вами ниже задачу я бы решал именно через useState.
Почему я против того, чтобы хранить такое в redux? У меня есть очень большой проект на next.js и там больше десятка разных типов страниц и стэйты всех страниц засунуты в redux, в итоге при загрузке страницы next data весит порядка 2МБ, но большая часть глобального стейта - это дефолтные значения стейтов других страниц. Плюс запрос getServerSideProps занимает очень много времени (попядка 2 секунд), т.к. вместо того, чтобы запросить json данные с бэка и передать их на фронт, каждый раз на сервере происходит инициализация redux, запуск всего его жизненного цикла, потом сериализация стейта и отправка этого клиенту. Причём опять же большая часть респонса не нужна на запрашиваемой странице.
Локальный стор - это же context. Естественно, если компонента состоит не нескольких сабкомпонент. Иначе вообще стор не нужен
Обязательно напишу об оптимизации, пока что решил посмотреть на главный аргумент засирания Redux, комюнити mobx
Это один из главных аргументов. Но это дело вкусовщины. Нравится вам бойлерплейт и идеология flux, нет проблем. Проблема в том, что это не избавляет вас от «проблем» реакта, таких, как например, always new свойств. С Mobx useCallback, useMemo, memo, можно позабыть, потому что он решает проблемы связанные с ними
Я согласен, что это все дело вкуса, я не старался выставить один стейт менеджер лучше другого, а говорю, что аргументы о бойлерплейте неприемлимы.
По поводу оптимизации, если все правильно писать, то проблем никаких не будет, в redux есть все для оптимизации и мемоизация не нужна. Другое дело, что пишут все по разному. Не раз видел, как в mobx сторах, люди мапили или фильтровали.
В редаксе и прочих библиотеках где не производится deep comparsion, не обойтись без встроенных инструментов реакта. Или смириться с неизбежным перерендерингом компонентов
deep comparison это признак плохого кода и плохой оптимизации, и в react и redux он как раз не нужен из за грамотной архитектуры. Встроенные инструменты реакта вообще нужны для самого реакта в первую очередь, редакс обходится reselect если вообще нужно.
Я думаю, что вы однажды столкнетесь с клиентом, на котором будут нужны десятки / сотни вычислений из разных источников данных и тогда мы поговорим с вами о глубоком сравнении, оптимизации и других инструментах реакта и библиотеках которые отвечают за хранение данных
Именно на таких клиентах никому не придет в голову в здравом уме делать deep comparison когда можно обойтись shallow, и именно такими проектами я и занимался/занимаюсь. Так что не вам мне рассказывать.
А причём тут вообще deep comparison?
Вопрос не ко мне, товарищ @Modinрешил почему то, что оно лучше чем по ссылке или shallow, без аргументов.
А тут пишут, что deep comparison - самое правильное решение. Кому верить?
У вас возникали такие проблемы? Приходилось отрисовывать жирнейшую логику с множеством списков и фильтров, никаких проблем не было, да были некоторые рендеринги, но на UX это никак не влияло. Мне было бы очень интересно посмотреть пример, когда редакс не справляется
Да, полностью плюсую комментарию, что не в одном бойлерплейте дело: из-за того, что в Redux мы работаем с единым большим стором с определенного момента начинаются неизбежные проблемы с оптимизацией приложения (чего нет в MobX из-за разницы в реализации библиотек)
И добавлю, что в целом при работе с Redux могут быть различные подходы (например, асинхронщина может реализовываться как через Redux Thunk / Sagas / RxJS + Redux Observable - и в зависимости от выбранного подхода количество кода также будет значительно различаться.
В чем проблема с оптимизацией в Redux при разростании приложения? Не вижу проблем
Ну вот такой классический кейс: допустим, в вашем примере верстка поста уехала в отдельный компонент Post. При изменении какого-то поля отдельного поста, мобх может обойтись ререндером одного Post, а редукс вынужден дополнительно ререндерить список
Нет такой проблемы в redux, у вас очень слабое знание этой библиотеки.
Если я вас правильно понял, то для изменения данных в списке постов может быть использован createEntityAdapter, проблем не будет
Да, нормализация данных, я уж и подзабыл) Но тогда это в копилку лишнего бойлерплейта, разве нет? Мы вынуждены нормализовывать, а в мобх можно обойтись просто массивом объектов.
Ну, как вы будете изменять элемент, если передали только id? Нужно будет нормализовывать
Очевидно, что без нормализации передавать нужно не id, а сам объект. В чём вы видите сложность изменить свойство объекта?
передавать объект это типичный говнокод, с которым отвалится deep linking например
С фига ли говнокод и при чём тут вообще deep linking?
В тех случаях, где с передачей объектов возникнут проблемы, можно передавать id. Но вовсе не потому, что инструмент, видите ли, без этого не может нормально работать.
Передавать в экран объект вместо id это плохо всегда. Между вложенными компонентами допустимо. И да, инструменты тут ни при чем.
Я допускаю, что это плохо в некоторых отдельных случаях. Но по поводу "всегда" интересно увидеть обоснование.
Экраны должны быть автономны, должна быть возможность открывать любой экран хоть при старте приложения, и чтоб он подкачал все что ему требуется. Это нужно, например, для deep lilnking, и если так не делать, то когда это понадобится придется переписать половину приложения. Так же это показатель, что архитектура приложения удачная, и дает много других бонусов, о которых можно статью отдельную писать.
Добавлю, что при таком подходе компонент становится более автономным, не завязанным на глобальный стор, и легче тестируемым. Впрочем, это наверно очевидно...
В redux и без нормализаций хорошо работает, так как при реализации списков элементы списка мемоизируются, и при перерендеринге списка они не перерисовываются если не изменились их данные. Нормализация это скорей для совсем идеального решения.
У вас слабое знание предмета - библиотеки redux. Там можно делать несколько сторов. И да, у 99.9% приложений никаких проблем с оптимизацией не возникнет даже с одним стором.
В redux для асинхронищины вообще не обязательно что либо использовать. Просто мало кто об этом знает.
А кто говорит, что обязательно? Также как и то, что технически невозможно создать несколько сторов?
Скорее здесь был описан наиболее стандартный пример: стор один и он глобален, для взаимодействия с API / других асинхронных операций используется какая-либо библиотека из указанных выше (что как раз таки во многом позволяет сокращать кол-во бойлерплейта, который и оценивается). А насчет перформанса Redux даже его дока не дает однозначного ответа (с одной стороны да, многие приложения не будут сталкиваться с проблемами оптимизации, но в то де время другие библиотеки могут работать эффективнее, без траты времени на кастомизацию и профилирование): https://redux.js.org/faq/performance#how-well-does-redux-scale-in-terms-of-performance-and-architecture
P.S. И да, как грамотно ответил кто-то в комментах, говоря про бойлерплейт, для указанного примера самым лаконичным был бы React Query / SWR)
Критика боилерплейта redux это почти всегда рассуждения на примерах типа hello world. Вот только во-первых его можно очень неплохо "причесать", а во-вторых - с ростом проекта он не увеличивается, в отличие от MobX, где растет количество связей, появляются нетипичные проблемы, решать которые просто не получится, такие как сериализация, или инициализация большого куска данных из сохраненного состояния. В redux состояние это всегда максимально тупая структура, которую можно целиком стерилизовать и десериализовать при желании, а нетипичные ситуации практически отсутствуют - на все есть продуманное, популярное решение. А для mobx даже появился mobx-state-tree, чтобы решить эту архитектурную проблему.
Наиболее стандартный пример с одним стором потому и стандартный, потому что на практике это отлично работает, и даже не требуется разбивать на сторы, а для оптимизации достаточно грамотное использование и какой нибудь reselect, и только если нужно совсем хорошо, можно обратиться к нормализации (об этом и написано в доке), и созданию дополнительных сторов, и даже использование React.Context для какой нибудь темы. А практика вообще показывает, что в 95% случаев узкое горлышко это как раз не redux, а неоптимальный код на react, и соответственно выбирать технологию нужно изходя из того, какая проще. Redux намного проще, а значит лучше.
Это так же можно решить, в редаксе существует редюсер менеджер. Который вроде как способен подгружать в стор редюсеры лениво. Правда у меня его так и не получилось реализовать.
На прошлой неделе впервые поучаствовал в конференции по Frontend, где один из докладчиков, расказывал, как удачно его команда переехала с Redux на Mobx.
Примеры с конференций не очень показательны, даже переписав старое приложение с Redux на Redux можно здорово уменьшить код, просто самим фактом рефакторинга.
Пример в статье сильно маленький и не даёт особого представления о разработке. На таком примере Zustand будет короче обоих вариантов, а SWR или @tanstack/react-query вообще обойдутся парой строк для описания всего взаимодействия с сервером. Причём у последних реализация ещё и будет корректнее.
В реальном приложении будут играть роль такие моменты как:
Удобство композиции сторов. Использование одного действия для изменения нескольких сторов, например.
Удобство взаимодействие c компонентами, насколько библиотека opinionated (в данном контексте насколько она влияет на архитектуру приложения).
Оптимизация быстродействия. "Удобные" селекторы в Redux, например.
Взаиможействие с локальным стейтомЗачеркнул, потому что в React он сделан так, что в любой библиотеке это будет примерно одинаково ху..во.Взаимодействие с библиотеками для работы с сервером вроде SWR и @tanstack/react-query, либо наличие чего-то аналогичного в экосистеме.
Тестируемость.
Простота отладки и логгирования, в том числе в проде.
Взаимодействие с серверным рендерингом.
Удобство работы со сложным асинхронным кодом (всякие саги у Redux и экшены на генераторах у MobX).
Реализация шаблона внедрения зависимости, либо взаимодействие со встроенным в React внедрением зависимости через Context.
Откуда? Какие такие экшены на генераторах в Mobx? Mobx 5 это ванильный js/ts код за исключением, может быть makeAutoObservable в конструкторе класса. Все. После этого делайте хоть на генераторах, хоть на промисах, хоть на async/await, никто не диктует условий
Конечно, внутри, все устроено сложнее, но это скрыто от пользователя, по факту взаимодействовать придется с почти ванильным js
Никакое чудо не даст какой-то там библиотеке внедряться в механизм async/await, хоть десять версий выпусти. А внедряться надо, чтобы избегать лишних рендеров.
Так что либо генераторы, либо особый плагин к транспилятору.
Которые flow
И генераторы это ванильный код со времен ES2015
Вместо тысячи слов и споров, всё максимально наглядно и очевидно для всех.
Вот прям пример с MobX (меньше 100 строк кода), тут есть и глобальное состояние и локальное состояние компонента:
https://codesandbox.io/p/sandbox/adoring-banach-k8m9ss?file=%2Fsrc%2FApp.tsx
Реализуйте тоже самое, только используя Redux/RTK и приложите ссылку на codesandbox и сравним все вместе какой код приятнее, с RTK или с MobX. Критерий оценки не кол-во строк кода, а то, насколько код читаем, легко понятен и очевиден.
@artemmorozov13 ну так что, код будет?
А если еще чуть в сторонку посмотреть...
https://github.com/artalar/RTK-entities-basic-example/pull/1/files
Так всё же более понятно:
import { $mol_wire_solo as mem, $mol_wire_method as act, $mol_wire_sync as sync } from 'mol_wire_lib'
import userAPI from './userAPI'
export class User extends Object {
@mem static all( next?: User[] ) {
return next ?? sync( userAPI ).fetchAll().data
}
@mem static one( id: string ) {
return this.all().find( user => user.id === id )
}
@act static del( id: string ) {
this.all( this.all().filter( user => user.id !== id ) )
}
}А если говорить про редакс, то разница вообще на порядок.
Крайне неграмотный подход, в примерах используются разные подходы, например типы в редакс другие, а правильнее использовать такие же если мы хотим сравнить количество кода, в примере с компонентом тоже самое при использовании мобыкс почему то был использован switch case, можно было написать так же как и в примере с редаксом
Если получать данные в React server components и вызывать действия через server actions, то почти весь код можно убрать с клиента.
Обновили данные в бэке, перерисовали.
Особенно удобно, когда фулстек приложение.
Сегодня ни то ни другое не нужно ибо оба бойлерплейт - самое минималистичное по размеру и самое оптимальное и богатое по функционалу решение - Zustand ( я описывал его реализацию в статье)
Сегодня ни то ни другое не нужно ибо оба бойлерплейт - самое минималистичное по размеру и самое оптимальное и богатое по функционалу решение - Zustand ( я описывал его реализацию в статье)
И писать вот такой код??? Ахахах, пока все дома этого никто в здравом уме делать не станет.
// Писать вот это (Zustand )
set((state) => ({ bears: state.bears + 1 }))
set((state) => ({ bears: state.bears - 1 }))
// Вместо (MobX)
state.bears++
state.bears--
// Писать вот это (Zustand )
function Controls() {
const increasePopulation = useStore((state) => state.increasePopulation)
const decreasePopulation = useStore((state) => state.decreasePopulation)
return (
<div>
<button onClick={increasePopulation}>one up</button>
<button onClick={decreasePopulation}>one dowm</button>
<div>
)
}
// Вместо (MobX)
const Controls = observer(() {
return (
<div>
<button onClick={state.increasePopulation}>one up</button>
<button onClick={state.decreasePopulation}>one dowm</button>
<div>
)
})И это только самые самые базовые и тривиальные вещи, я уже молу про реальный мир, там вообще говнокод Zustand'a с его иммутабильностью утопит вас и весь проект по уши. Это же как надо себя ненавидеть, чтобы просто тупо принципиально не использовать MobX, а вместо этого использовать всякий шлак у которого реально ноль преимуществ.
самое минималистичное по размеру
// Писать вот это (Zustand )
set((state) => ({ bears: state.bears + 1 }))
set((state) => ({ bears: state.bears - 1 }))
// Вместо (MobX)
state.bears++
state.bears--Где? В каком месте?
и самое оптимальное и богатое по функционалу решение - Zustand
Где? В каком месте? Что тут есть богатого, что не доступно MobX'у?? Ах да, совсем забыл, ничего.
Не надоело по hello world сравнивать? PS. zustand ни разу не защищаю.
отнесем излишнюю эмоциональность комментатора на весенние деньки :), а по сути и без эмоций могу сказать, что то что любят начинающие и те кто пишет сам (всякую магию которая делается одной буквой и тому подобное) в промышленной разработке в больших командах не применимо - там эта "магия" вылазит боком!
Поэтому все лидеры рынка и пишут до сих пор на Redux и на MobX не перейдут никогда. Сейчас все из них присматриваются и переходят на Zustand.
По поводу всякой "магии" и черных волшебных ящиков у разработчиков выработалось защитное правило: все явное лучше не явного так проще найти и понять что и почему - в "магии" замучаешься искать
Да-да, saspense, virtual dom, hooks нисколько не магия. А вот автотрекинг зависимостей по факту обращения к ним, работающий так же как и тот же саспенс - это вдруг чёрная магия, тайные практики.
по сути и без эмоций могу сказать, что то что любят начинающие и те кто пишет сам (всякую магию которая делается одной буквой и тому подобное) в промышленной разработке в больших командах не применимо - там эта "магия" вылазит боком!
Object.defineProperty(target, key, {
get() {
// ...
},
set(v) {
// ..
},
});Вот и весь главный принцип так называемой вами "магии". Но практика такая, с 2016 года использования MobX никаких проблем, ничего боком не вылезало, одни только плюсы по сравнению со всеми остальными "аналогами".
Поэтому все лидеры рынка и пишут до сих пор на Redux и на MobX не перейдут никогда.
Да вы что? Вот прям так? Все лидеры рынка переходят с Redux на MobX и уже давно..
Сейчас все из них присматриваются и переходят на Zustand.
Спойлер, на самом деле все переходят на MobX.
По поводу всякой "магии" и черных волшебных ящиков у разработчиков выработалось защитное правило: все явное лучше не явного так проще найти и понять что и почему - в "магии" замучаешься искать
Да, но не в этом случае, ибо тут на get идёт подписка, а на set идут реакции. Всё. Достаточно это понимать, и сразу никакой "магии" и нет.
Да вы что? Вот прям так? Все лидеры рынка переходят с Redux на MobX и уже давно..
Это кто, например? Кроме Яндекс.Еды.
Давайте не будем обманывать себя и других - вы тут стыдливо умолчали и о Сбере и о Тинькове и о ВК и многие многие другие - все они используют Redux
По поводу Zustand - все его внутреннее устройство состоит из pub/sub объекта (для работы с не React) и единственный хук для React (все вместе около 2кб чистого кода!!!!) - чего еще проще может быть?????
ЗЫ: и давайте без эмоциональных высказываний и оценок - мы все же в публичном пространстве
Бла бла бла.
// Писать вот это (Zustand )
set((state) => ({ bears: state.bears + 1 }))
set((state) => ({ bears: state.bears - 1 }))
// Вместо (MobX)
state.bears++
state.bears--
// Писать вот это (Zustand )
function Controls() {
const increasePopulation = useStore((state) => state.increasePopulation)
const decreasePopulation = useStore((state) => state.decreasePopulation)
return (
<div>
<button onClick={increasePopulation}>one up</button>
<button onClick={decreasePopulation}>one dowm</button>
<div>
)
}
// Вместо (MobX)
const Controls = observer(() {
return (
<div>
<button onClick={state.increasePopulation}>one up</button>
<button onClick={state.decreasePopulation}>one dowm</button>
<div>
)
})Этого достаточно. Всё.
Вам нужно смотреть в сторону голого HTML и PHP, ибо реакт и т.п. это всё для вас не очевидно и страшная магия, как и mobx, а так глядишь нормально будет.
сразу нужно предупреждать что вы технологический ортодокс и экстремист, чтобы не связываться и не тратить зря силы и нервы :)
я вам говорю о внутреннем устройстве, а вы мне только якобы красивую сверкающую обертку показываете!!!
ЗЫ: Раневская как-то сказала: за каждым красивым хвостом фазана прячется обыкновенная жопа :)
Меньше эмоций - больше конструктива!
Вам определенно нужно устроиться поработать в крупную компанию, чтобы очень много чего понять и в технологическом плане и в плане культуры общения.
В крупных проектах не важны красивости - важна простота, надежность, понимаемость, простая отлаживаемость и предсказуемость. На маленьких проектах - это не важно, можно хоть левой ногой писать - там можно и всякие красивости со всякими рюшечками использовать
Говоря о конструктиве, если напишете код на zustand, то добавлю его в большое сравнение стейтменеджеров. Это позволит сравнить его архитектуру с остальными.
Хорошо я посмотрюи при наличии времени добавлю код
( Было бы хорошо если бы вы какое-нибудь описание дали по данному бенчмарку )
Дмитрий, очень рад пообщаться с вами!
За вами и вашими выступлениями слежу давно и с интересом.
Ваш взгляд на то как вы пишете и понимаете код для большинства - радикален. Без сомнений, вы много знаете и умеете, но способ программирования, который вы предлагаете резко выбивается из общего представления. Но все равно когда встречаю ваши материалы - пытаюсь прочесть или послушать.
Посмотрел я и описание и примеры бенчмарков - сходу разобраться что к чему и как их правильно написать - очень сложно. Может вы рассмотрите вариант общения в телеге, где я смогу если нужно что-то рассказать про Zustand а вы составите бенчмарк для него?
Меньше эмоций - больше конструктива!
Ну доводы про "магию" - это прямо максимальный антиконструктив. В том же Vue реактивность на точно таких же принципах, и никто на магию не жалуется.
Александр, возможно вы и правы. Речь идет о том, что я предоставил полное описание реализации Zustand в статье и там всё предельно просто и минималистично: pub / sub объект + один системный хук из React (всего около 2кб текста)
Разбираться во внутренностях реализации MobX нет ни сил ни желания поэтому я условно и назвал ее "магией". Оппоненты все время приводят в качестве аргумента его минималистичный интерфейс, но я же все время ведут речь о реализации ! Интерфейс - это совсем другой вопрос!
Было бы конструктивно со стороны оппонентов приводить преимущества в коде реализации и технологиях, а не в его интерфейсе
Разбираться во внутренностях реализации MobX нет ни сил ни желания
А во внутренностях Реакта, Тайпскрипта, v8, компилятора c++ (на котором был откомпилирован v8), отрисовкой в браузере, и т.д. вы уже разобрались? Или, например, добавляя в приложение карту, вдумчиво раскурили все карточные движки и сравнили?
Между фронтендерским кодом и результатом лежит огромный пласт всякой "магии". Мобх там занимает 0.0001%. Почему вопросы возникли именно к этим несчастным подписывающимся чтениям - ума не приложу.
А по поводу минималистичности интерфейса - можно посмотреть и на другую библиотеку автора Zustand - Daishi Kato (https://github.com/dai-shi) Valtio, но когда углубляешься в реализацию - понимаешь что за красивый хвост приходится платить .... :)
Вообще рекомендую Daishi Kato (https://blog.axlight.com/) - он автор нескольких типов state-manages
Redux это бойлерплейт, а Mobx нет! Но есть нюанс