Велики только после покраски! Налетай!
Ваш вариант лучше простой мапы экшнов описанной в главе "Выбор редьюсера из объекта по ключу" хотя бы тем, что позволяет биндить один и тот же редьюсер на массив экшн типов, но мне кажется, что он все же проигрывает в читаемости классам.
Плюс в reducer-class из коробки immer, поддержка разных экшн криэйторов, дабы не передавать сам тип, обработка кейса, когда одному типу соответствует несколько редьюсеров.
Как по мне, то либа более многословная в плане создания экшнов по сравнению с flux-action-class.
Если же говорить о редьюсерах, то ее функционал ничем не отличается от кейса "Выбор редьюсера из объекта по ключу" разобранного в этой статье. В начале главы "Редьюсеры на основе классов" я расписал те преимущества, которые я вижу для себя. Безусловно это очень субъективный набор. Для себя все же пока остановился на классовых редьюсерах в силу читаемости и, как следствие, поддерживаемости.
Одним из лучших вариантов организации редьюсеров через классы мне представляется ngrx-actions. Мне немного не хватало в нем типизации, и т.к. автор забил на проект, то я его переписал. Но, в целом, мысли похожие.
А что если так?
```javascript
const makeGetComment = () => createSelector(
[
(state, props) => state.entities.comments[props.id],
(state, props) => state.entities.users[
state.entities.comments[props.id].author
]
],
(comment, author) => ({
...comment,
author
})
)
```
Выглядит, конечно, ужасно, но работать по идее должно без лишней инвалидации селектора. Как раз такой пример по идее и решается redux-orm. Хотя, честно говоря, не так уж часто мне приходилось сталкиваться с необходимостью делать подобную денормализацию. Обычно, проще сервер попросить вернуть данные в нужном формате. Иначе если запросить список юзеров и список комментов отдельно, то можно получить слишком много данных (не все комменты нужно отображать, не для всех юзеров и т.д.). А если предположить, что список комментов уже был получен ранее, то можно нарваться на проблемы кеширования. Так что подобные проблемы становятся действительно актуальны чаще всего тогда, когда мы хотим с локальным кешем работать и лениво го с серваком синхронизировать.
Так или иначе, ваш посыл понятен. Спасибо. Надо присмотреться к MST.
Можете пример какой подсказать или статью где есть работа с графовыми данными в MST и аналогично в Redux?
Сам какое-то время работал с redux-orm. Увидев, выпученные от удивления глаза новых членов команды, выплил ее к чертям. Сейчас для хранения списков, если нет глубокой вложенности, предпочитаю `Map`, т.к. оно и O(1) по ключу дает, но при этом и порядок вставки запоминает.
1. Спасибо. Посмотрел. Ваша правда.
2. Вы ведь немного лукавите насчет O(n), правда? :) Я к тому, что `listener`, конечно, будет вызываться при каждом обновлении стора, но использование PureComponent позволит избежать ререндера.
Это, по-моему, в принципе, самая большая проблема экосистемы реакта — отсутствие стандартов, которые бы поддерживались профессионалами на зарплате, а не энтузиастами.
Поэтому лично мне хочется на данном этапе иметь набор библиотек, которые помогут побороть бойлерплейт, но при этом будут оставаться максимально простыми, с как можно меньшим количеством проприетарного API.
Это верно подмечено. Сделано было для пущего драматического эффекта. Но на самом деле ActionStandard вынесен в библиотеку, createReducer вынесен в библиотеку, так что их и не придется писать. Написать надо будет разве что reducerLoadingMap. Но пара лишних строчек на reducerLoadingMap с лихвой окупится, когда будет работа не с одной сущностью, а с десятью.
Мысль как раз в том и была, что не стоит бездумно использовать все, что под руку попадется. Пример с селекторами привел лишь потому, что в документации к самому NGRX предлагается использовать мемоизацию на каждый чих.
Redux-act — да, клевая штука. Разве что их createAction с TypeScript дружит не так хорошо, как flux-action-class, а createReducer немного перегружен на мой взгляд по сравнению с redux-create-reducer, потому что парень хотел ES5 поддержать
Как по мне, то разница между простым логгированием и экшнами в том, что логгирование позволяет попробовать догадаться о состоянии, что там происходило, а экшны дают точную реплику этого состояния. В общем, для маленьких приложений, вроде как, и не актуально. А в средних и больших, вроде как, и полезно.
Не только можно, но даже нужно! Единственное, я для себя пришел к выводу (на данный момент), что подобные обертки надо писать каждый раз заново для каждого проекта. Все проекты немного разные с разными требованиями, поэтому я пока предпочитаю иметь в наличии множество небольших кубиков (таких как flux-action-class, набор стандартных редьюсеров для работы со списками и т.д.) и собирать из них конечный велосипед под нужды проекта. В конечном итоге, да, стремлюсь собрать заниженный велик с турбированным движком и тонировкой по периметру, чтобы получалось что-то похожее на то, что вы предложили.
Дык оно и в Реакте можно без Redux. Также в одну строчку, используя браузерный fetch API. Как по мне, так основная проблема mol — это его популярность, точнее ее отсутствие. Когда я выбираю фреймворк/библиотеку для нового проекта, одним из важных аргументов является популярность. Просто потому что бизнес может захотеть расширить проект, привести новых людей в команду. При использовании популярных решений сделать это будет в разы проще.
Для начала скажу, что MobX в проде не юзал пока, дабы был контекст. Теперь по делу. Мне нравится подход MobX лаконичностью, но там нет святого грааля Redux в моем понимании — возможности сделать replay. В идеале, хочу держать в свое сторе как можно более полное состояние приложения, чтобы потом при ошибке у пользователя получить набор экшнов, который к этому привел, и с точностью воспроизвести ошибку. Плюс самому дебажить по диффам между состояними стора и списку экшнов — одно удовольствие.
Я к курсе, что есть mobx-state-tree. Глубоко его не изучал пока что, но собираюсь посидеть и поковырять. Есть опасения насчет производительности в некоторых случаях. Как я понимаю, для того чтобы заставить императивные операции, которые мутируют стейт, возвращать новое иммутабельное состояние, они должны были запилить некий proxy наподобие immer. Есть подозрение, что в некоторых случаях редьюер сделанный руками будет эффективнее, чем иммутабельность через прокси в mobx-state-tree.
А можно поинтересоваться, насколько большие вам доводилось делать? Какая была самая большая команда в которой приходилось работать?
Если проект небольшой и пишется в одно лицо, то можно много каскадных красивостей нагородить. При наличии даже двух разработчиков начнется ад.
Как по мне, так основная проблема, которую необходимо решить любому языку, транспилирующемуся в js, — это размер коммьюнити и возможность использовать существующие библиотеки. Тот же Typescript имеет огромное коммьюнити и кучу типов для уже известных js библиотек. Как у этого с котлин?
Самому нравится шарить DTO и валидацию между фронтом и беком. Для этого все пишу на
TS — не вижу проблемы подождать компиляции. Честно говоря, новые фичи пилю большую часть времени вообще не глядя в браузер, только код в IDE. Спустя час-другой, когда все готово, уже делаю смоук тест в браузере. Обычно все работает с минимальным шаманством как раз благодаря типизации ТС и отлову ошибок ещё во время компиляции.
Препроцессоры — их клмбинирую с css переменными. У них есть классный синтаксический сахар для описания классов с префиксами.
Менеджмент стейта — вы предлагаете костылировать самому то, что уже написано? Зачем? Если результат тот же, то не проще ли использовать готовое? Чтобы облегчить боль новых девов на проекте и чтобы использовать уже протестированные
Велики только после покраски! Налетай!
Ваш вариант лучше простой мапы экшнов описанной в главе "Выбор редьюсера из объекта по ключу" хотя бы тем, что позволяет биндить один и тот же редьюсер на массив экшн типов, но мне кажется, что он все же проигрывает в читаемости классам.
Плюс в reducer-class из коробки immer, поддержка разных экшн криэйторов, дабы не передавать сам тип, обработка кейса, когда одному типу соответствует несколько редьюсеров.
Как по мне, то либа более многословная в плане создания экшнов по сравнению с flux-action-class.
Если же говорить о редьюсерах, то ее функционал ничем не отличается от кейса "Выбор редьюсера из объекта по ключу" разобранного в этой статье. В начале главы "Редьюсеры на основе классов" я расписал те преимущества, которые я вижу для себя. Безусловно это очень субъективный набор. Для себя все же пока остановился на классовых редьюсерах в силу читаемости и, как следствие, поддерживаемости.
Одним из лучших вариантов организации редьюсеров через классы мне представляется ngrx-actions. Мне немного не хватало в нем типизации, и т.к. автор забил на проект, то я его переписал. Но, в целом, мысли похожие.
Рекомендую попробовать Zoom. Качество лучше на порядок
```javascript
const makeGetComment = () => createSelector(
[
(state, props) => state.entities.comments[props.id],
(state, props) => state.entities.users[
state.entities.comments[props.id].author
]
],
(comment, author) => ({
...comment,
author
})
)
```
Выглядит, конечно, ужасно, но работать по идее должно без лишней инвалидации селектора. Как раз такой пример по идее и решается redux-orm. Хотя, честно говоря, не так уж часто мне приходилось сталкиваться с необходимостью делать подобную денормализацию. Обычно, проще сервер попросить вернуть данные в нужном формате. Иначе если запросить список юзеров и список комментов отдельно, то можно получить слишком много данных (не все комменты нужно отображать, не для всех юзеров и т.д.). А если предположить, что список комментов уже был получен ранее, то можно нарваться на проблемы кеширования. Так что подобные проблемы становятся действительно актуальны чаще всего тогда, когда мы хотим с локальным кешем работать и лениво го с серваком синхронизировать.
Так или иначе, ваш посыл понятен. Спасибо. Надо присмотреться к MST.
Сам какое-то время работал с redux-orm. Увидев, выпученные от удивления глаза новых членов команды, выплил ее к чертям. Сейчас для хранения списков, если нет глубокой вложенности, предпочитаю `Map`, т.к. оно и O(1) по ключу дает, но при этом и порядок вставки запоминает.
2. Вы ведь немного лукавите насчет O(n), правда? :) Я к тому, что `listener`, конечно, будет вызываться при каждом обновлении стора, но использование PureComponent позволит избежать ререндера.
Поэтому лично мне хочется на данном этапе иметь набор библиотек, которые помогут побороть бойлерплейт, но при этом будут оставаться максимально простыми, с как можно меньшим количеством проприетарного API.
Это верно подмечено. Сделано было для пущего драматического эффекта. Но на самом деле ActionStandard вынесен в библиотеку, createReducer вынесен в библиотеку, так что их и не придется писать. Написать надо будет разве что reducerLoadingMap. Но пара лишних строчек на reducerLoadingMap с лихвой окупится, когда будет работа не с одной сущностью, а с десятью.
Мысль как раз в том и была, что не стоит бездумно использовать все, что под руку попадется. Пример с селекторами привел лишь потому, что в документации к самому NGRX предлагается использовать мемоизацию на каждый чих.
Redux-act — да, клевая штука. Разве что их createAction с TypeScript дружит не так хорошо, как flux-action-class, а createReducer немного перегружен на мой взгляд по сравнению с redux-create-reducer, потому что парень хотел ES5 поддержать
Не только можно, но даже нужно! Единственное, я для себя пришел к выводу (на данный момент), что подобные обертки надо писать каждый раз заново для каждого проекта. Все проекты немного разные с разными требованиями, поэтому я пока предпочитаю иметь в наличии множество небольших кубиков (таких как flux-action-class, набор стандартных редьюсеров для работы со списками и т.д.) и собирать из них конечный велосипед под нужды проекта. В конечном итоге, да, стремлюсь собрать заниженный велик с турбированным движком и тонировкой по периметру, чтобы получалось что-то похожее на то, что вы предложили.
Дык оно и в Реакте можно без Redux. Также в одну строчку, используя браузерный fetch API. Как по мне, так основная проблема mol — это его популярность, точнее ее отсутствие. Когда я выбираю фреймворк/библиотеку для нового проекта, одним из важных аргументов является популярность. Просто потому что бизнес может захотеть расширить проект, привести новых людей в команду. При использовании популярных решений сделать это будет в разы проще.
Для начала скажу, что MobX в проде не юзал пока, дабы был контекст. Теперь по делу. Мне нравится подход MobX лаконичностью, но там нет святого грааля Redux в моем понимании — возможности сделать replay. В идеале, хочу держать в свое сторе как можно более полное состояние приложения, чтобы потом при ошибке у пользователя получить набор экшнов, который к этому привел, и с точностью воспроизвести ошибку. Плюс самому дебажить по диффам между состояними стора и списку экшнов — одно удовольствие.
Я к курсе, что есть mobx-state-tree. Глубоко его не изучал пока что, но собираюсь посидеть и поковырять. Есть опасения насчет производительности в некоторых случаях. Как я понимаю, для того чтобы заставить императивные операции, которые мутируют стейт, возвращать новое иммутабельное состояние, они должны были запилить некий proxy наподобие immer. Есть подозрение, что в некоторых случаях редьюер сделанный руками будет эффективнее, чем иммутабельность через прокси в mobx-state-tree.
А чем не угодили class-transformer вместе с class-validator?
https://github.com/typestack/class-transformer
https://github.com/typestack/class-validator/
А чем не угодили class-transformer вместе с class-validator?
https://github.com/typestack/class-transformer
А можно поинтересоваться, насколько большие вам доводилось делать? Какая была самая большая команда в которой приходилось работать?
Если проект небольшой и пишется в одно лицо, то можно много каскадных красивостей нагородить. При наличии даже двух разработчиков начнется ад.
Как по мне, так основная проблема, которую необходимо решить любому языку, транспилирующемуся в js, — это размер коммьюнити и возможность использовать существующие библиотеки. Тот же Typescript имеет огромное коммьюнити и кучу типов для уже известных js библиотек. Как у этого с котлин?
Самому нравится шарить DTO и валидацию между фронтом и беком. Для этого все пишу на