EP
я раньше did-mount страдал, потом мне объяснили что это антипатерн и айайай
Size: a a a
2021 March 16
EP
лучше все же роутер и нормальный re-frame
AC
погляди kee-frame
контролер берет данные из урла, кидает эвент, данные грузишь.
все от роутера.
данные по умолчанию в дб все равно где-то нужно брать, можно захатчить конфиг в виде переменной в js и генерить со страницы, например. Если уж сильно нужно до загрузки взять что-то. Но там обычно всякую конфигурацию передают. Данные для страниц уже качай нормально по ресту.
контролер берет данные из урла, кидает эвент, данные грузишь.
все от роутера.
данные по умолчанию в дб все равно где-то нужно брать, можно захатчить конфиг в виде переменной в js и генерить со страницы, например. Если уж сильно нужно до загрузки взять что-то. Но там обычно всякую конфигурацию передают. Данные для страниц уже качай нормально по ресту.
мы так делали единственное неудобство в том что есть вьюхи, которые много где используются и им надо одни и те же данные подтягивать
AC
по урлам такое не оч удобно раскладывать
AC
Т.е. у нас есть превью некой сущности, которое мы втыкаем везде где встречается эта сущность.
AG
я раньше did-mount страдал, потом мне объяснили что это антипатерн и айайай
мне для поиграться сойдет дид моунт спасибо
EP
мы так делали единственное неудобство в том что есть вьюхи, которые много где используются и им надо одни и те же данные подтягивать
ну да вечная борьба с дублированием логики. каждый решает это сам. но контрооллер - это лишь триггер на урл. можно сразу несколько таких триггеров запускать и пусть какие данные грузятся в разных вьюхах одинаково.
еще неудобство - когда вьюхи вложенные и нужно что-то общее использовать. нужно загрузить одни данные , а потом грузить другие данные уже основываясь на этих подгруженных данных. тут либо всякие контексты и очереди велосипедить либо смотреть уже на graphql....
еще неудобство - когда вьюхи вложенные и нужно что-то общее использовать. нужно загрузить одни данные , а потом грузить другие данные уже основываясь на этих подгруженных данных. тут либо всякие контексты и очереди велосипедить либо смотреть уже на graphql....
AC
ну да вечная борьба с дублированием логики. каждый решает это сам. но контрооллер - это лишь триггер на урл. можно сразу несколько таких триггеров запускать и пусть какие данные грузятся в разных вьюхах одинаково.
еще неудобство - когда вьюхи вложенные и нужно что-то общее использовать. нужно загрузить одни данные , а потом грузить другие данные уже основываясь на этих подгруженных данных. тут либо всякие контексты и очереди велосипедить либо смотреть уже на graphql....
еще неудобство - когда вьюхи вложенные и нужно что-то общее использовать. нужно загрузить одни данные , а потом грузить другие данные уже основываясь на этих подгруженных данных. тут либо всякие контексты и очереди велосипедить либо смотреть уже на graphql....
по-хорошему бы иметь некий per-view механизм чтобы роутер сам собирал кому что надо
AC
но не понятно как это сделать
AC
типа onViewDidMount чтобы каждая вьюха куда-то складывала свои хотелки по запросам
AC
а потом роутер это как-то собирал и отправлял
AC
в принципе это достижимо - у реагента есть калбек на конец рендеринга
D
fulcro не так?
AC
fulcro не так?
там я так понял так, но за это ты не можешь просто вьюху отрендерить - тебе надо все вьюхи задавать через какие-то мапы
AC
(defsc Root [this {:ui/keys [number]}]
{:query [:ui/number]
:initial-state {:ui/number 0}}
(dom/div
(dom/h4 "This is an example.")
(dom/button {:onClick #(comp/transact! this [(bump-number {})])}
"You've clicked this button " number " times.”)))AC
те это уже не реагент вью обычный а какая-то опердень которую специально надо процессить
AC
как-то при рендеринге надо где-то все это складывать потом читать
AC
короче надо будет свой hiccup писать который будет собирать инфу с вьюх
KR
Короч тебе насоветовали хороших продакшн вариантов, но тебя скорей всего устроит делать запрос на каждый маунт :)
KR
как-то при рендеринге надо где-то все это складывать потом читать
У вас проблем с инвалидацией кеша нет?