Fork me on GitHub
#re-frame
<
2016-04-01
>
bpicolo02:04:27

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

cky02:04:09

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

mikethompson02:04:36

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

mikethompson02:04:55

That event handler would normally issue the necessary HTTP GET

bpicolo02:04:04

Maybe I'll have to reorganize how I do routing

bpicolo02:04:17

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

mikethompson02:04:02

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

mikethompson02:04:21

So sourcing data generally happens in event handlers

bpicolo02:04:45

I have a multimethod defined to route to views

mikethompson02:04:48

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

mikethompson02:04:54

What (event handler) knows to change route?

bpicolo02:04:06

This is a land-on-page routing

bpicolo02:04:13

not necessarily the result of a click

mikethompson02:04:46

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

mikethompson02:04:58

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

mikethompson02:04:09

where XXXXX is the necessary path info

bpicolo02:04:56

Will look into it, yeah

bpicolo02:04:05

The patterns are slowly coming together

bpicolo02:04:22

Yeah, that part I have down now simple_smile

bpicolo02:04:26

Very similar to flux data flow

cky03:04:00

@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.

cky03:04:38

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.

pepe07:04:50

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

escherize10:04:34

I have a noob question

escherize10:04:52

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)}]

escherize10:04:21

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]))
whenever enter is hit within the form. When I wrapped it in a form (as follows), enter was causing me to post query params, instead of running my cljs - even though i have :on-submit (fn [e] (.preventDefault e)) on the form!

escherize14:04:58

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

escherize14:04:29

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

escherize14:04:35

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.

escherize14:04:49

Any better approaches?

amacdougall16:04:53

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.