Если вы не против я ни буду писать вам в ответ еще портянку текста.) Как будет достаточно кармы поставлю вам + за конструктивное и хорошо обоснованное мнение. Я приму к сведению ваши замечания.
Не понимаю зачем включать в статью голословные заявления и объяснять это субъективным мнением.
Ваше замечание вполне уместно, в случае с mobx я действительно скупился на текст. Тем не менее в статье я меньше всего хотел сравнивать инструменты, а просто-напросто рассказать что меня побудило на создание своего state-manager.
Какой смысл разделять стор от экшенов?
Во-первых, я сторонник подхода разделяй и властвуй. Во вторых вы же понимаете что утиный hello world это не показатель, в повседневной жизни управляемые состояния могут содержать гораздо большое количество кода, и на мой взгляд чем больше есть возможностей декомпозиции тем лучше. И наконец подход с middleware позволяет с легкостью создать свой вариант реализации функции работы с actions, в случае если вас не устраивает модуль Adapter. Так же у вас есть возможность вообще не использовать управление состояниями.
Зачем прокидывать экшны в аргументы observer?
Если вы подробно ознакомитесь с паттерном проектирования observer, то поймете что явное указание подписчиков в слушателе является более правильной практикой.
Явное указание зависимостей делает код более очевидным;
Ручная подписка на определенные состояния помогает избежать незапланированных перерисовок компонента.
Что за странная конвенция импортировать connect как adapter и добавлять его в массив middleware?
Тут я честно говоря не знаю что вам ответить… Для меня так удобней. Export/import гибкий инструмент всегда можно сделать так как удобней вам.
У вас стор импортируется из модуля инициализированный, как мне создать 2 инстанса стора (пример — 2 независимых инстанса duck)?
А зачем? Что бы ваш код было сложней поддерживать? Biscuit ориентируется на подход с централизованными контейнерами состояний и сам по себе является инстансом объекта store. Если вы работаете, например localStorage вы же не делайте кучу его инстансов… Тут похожий подход.
Как написать unit-test на store, не сбрасывая его состояние перед каждым тестом?
Я честно говоря не понимаю зачем вам нужен тест конкретно store… Функция createStore уже протестирована за вас. Тесты будет уместней писать для конкретных actions. Сейчас это можно организовать на моках. В ближайшем будущем планирую написать инструмент для тестирования. P.s. Mobx действительно удобно тестировать, как и любой класс, этого я ни в коем случае не отрицаю.
Почему экшн duckQuack переименовался в setQuack?
Это вопрос реализации, а не подхода.
В вашем примере для меня непонятна реализация с useState. Зачем имплементировать встроенный state-managment React совместно со стейт-машиной mobx? А Так же. Возможно я ошибаюсь, но ваш store предоставляет мутабельное поле value во внешний мир, Нарушая принцип инкапсуляции.
Лично для меня observer mobx неочевиден по вышеуказанным причинам.
Мне, если честно очень неприятно отвечать на вашу абсолютно не обоснованную, неконструктивную, агрессию. Но.
Боже откуда вы только берете такие мысли, сразу видно тех кто никогда не юзал MobX на реальном проекте в бою, однако ещё заключения какие-то умудряются делать.
Тут вы неправы… По воле судьбы я сейчас работаю на проекте завязанном, на Mobx, в котором принимают участия более 5 смежных команд.
И поверьте то что я написал, я взял не из своей бурной фантазии.
Если есть MobX который на порядок лучше абсолютно по всем параметрам всех redux-like поделок и redux'a.
Я честно говоря, не понимаю, зачем нужно сравнивать «пассатижи» c «плоскогубцами». Как-то это не по-взрослому. Каждый инструмент по-своему хорош.
Ваше замечание вполне уместно, в случае с mobx я действительно скупился на текст. Тем не менее в статье я меньше всего хотел сравнивать инструменты, а просто-напросто рассказать что меня побудило на создание своего state-manager.
Во-первых, я сторонник подхода разделяй и властвуй. Во вторых вы же понимаете что утиный hello world это не показатель, в повседневной жизни управляемые состояния могут содержать гораздо большое количество кода, и на мой взгляд чем больше есть возможностей декомпозиции тем лучше. И наконец подход с middleware позволяет с легкостью создать свой вариант реализации функции работы с actions, в случае если вас не устраивает модуль Adapter. Так же у вас есть возможность вообще не использовать управление состояниями.
Если вы подробно ознакомитесь с паттерном проектирования observer, то поймете что явное указание подписчиков в слушателе является более правильной практикой.
Тут я честно говоря не знаю что вам ответить… Для меня так удобней. Export/import гибкий инструмент всегда можно сделать так как удобней вам.
А зачем? Что бы ваш код было сложней поддерживать? Biscuit ориентируется на подход с централизованными контейнерами состояний и сам по себе является инстансом объекта store. Если вы работаете, например localStorage вы же не делайте кучу его инстансов… Тут похожий подход.
Я честно говоря не понимаю зачем вам нужен тест конкретно store… Функция createStore уже протестирована за вас. Тесты будет уместней писать для конкретных actions. Сейчас это можно организовать на моках. В ближайшем будущем планирую написать инструмент для тестирования.
P.s. Mobx действительно удобно тестировать, как и любой класс, этого я ни в коем случае не отрицаю.
Это вопрос реализации, а не подхода.
В вашем примере для меня непонятна реализация с useState. Зачем имплементировать встроенный state-managment React совместно со стейт-машиной mobx? А Так же. Возможно я ошибаюсь, но ваш store предоставляет мутабельное поле value во внешний мир, Нарушая принцип инкапсуляции.
Лично для меня observer mobx неочевиден по вышеуказанным причинам.
Тут вы неправы… По воле судьбы я сейчас работаю на проекте завязанном, на Mobx, в котором принимают участия более 5 смежных команд.
И поверьте то что я написал, я взял не из своей бурной фантазии.
Я честно говоря, не понимаю, зачем нужно сравнивать «пассатижи» c «плоскогубцами». Как-то это не по-взрослому. Каждый инструмент по-своему хорош.