Fork me on GitHub
#re-frame
<
2016-06-01
>
rui.yang11:06:02

hi, I am still new to reframe, wonder if there is some template to start. I am particularly interested how to handle a usual login scenario, which include: 1. show login screen, 2. do the login, if success, show dashboard, 3, if fail keep on login page, 4. if go to dashboard directly by url, then clean auth cookie and redirect to login page.

rui.yang11:06:46

trying to figure out what is the best way of doing all these using single state atom

rui.yang11:06:43

in my current setup, I used secretary for routing

Jacobin13:06:38

I have a component

(defn input-component []
  (let [input (re-frame/subscribe [:input])]
    (fn []
      [:div
        "Hello : " @input ". "
        [:div [:input {:type "text" :on-change #(re-frame/dispatch [:input-changed])}]]
      ])))

Jacobin13:06:53

put the input-changed handler just gets nil

mccraigmccraig13:06:32

@ashconnor: you aren't including the input value in your dispatch - try something like #(re-frame/dispatch [:input-changed (-> % .-target .-value)])

Jacobin13:06:19

got it working thanks

fasiha14:06:41

What @rui.yang asks for might actually be really useful. I'll be needing to add auth to my re-frame app soon and am probably procrastinating because I have no idea how that'll work with re-frame

mccraigmccraig14:06:21

i'm sure a template would be useful @fasiha @rui.yang ... meanwhile a very simple scheme is to store your user-credentials (or lack thereof) in app-db, have a sub which yields those creds and a form-2 component which has hiccup something like (if @creds-sub [authenticated-view] [unauthenticated-view]) ... after successful login a handler stores the creds in app-db, logout (or whenever you get a 401) removes them

escherize14:06:51

I'm not sure if this will help you guys, but this is how I've decided to differentiate logged in routes vs logged out routes:

Jacobin15:06:24

Can someone take me through the [:input-changed (-> % .-target .-value)]? It works but I don’t know exactly what (-> % .-target .-value) is doing

Jacobin15:06:57

.-target and .-value I assume comes from the DOM event

Jacobin16:06:23

not sure why they are prepended with dots and the arrow and percentage

mccraigmccraig16:06:19

@ashconnor: it is syntax sugar for (fn [e] (-> e .-target .-value)) which defines a function with a single parameter e and returns the value field of the target field of e

caio16:06:55

1. % is part of syntactic sugar for anonymous functions. inside the #(..), it’s a reference to the args passed to the function. 2. -> is the thread-first macro, see this: https://clojuredocs.org/clojure.core/-%3E 3. .- is an interop with javascript. you’re getting an attribute from an object

mccraigmccraig16:06:21

the -> is a threading macro, which rewrites (-> e .-target .-value) as (.-value (.-target e))

caio16:06:23

#(-> % .-target .-value) is the same as function (x) { x.target.value }

Jacobin16:06:01

thanks @mccraigmccraig @caio - that makes sense

Jacobin16:06:39

so I could replace the macro with [:input-changed (fn [e] ((.-value (.-target e))))] : edit maybe [:input-changed (fn [e] (.-value (.-target e)))]

caio16:06:43

from what you’ve sent, it looks like the whole line is inside an anonymous function, isn’t it?

Jacobin16:06:54

yeah that’s correct

caio16:06:27

idk if it was a typo or what, but the correct “translation” to that first line you sent would be [:input-changed (.-value (.-target %))]

caio16:06:59

[:input-changed (fn [e] (.-value (.-target e)))] would be right if the original was [:input-changed #(-> % .-target .-value)] (notice the #)

Jacobin16:06:07

thanks - because right now with the code I posted just above - it returns a javascript function to the input

rui.yang23:06:19

@escherize thanks for sharing, will digger into it.

escherize23:06:11

If you have any questions feel free @rui.yang