@mikethompson: Ok thanks, I’m going to have to think about this a bit more in the context of things I’ve built.

@mikethompson - how rigidly do you stick to the stock file structure for each "panel"? I find cljs programmers quite keen to stuff as much as possible into single files rather than splitting them out

Personally I don't like files longer than 100 -150 lines or so

We are pretty rigid about it. When I show up in a directory, and I see db.cljs or events.cljs I already know what's in them. I know where to look.

If I'm new to the app, I go sniffing in db.cljs first, getting a feel for the Schema (the information model), from there i can venture out.

hmm - would folders with matching name be incredibly hideous for say, views or events?

i.e views/foo.cljs views/bar/cljs

Or would you then be approaching a new panel?

@am-a_metail we do src/app_name/panel1/events.cljs, src/app_name/panel1/db.cljs, src/app_name/panel2/events.cljs, e.t.c.

what's the best way to dispatch the value of a text box on blur?

i've found a way. not sure if its great

once thing conceptually strange to me is the re-frame tutorial makes quite a bit out of reaction but it is nowhere in the template and doesn't seem to be in core any longer

@dpsutton Was it something like

(defn target-value [event]
  (-> event .-target .-value))

[:textarea {:on-blur #(dispatch [:blur-text (target-value %)])}]

yeah basically

I'd say that's "how you do it"

fair enough

do you ever use reaction? The docs seem to make a big deal out of it whereas it seems nowhere exposed to the user

@dpsutton I think the reaction stuff in the tutorial is partly because it emphasizes how re-frame is implemented

ah ok.

made me nervous i wasn't doing it correctly

Pre 0.8.0 you have to use reaction in your subscriptions, but not anymore thanks to reg-sub

@dpsutton: In v0.8.0, reactions are built right into your reg-sub calls - they're still there under the hood, you just don't have to write them manually.

ah ok.

Part of it is a factor of the docs being written when it was still required and not being updated perfectly, but the concept is still pretty fundamental to how it all works.

I was reading this and making sure i understood its implications and couldn't figure out who to do it and what I should take form it

As now it seems reg-sub takes an subscription and a function which dictates what value is watched

@dpsutton: if you compare reg-sub with reg-sub-raw you can see the difference in how they work - reg-sub-raw is the same as the old version.

ah, and reaction is a reagent concept

i was looking in reframe for that

one last question for the night. What's the best way to have one event trigger 4 others?

a single dispatch then causes 4 things?

@dpsutton: Can you give an example of what you’re trying to do?

Do you dispatch from reg-event-fx?

I can

Currently, when you click on a button, it hits an api call for an invoice

but I actually need it to hit 4

can i have it populate 4 tables from four sources with a single dispatch?

or am i thinking about it wrong?

But i need 4 of those actually

and "you're doing it wrong" is a totally acceptable answer

Hmm… let me think about it for a second - you’re doing it wrong doesn’t work well if you can’t change the API.

I'd love if i could create a stream of urls along with where in the app-db to put it

but i'm not sure where in the application to treat things like streams