This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-10
Channels
- # beginners (61)
- # boot (264)
- # cider (125)
- # cljs-dev (3)
- # clojure (118)
- # clojure-gamedev (3)
- # clojure-greece (1)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-poland (3)
- # clojure-russia (38)
- # clojure-spain (2)
- # clojure-spec (17)
- # clojure-taiwan (1)
- # clojure-uk (42)
- # clojurescript (118)
- # clojutre (5)
- # cursive (24)
- # datomic (22)
- # emacs (3)
- # events (2)
- # figwheel (19)
- # funcool (1)
- # jobs-discuss (224)
- # jobs-rus (1)
- # klipse (14)
- # luminus (1)
- # lumo (49)
- # off-topic (51)
- # om (34)
- # pedestal (1)
- # perun (1)
- # planck (93)
- # powderkeg (1)
- # re-frame (15)
- # ring (4)
- # rum (9)
- # slack-help (3)
- # spacemacs (2)
- # specter (13)
- # uncomplicate (1)
- # unrepl (22)
- # untangled (10)
- # yada (36)
я как-то абстрагировал re-frame от реагента, мы его с омом старым использовали https://github.com/condense/ampere — порт, правда немного отстал от апстрима за это время, ко-эффектов и прочего нет
но вот я сейчас собираюсь писать приложение на cljs и брать re-frame или другой redux-like не хочется =(
по опыту использования ре-фрейма и самого редакса в больших приложениях, компонентность надломана немного
всё, что реально получается переиспользовать — это много разных мелких хелперов, а цельные компоненты пропростают в приложение
уже который день не могу развеять печаль, посмотрел на всё, что перечислено здесь https://staltz.com/unidirectional-user-interface-architectures.html, и на классический MVC посмотрел снова, и не знаю, какую архитектуру заложить в приложение
дак а что конкретно не нравится в redux-like? То что большие компоненты не переиспользовать, дак на то они и большие это ок
иллюзии того, что большие UI-куски можно переиспользовать, нет. проблема скорее в том, что много мест, которые хотелось бы вынести либо в какие-то отдельные поведения/миксины, либо инкапсулировать в компоненте, часто дублируются в actions & reducers с привязкой к конкретным типам действий и адресам в стейте. higher-order actions & reducers иногда помогают, но чаще выглядят костылём, уж лучше ввести локальный стейт было бы.
вот здесь ещё неплохие примеры и постановка проблемы (хотя и недостаточно подробная, с первого взгляда кажется "ну и чо, два одинаковы компонента легко зафигачить, сто раз делали") https://github.com/slorber/scalable-frontend-with-elm-or-redux
>и адресам в стейте не пробовали нормализовать стейт? Чтоб не было как-раз дикой вложенности. Я помню ом-некст очень хорошо описывает эту тему да и нормализует из коробки по сути
насчёт нормализации, так с бизнес-данными вроде бы и нет проблемы, они прекрасно нормализуются и потом контейнерами отдаются компонентам, с данными из домена самого приложения хуже
>с данными из домена самого приложения хуже хм, так то разницы же не должно быть, что данные нормализуются, что внутренние данные приложения. Что-нить типа
{:data {:account/by-id {:1 {:name “John”}}
:2 {:name "Frank"}}}
:ui {:chart/by-name {:profit {:y-name "Money" :x-name "Time" ...}}}}
рекомендую посмотреть еще на http://witheve.com. Очень зачетная тема
да, Крис продолжает жечь 😃 спасибо за напоминание, перечитаю и про Eve в рамках этого мини-исследования
дада, они поначалу рекламировали Eve как поделку для тех кто программировать не умеет, но в итоге если копнуть то очень годно
я тут уже даже на smalltalk смотреть начал, к слову очень сильно напоминает многое из того, что я вижу в функциональном мире, только завёрнутое в объекты вместо неймспейсов + контрактов данных ))))
Всем привет. А Om Next правда начинает набирать обороты? То есть они добились того чего хотели? Где-то полгода назад всё было только непонятно
т.е. я понимал что есть например поддержка кэширования браузером запросов
а всё остальное, особенно "парсер" не было понятно вообще
блин, тоже хотел скинуть, причем мне это прислали люди которые к clojure вообще отношения не имеют)
ктот спрашивал про java9, понравилось AOT в контексте кложи может быть актуально http://openjdk.java.net/jeps/295 и еще понравились коллекции с человеч лицом Map.of(k1, v1, k2, v2, k3, v3)
http://openjdk.java.net/jeps/269
@ul можно поподробней, в чем проблема с компонентами в re-frame? у нас все приложение попилено на компоненты, связываются через subscription’ы, каждый компонент, которому нужен свой state - хранит его в базе по своему уникальному пути
(shameless plug) у нас есть DataTable (https://kishanov.github.io/re-frame-datatable/), он не зависит от pagination и от search - это отдельные компоненты, которые друг другу передают subscription
т.е. чтобы сделать searchable paginable table надо завести компонент search который подписывается на сырые данные и применяет search, datatable и pagination подписываются на subscription который высовывает search после применения
любой компонент, который должен отобразить какие-то данные с сервера может быть в него завернут и он будет показывать loading spinner/error/component в зависимости от состояния данных
вот из текущего приложения как рендерятся компоненты - по принципу матрешки
[container-views/data-from-server-view-container
[blueprints-views/scaffolding-container
[container-views/nav-menu-container
[blueprints-views/blueprint-details-physical-view]
::routes/details]]
[::routes/physical ::routes/details]]
Я почти год занимаюсь clojure. И весь этот год я испытывал отвращение и не понимал идею stuartsierra/component. После того, как я сделал 2 велосипеда, почитал книжки и статьи, внимательно посмотрел презетацию, я могу сказать, что понял его идею и этой библиотекой можно пользоваться. Если кто-то не понимает сomponent, то обращайтесь - расскажу то, что понял я.
@kuzmin_m А может я что то упускаю? Что именно “щелкнуло” за этот год? Для меня это место куда можно накидать вотчеров, сервисы что то подобное и потом релодить по хоткею в IDE
это собственно на первой странице и написано https://github.com/danielsz/system