What's the right place to dispatch a route-dependent load event?

@mikethompson: Ah, that’s a good point, event handlers are supposed to be snappy.

There will be some event which triggers the change in route. And there will be an event handler which handles that event.

@mikethompson: aha, yeah

That event handler would normally issue the necessary HTTP GET

Maybe I'll have to reorganize how I do routing

Having the route handlers far away from views is kind of awkward

Hmm. Not sure it is. Changes to app-db happen in event handlers. https://github.com/Day8/re-frame/wiki/Talking-To-Servers

So sourcing data generally happens in event handlers

I have a multimethod defined to route to views

Back up to the point where there is an "event" ... the user clicks on something. What handles that event?

What (event handler) knows to change route?

This is a land-on-page routing

not necessarily the result of a click

okay so in your "main" ... ... you'll have a initialise-db event fired which takes the route ... and which will initiate the HTTP GET ... and the on-success and on-failure of that GET will themselves dispatch

https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/core.cljs#L30-L34

Except your dispatch will look something like ... (dispatch [:initialise XXXXXX])

where XXXXX is the necessary path info

hm

Will look into it, yeah

https://github.com/Day8/re-frame/wiki/Talking-To-Servers

The patterns are slowly coming together

Yeah, that part I have down now

Very similar to flux data flow

@bpicolo: Similar, except that re-frame dispatches based on event type, whereas Flux apps typically dispatch based on sub-state-tree handlers, each of which picks apart the event type. Or as far as I understand the Flux docs, anyway.

I say “typically” because it is possible to write a Flux app that uses re-frame style event dispatch. It just isn’t the usual pattern.

@mikethompson: just last week I was solving this and found the same solution 😉. Great

I have a noob question

here's an input:

[:input {:type "password"
                     :name "password"
                     :placeholder "Password"
                     :value @password
                     :on-key-press (fn [e]
                                     (let [enter 13]
                                       (if (= enter (.-charCode e))
                                         (when (validate @signup-form-data)
                                           (dispatch [:signup-request]))))
                                     true)
                     :on-change (fn [e]
                                  (dispatch [:update-signup-form :password
                                             (-> e .-target .-value)])
                                  true)}]

No surprise here: it's the password field on my signup form. Is there a better way to get the :on-key-press functionality? I.e., run

(when (validate @signup-form-data) 
   (dispatch [:signup-request]))

Here's the gist: https://gist.github.com/744af627eafb9f4b9889aab1d80c7f48

In any case, I'll pretend like listening for enter is the best way to go.

Are there any best-practices about having "must be logged in" areas of a SPA?

The way I've done it before is: 1. In the app routes, either subscribe to :logged-in? or check for the existance of a key to indicate that fact. 2. For the login/signup/non-secret pages, if :logged-in?, edit the url to put the user at the main screen in the SPA. 3. For the secret pages, if not :logged-in? edit the url to kick the user to signup page.

Any better approaches?

Those are fine; just remember that you also want server-side authorization on all this stuff, just in case someone hacks their way around. Never trust the client code.