MG
Redux за вычетом boilerplate, да.
Size: a a a
2019 May 22
АГ
а тебе чем нравится / не нравится?
не нравится тем что слишком сложно. я чувствую себя как на картинке где functions, functions, functions. в том плане что я не понимаю зачем вот это всё event dispatch, event handling, effect handling, query, view, dom. я не понимаю почему нельзя всё это совместить просто в функции, которые меняют топлевелные ratom'ы. ratom'ы лежат в топлевеле неймспейсов, которые отвечают за какие-то части клиент-специфичной логики, но большая часть стейта и логики на сервере за rest api, и для того чтобы это всё не дублировать и не оборачивать на клиенте я некоторое время назад придумал https://github.com/alesguzik/live-components
АГ
АГ
там есть ещё в примерах counter, там не настолько в тупую в лоб сделано взаимодействие с rest и нормально сделан роутинг через bidi вместо прямых урлов
A
не нравится тем что слишком сложно. я чувствую себя как на картинке где functions, functions, functions. в том плане что я не понимаю зачем вот это всё event dispatch, event handling, effect handling, query, view, dom. я не понимаю почему нельзя всё это совместить просто в функции, которые меняют топлевелные ratom'ы. ratom'ы лежат в топлевеле неймспейсов, которые отвечают за какие-то части клиент-специфичной логики, но большая часть стейта и логики на сервере за rest api, и для того чтобы это всё не дублировать и не оборачивать на клиенте я некоторое время назад придумал https://github.com/alesguzik/live-components
по аналогии с редаксом - твои редьюсеры и экшены
event dispatch
event handling
effect handling
query - твой мап ту стейт
event dispatch
event handling
effect handling
query - твой мап ту стейт
АГ
я точно так же не понимаю зачем redux)
A
а большие приложения делал?)
АГ
мы пару лет делали приложение где было довольно много разных entity, были загрузки файлов, были бесконечно подгружаемые списки, были разные пользователи, был шаринг и всякое такое. большие это по каким меркам? типа "чем тяжелее самолёт тем лучше"?
A
мы пару лет делали приложение где было довольно много разных entity, были загрузки файлов, были бесконечно подгружаемые списки, были разные пользователи, был шаринг и всякое такое. большие это по каким меркам? типа "чем тяжелее самолёт тем лучше"?
а страниц по урлам сколько было?
v
это троллинг уже!
A
> гыгы, открыл для себя pyrsistent
он местами оч не быстрый
он местами оч не быстрый
АГ
11 типов страниц, каждая в отдельном неймспейсе. общий для разных страниц стейт хранился в отдельных неймспейсах с функциями для работы с ним (ещё 10 неймспейсов). ещё 37 неймспейсов с разными ui-компонентами и вспомогательными штуками
АГ
это фронтенд
АГ
бэкенд 47 неймспейсов не включая cljc
АГ
ещё 14 cljc
A
11 типов страниц, каждая в отдельном неймспейсе. общий для разных страниц стейт хранился в отдельных неймспейсах с функциями для работы с ним (ещё 10 неймспейсов). ещё 37 неймспейсов с разными ui-компонентами и вспомогательными штуками
то есть тебя устраивает твой вариант реализации?)
АГ
а что не так?)
АГ
да, меня устраивает. очень удобно находить какой код где, очень удобно из репла дёргать ивенты (просто функции вызываешь), очень удобно смотреть стейт (он в топлевеле), не нужно поддерживать кэш данных с сервера в каком-то сторедже и пытаться его обновлять в соответствии с результатами rest-запросов, и т.д.
АГ
компилятор проверяет что мои ивенты имеют смысл (в отличие от произвольных кейвордов)