Предоставляет знания: данные и методы работы с этими данными;
Реагирует на запросы, изменяя своё состояние;
Не содержит информации, как эти знания можно визуализировать;
Экземпляр Store из Redux:
Предоставляет знания: данные и методы работы с этими данными — YES
Реагирует на запросы, изменяя своё состояние — YES
Не содержит информации, как эти знания можно визуализировать — YES
Не вижу противоречий.
Controller связывавает View и Model. Здесь всё стандартно
Дело в том, что React-компонент может выполнять все роли из MVC — хранить данные, обрабытывать их и рулить другими компонентами, может даже дергать функции дочерних компонентов через Refs. Из-за таких широких возможностей многие лепят архитектуру как попало. Я же предлагаю вариант наведения в коде порядка, спроецировав старые добрые принципы в новую реальность
Про "легко" и "MVC" я написал, потому что для реализации его принципов в связке React и Redux не нужно никаких надстроек, не нужно своего кастомного кода — нужно лишь придерживаться пары простых принципов, как раз для хорошей организации кода
Мне кажется, что я использую связку React+Redux вполне стандартным образом. Просто я ввел некоторые ограничения, которые гарантируют, что все плюсы, которые дает нам Redux не будут сведены на нет. Про возможное убийство плюсов я писал.
Насчет "если нет возможности использовать Flux то зачем использовать редукс" не могу согласиться. Redux — всё-таки это не Flux (про отличия от предшественников можно почитать тут https://github.com/reactjs/redux/blob/master/docs/introduction/PriorArt.md )
Зачем строить MVC? Потому что плюсов масса, и потому что это легко сделать — посмотрите код всего приложения, там никаких кастомных решений нет — всё беру из коробки.
Я не фанат иммутабельности. Просто мне приходится использовать React + Redux. А там без иммутабельности никуда, на ней все держится. Я прекрасно понимаю, что мутабельность в большинстве случаев быстрее и лучше. Но не в React + Redux, а это нынче модное направление, и многим людям придется столкнуться иммутабельностью из-за этого.
Ситуация с тестами все таки возможна, и даже если найти поломку получится быстро — все равно это не очень приятный момент
Безопаснее использовать, и поэтому легче тестировать.
Предположим, первый тест вам массив случайно испортил, отсортировал его, а второй тест ожидает элементы в исходном порядке, а на отсортированном массиве он сломается. Т.е. ситуация такая — обвалился второй тест, а виноват первый. Причину поломки будет найти не так просто.
Спасибо за предложение — про иммутабельные поля на getter/setter обязательно добавлю. Про Proxy — не знаю, стоит ли. Поддержка в браузерах пока, что оставляет желать лучшего http://caniuse.com/#feat=proxy
Я как-то читал результаты опроса, где обычных людей из Индии спрашивали пользуются ли они на мобильнике интернетом, и пользуются ли они фейсбуком на мобильнике. Так вот — количество пользователей фейсбука получилось в два раза больше, чем количество пользователей мобильного интернета (чего не может быть)
К чему я веду — среднестатистический пользователь в ваккуме не обладает никакой технической грамотностью, не отличает интернет от браузера, и верстаете вы именно для него, а он скорее всего использует предустановленные приложения, т.к. о других не догадывается
Такой подход даёт гарантии. Если работает в этих дырявых браузерах — я уверен, что любой девайс 5-летней давности нормально отобразит вёрстку.
Я до недавних пор использовать морально устаревший телефон на android версии 4.0.3 — так там стандартный браузер работал примерно как safari 5.x, ничего там не поддерживалось. Мне думается, в мире много еще такого же барахла как этот телефон.
Хорошее напоминание для тех, кто использует flexbox где нужно и нет.
P.S. — для себя решил, что вёрстка хороша тогда, когда Opera 12.17, Safari 5.1.4, IE 9 корректно её отображает, может быть без поддержки всех фич, но корректно.
Вы говорите, что модели здесь вообще нет.
Описание модели из русской википедии:
Экземпляр Store из Redux:
Предоставляет знания: данные и методы работы с этими данными — YES
Реагирует на запросы, изменяя своё состояние — YES
Не содержит информации, как эти знания можно визуализировать — YES
Не вижу противоречий.
Controller связывавает View и Model. Здесь всё стандартно
Дело в том, что React-компонент может выполнять все роли из MVC — хранить данные, обрабытывать их и рулить другими компонентами, может даже дергать функции дочерних компонентов через Refs. Из-за таких широких возможностей многие лепят архитектуру как попало. Я же предлагаю вариант наведения в коде порядка, спроецировав старые добрые принципы в новую реальность
Про "легко" и "MVC" я написал, потому что для реализации его принципов в связке React и Redux не нужно никаких надстроек, не нужно своего кастомного кода — нужно лишь придерживаться пары простых принципов, как раз для хорошей организации кода
Насчет middlewares: я использую redux-thunk. Без проблем прикрутится redux-devtools, какой-нибудь логгер и т.д… По-идее middlewares не должны мешать
Пример использования redux-thunk:
Мне кажется, что я использую связку React+Redux вполне стандартным образом. Просто я ввел некоторые ограничения, которые гарантируют, что все плюсы, которые дает нам Redux не будут сведены на нет. Про возможное убийство плюсов я писал.
Насчет "если нет возможности использовать Flux то зачем использовать редукс" не могу согласиться. Redux — всё-таки это не Flux (про отличия от предшественников можно почитать тут https://github.com/reactjs/redux/blob/master/docs/introduction/PriorArt.md )
Зачем строить MVC? Потому что плюсов масса, и потому что это легко сделать — посмотрите код всего приложения, там никаких кастомных решений нет — всё беру из коробки.
fixed
fixed
Я не фанат иммутабельности. Просто мне приходится использовать React + Redux. А там без иммутабельности никуда, на ней все держится. Я прекрасно понимаю, что мутабельность в большинстве случаев быстрее и лучше. Но не в React + Redux, а это нынче модное направление, и многим людям придется столкнуться иммутабельностью из-за этого.
Ситуация с тестами все таки возможна, и даже если найти поломку получится быстро — все равно это не очень приятный момент
Безопаснее использовать, и поэтому легче тестировать.
Предположим, первый тест вам массив случайно испортил, отсортировал его, а второй тест ожидает элементы в исходном порядке, а на отсортированном массиве он сломается. Т.е. ситуация такая — обвалился второй тест, а виноват первый. Причину поломки будет найти не так просто.
Да — для node.js использовать Proxy — не проблема. А вот насчет шимов и полифилов — для Proxy они невозможны
fixed
Спасибо за предложение — про иммутабельные поля на getter/setter обязательно добавлю. Про Proxy — не знаю, стоит ли. Поддержка в браузерах пока, что оставляет желать лучшего http://caniuse.com/#feat=proxy
К чему я веду — среднестатистический пользователь в ваккуме не обладает никакой технической грамотностью, не отличает интернет от браузера, и верстаете вы именно для него, а он скорее всего использует предустановленные приложения, т.к. о других не догадывается
Я до недавних пор использовать морально устаревший телефон на android версии 4.0.3 — так там стандартный браузер работал примерно как safari 5.x, ничего там не поддерживалось. Мне думается, в мире много еще такого же барахла как этот телефон.
P.S. — для себя решил, что вёрстка хороша тогда, когда Opera 12.17, Safari 5.1.4, IE 9 корректно её отображает, может быть без поддержки всех фич, но корректно.