Начиная с этих двух обработчиков, которые заботятся о получении текущей информации о пользователе:Как заставить обработчики запускаться последовательно в повторном кадре?
(re-frame/register-handler
:got-user
(fn [db [_ user]]
(assoc db :user user)))
(re-frame/register-handler
:get-user
(fn [db [_]]
(ajax/GET "/user"
{:handler #(re-frame/dispatch [:got-user %1])})
db))
на одной странице, я хочу, чтобы отобразить список друзей, но проблема заключается в том, что это зависит от того, пользователь является неправдоподобным первым :
(re-frame/register-handler
:get-friends
(fn [db [_]]
(when (nil? (:user db))
(re-frame/dispatch [:get-user]))
; Here's the problem, as I need to way for get-users and got-users to run.
(ajax/GET (str "https://stackoverflow.com/users/" (get-in db [:user :id]))
{:handler #(re-frame/dispatch [:got-friends %1])})
db))
Как я должен структурировать этот код?
Я только что узнал о повторной кадре, но вот идея: почему бы не отправить '[: get-user {: next: get-user-friends}]' с каким-то стилем продолжения прохождения, где ': next' - это событие для отправки, когда мы получили пользователя? обработчик для ': got-user' отправил следующее событие. Поэтому ': get-friends' разделяется на две части:': get-friends' (при необходимости получите пользователя) и ': get-user-friends' (получить друзей для известного пользователя). – coredump
@coredump да, я играл с этим, но продолжения трудно поддерживать и отлаживать, и передача ключевого слова-как-продолжение неизбежно будет недостаточной в будущем по моему скромному мнению. – Pablo
Я не понимаю, почему было бы трудно поддерживать и отлаживать. Мне кажется, что вы уже используете подход, управляемый событиями, с обратными вызовами (обработчиками). События обмена IMHO прекрасно сочетаются с существующей структурой. Если я правильно понимаю, вы можете передать произвольные аргументы обработчикам для ваших будущих потребностей, а не только ключевые слова. Приветствия. – coredump