до фрактала набрел на такое(это форк с небольшими изменениями): github.com/plandem/react-redux-controller и, честно говоря, с тех пор такой подход мне нравится все еще больше, чем фрактал или то, что в статье. Там хотя бы есть какое-то упрощение кода.
что именно? redux-orm? У нас связи между моделями + reselect иногда не тривиальный был, в итоге поняли, что практически сделали «то же самое, но свое». orm мы только для локального кэша объектов из БД используем, для других частей, простые reducer, без orm.
Я не утверждаю, что immutable панацея, нужно смотреть на требования. В текущем проекте, например, immutablejs не используем.
p.s.: хранилище данных может быть сложным, если, например, нужно повторить «структуру БД», а если еще и несколько схем, то все усложнится в разы. это все application specific и выбирать инструмент нужно по требованиям.
Изначально комментарий был про то, что результаты у spread и immutablejs не всегда одинаковые и нужно это понимать и использовать то, что лучше подходит.
да даже пусть у вас будет просто объект, с 10 полями. Вы будете все их проверять и потом делать spread, если было реальное изменение?
{ name: 'aaa', age: 10, email: 'spam@spam.it', .....}
прилетает запрос на выставление age в 10 или даже на age + email. Данные не поменялись, но запрос прилетел. Можно сделать spread:
{ ...state, ...action.updates}
и получим новый объект (данные не поменялись на самом деле, прилетел запрос на изменение такой: { age: 10, email: 'spam@spam.it'). immutable вернет тот же объект.
В более сложном чем счетчик reducer, запросто могут быть объекты. Например, что-то типа ORM для более удобного работы с объектами. В реальном приложении state далеко не примитивны.
если именно про Reddit, то в Индонезии, например, блокирует его. Но думаю речь шла про, что в каждой стране можно найти какие-то «неугодные ресурсы» которые заблокировали
неужели прикрутили кэширования для RBAC? а то с самых первых версий приходится его всегда расширять/переписывать, чтобы хотя бы кеширование сделать — без него в случае если каждый «чих» проверяется через RBAC просто нереально.
нативность — да, но что насчет кастомных контролов? Например, сделать свой контрол и свою анимацию? Я пробовал и титаниум и pixate(точнее freestyle), все они хороши до тех пор, пока нет задачи написать что-то кастомное и когда начинаешь это делать, то встает большой вопрос использования этих решений — проще нативно сразу писать. Какую задачу будет решать reactiveJS native? код для каждой платформы будет свой. Что тогда решается?
Статья, конечно, уже достаточно древняя, но тем не менее. Еще в свое время потратил много времени, чтобы опытным путем выяснить (раньше это не было задокументировано), что у NSManagedObject weak связь с context — в свое время доставило это геммороя.
p.s.: хранилище данных может быть сложным, если, например, нужно повторить «структуру БД», а если еще и несколько схем, то все усложнится в разы. это все application specific и выбирать инструмент нужно по требованиям.
Изначально комментарий был про то, что результаты у spread и immutablejs не всегда одинаковые и нужно это понимать и использовать то, что лучше подходит.
{ name: 'aaa', age: 10, email: 'spam@spam.it', .....}
прилетает запрос на выставление age в 10 или даже на age + email. Данные не поменялись, но запрос прилетел. Можно сделать spread:
{ ...state, ...action.updates}
и получим новый объект (данные не поменялись на самом деле, прилетел запрос на изменение такой: { age: 10, email: 'spam@spam.it'). immutable вернет тот же объект.
E.g.: immutable не создает новый объект, если данные реально не были изменены, spread — создаст.
хотя скриншоты сделать — это круто. пока крашлитиком без скринштов и с подробными логами вроде справляемся, но визуалки при анализе не хватает.