@leov я когда решал похожуя задачу с менюшкой решал (надо было на в зависимости от выбранного подменю выставлять класс “active” на рутовом элементе) переделывал 3 раза

первый раз делал так: обычно ui route выглядит так: /root1/child1, /root1/child2 и т.д. . Если я находился в child1, я брал полный route и отрезал весь хвост кроме до /root1 и потом в router’е делал resolve на обрубок урла

во второй раз невод выглядел так: я сделал мапу с метаданными, когда на любой раут, который является подменюшкой был специальный ключик “root-key”, типа {:child1 {:root-menu-key :root1} :child2 {:root-menu-key :root2}}

(была еще собственная имплементация раутера чтобы туда можно было метаданные набрасывать, но я ее убрал)

сейчас подход такой: есть отдельное определение раутов и есть sitemap, который “связывает” независимые рауты произвольными отношениями

в этом случае (подразумеваем, что router выставлят при навигации ключик route-name в что-то типа ::ui-asn-pool-list можно написать функции, которые берут на вход sitemap и ключик текущего раута и по структуре sitemap определяют инфорацию для менюшек, бредкрамбов, тайтлов и т.д.

у меня вообще сейчас вся архитектура приложения сводится к тому, что есть “статический state” (это определение раутов, форм, связей между разными плюшками в виде мап) и “динамический state” (текущий раут, значения форм в поле видимости, данные с сервера, нужные для этого view и т.д.)

в итоге контроллеры превратились в subscription-ы (использую re-frame) которые берут мапу статического стейта, значения из динамического стейта и на основе этих двух входные данных выводят значения для того, что должно рисоваться (какую вьюху рендерить, какие менюхи, как breadcrumb’ы считать и т.д.)

не претендую на то, что это хоть какой best practice, просто на данный момент (после 4х больших переписываний) это рабочая версия. Мне с UI route’ами надо ассоциировать еще кучу всего (типа какие API call’ы должны быть сделаны при переходе на данный раут, какие формы надо инициализировать и т.д.) поэтому я решил заложиться на расширяемую мапу метаданных, потому что туда можно всегда ключей накидать

Ну, что никто не угадал https://twitter.com/mtnygard/status/821097080248737796, похоже.

Он написал про это: https://www.eventbrite.fr/e/billets-architecture-without-an-end-state-by-michael-nygard-cognitect-inc-29373848973

Хотя может ещё и что-нибудь более интересное напишет завтра 🙂

http://blog.cognitect.com/blog/2017/1/30/unlocking-hidden-value-in-your-data-1

https://github.com/cognitect-labs/vase

что-то этих когнитектовцев не поймешь, один Арахне пилит, другой Вазу, нет бы все вмести сели и end-to-end решение сделали полноценное

Закомплекченное?

Getting started "Как поставить вазу на пьедестал".

Вот и стало понятно, зачем Cognitect сделал Client API в Datomic.

@misha Твоя догадка была ближе всего к истине.

нее, я же прогнозировал "что-то чёткое"

кто-нибудь встречался с тем что lein игнорирует :prep-tasks и ничего из них не исполняет?

@misha А что, ваза размытая?

ну она для пьедестала, мимо меня пока что

Что-то как-то неприкольно. В этом месте даже протокол не вкорячили.

Оказывается, Nygård клёвую книжку написал десять лет назад, "Release it".

А теперь какие-то вазы лепит

релиз ит - четенькая книга

привет, я тут стал писать проект на cljs. И почти после каждой итерации рефакторинга, если я допускаю ошибку в хроме я вижу что то вроде GET net::ERR_CONTENT_LENGTH_MISMATCH. И все не ответа ни привета, что сломалось где непонятно

что я делаю не так?

фигвил не коннектиться, трейса нет. Хоть вешайся

проект то тривиальный не больше 1k LOC

т.е. при любой ошибке такое?

ну не при любой, но часто достаточно

а все так мучаются чтоли?

первый раз вижу, у меня фигвил сессия месяцами висит

хм

попробуй в firefox 🙂

да, файрфокс ок и новая инсталляция хрома-canary тоже ок

а нет, тоже самое

а джанга виновата! сорри, зря бочку катил на cljs. весь день к черту