@sandbags: what about adding a flag to db, when view changed, set the flag to another value, and when dealing with the 'later' event, check the value of the flag?

Re-frame is about to get a completely new README It is in the develop branch If anyone has time, can they proof read it please, give me a PR of any typo fixes. https://github.com/Day8/re-frame/blob/develop/README.md If you have even more time there's also: https://github.com/Day8/re-frame/blob/develop/docs/CodeWalkthrough.md These docs changes will be announced as part of the 0.9 release (currently in alpha)

'3. An Interceptor Chain is executed in two stages. First a forwards sweep in which all :before functions are called, and then second, a backwards sweep in which the :after functions are called. A context will be threaded through all these calls.' Does this 'backward sweep' mean that all :afters are executed in the reverse order as of the order how all :befores are executed?

Yes

Thanks!

@mikethompson Reading. I see you removed the conveyor belt graph. For what it’s worth, I think that was very illustrative.

Do you means this

app-db  -->  components  -->  Hiccup  -->  Reagent  -->  VDOM  -->  React  -->  DOM
 ^                                                                              |
 |                                                                              v
 handlers <-------------------  events  -----------------------------------------
                          a "conveyor belt" takes events
                          from the DOM to the handlers

Yes.

Hmm. Wondering how to weave that in.

You could re-do it in terms of the six dominoes, since in the end the DOM is used for the user to trigger events again.

Held a Clojure workshop on Saturday. Explaining re-frame quickly people were mostly nodding along, in that “yes, yes, understanding but not yet seeing it” sort of way.

At least most of them.

When they saw the conveyor belt graph, it clicked.

I think I'll need a diagram which better matches the new dominoes narrative

Are you sure the water cycle doesn't do it :-)

As an analogy? Yeah. If someone’s reading the whole thing. But you have to assume that the first encounter of anyone with re-frame will be by quickly scanning through it.

The brain will likely discard the image as local color. The equivalent of an xkcd reference.

I’m curious… why have the basic example with reg-event-fx?

i think because reg-event-fx is the basic function

reg-event-db is modifed reg-event-fx for special cases

when you want to change only db and you don't have coeffects

Hmm. Maybe. But I think most beginners will only care about returnning the new database, not coeffects, and reg-event-db scans much cleaner.

yes , but in future it can be confusing

My take on it would be that anyone who wants to dig into it, can, but that the README should take the most basic approach. Make things as basic as possible for newcomers to the library and approach. Maybe mention the other two reg-event-* and link to them, but not necessarily start there.

Without knowing that reg-event-fx handlers can return and receive something else than just the database, getting and returning a hashmap just reads like noise.

Particularly since the query acts directly on the database.

Just trying to think like a complete newcomer here. Having a reg-event-db handler on dominoes 2/3 would scan cleaner and more cohesive with #4 for a newcomer.

i think in reg-event-fx you should clear understand that you return instructions via data, and this is the key idea, and you should undertand this from the beggining, reg-event-db hides this idea, and this is not good

We have a difference of opinion there. I think presenting less noisy versions to newcomers is good. It makes it easier to get started. When they reach the limitations of the basic wrapper, then they can ask “hey, and how would I do X?” You’re not hiding knowledge, or asking them to treat something as an incantation. You’re just showing them first the option that they’re most likely to use.

@mikethompson Awesome! I'll check them out later today (Swedish time)

@ricardo the explanation to that point talks about how event handlers return a description of effects. That's an important concept if someone is going to get an initial feel for re-frame - I don't want to hide it. I felt the example had to reflect that concept OR I was going to have to unexplain that part. So, while reg-ervent-db is simpler it actually makes the explanation harder. I do understand what you are saying, but I'm comfortable with the decision to show reg-event-fx.

To put that another way: using the more sophisticated reg-event-fx actually makes the code more consistent with the explained concepts.

@mikethompson In that case, I’d add a note on Domino 2 to indicate ”besides the database, the parameter contains [fill in the blanks], which we won’t talk about now but you can read about [on this page here]”.

That way it’s clear why that first parameter is a map instead of just the database.

Hi, hoping someone can let me know if it would be considered bad practice to have a general purpose db subscription handler in the form:

(register-sub
 :db
 (fn [db [_ path]]
   (reaction (get-in @db path))))

(defn my-component []
  (let [bar (subscribe [:db [:foo :bar]])]
    (fn []
      [:p @bar])))

db in sub is not an atom, so you don't need deref

you don't need reaction inside subscription

(defn my-component []
  (let [bar (subscribe [:foo/bar]])]
    (fn []
      [:p @bar])))

(register-sub
:foo/bar
 (fn [db_]
   (get-in db :foo :bar))))

path is not a good idea i think

@andre I was under the impression that the db argument implicitly passed to subscription handlers was a ratom

Also I thought the rule was to "always" return a reaction from subscription handlers, as their job is to return a value that changes over time.

subscrube making reaction around you sub

i didn't know about dynamic subscriptions, so i can't say now about their performance but from code view, it's easier to see all queries in one place, but maybe it depends on specific situation

@andre My understanding was that using Reagent 0.5.1 and Re-frame 0.6.0 the following was true: 1. The db argument implicitly passed to subscription handlers is a ratom 2. Subscription handlers, must return a "stream" of values that change over time (reaction). Your examples seem to suggest that this is not the case.

yes because we have now reagent 0.6.0 and re-frame 0.9.0 (alpha)

Yeah I'm not using those

i came in this beautiful world from re-frame 0.8.0

Yes my version is abit old

So the advice you are giving is relevant to the latest version only?

sorry i don't know anything about older versions

@andre no problem

thanks anyway

@andre It looks like Re-frame 0.8.0 added following change: "With reg-sub, you no longer need to use reaction explicitly". https://github.com/Day8/re-frame/blob/master/CHANGES.md#080--20160819

Oh, thanks for mention that.

I'm just confusing about this.

@cmal I'm just coming to accept that an upgrade to Re-frame 0.8.0 is overdue

although seems that there were quite a lot of breaking changes

I'm reading the updated README by @mikethompson which helps alot: https://github.com/Day8/re-frame/blob/develop/README.md

Yeah, the docs are amazing! Clearly described. I learned a lot about the design patterns.

IMO the best README out there. Love it

and yes learned an absolute load from it

And people here are kind and knowledgeable. I am new here and loves that.

that helps

Just have a component which should trigger the fullscreen on click. I dispatch a :toggleFullscreen handler, and in it, I call the requestFullscreen function of the goog.dom library. But Chrome gives me a warning, that Fullscreen depends on a user gesture. Is their a way to get it done with that way? I thought the user gesture depends on the time from click to the requestfullscreen call.

@mikethompson With subscribe being ok in form-1 components, is the only need for form-2 components when you want to use a local reagent ratom?

(Meaning not that often)

@mf upgrading to 0.8 is fairly painless. Many code bases will handle the upgrade with zero changes (but you might get some deprecation warnings). There are some global renames to do (to avoid deprecation warnings). You really only have work to do if you wrote your own middleware.

@curlyfry yes

@mikethompson Great, thanks!

Hi, I’m new to re-frame, and I’ve been trying to find an example of the best way to handle form management/submission. I saw something about having forms do reagent stuff ‘privately’ then dispatch an event out. So, in say an :on-click, I should first do local validation, then fire off my event??

(defn test-form
  []
  (let [fields (r/atom {})
        error (r/atom nil)]
    ;(print "entering form")
    (fn []
      [:form.ui.form
       (text-input "First Name" :firstname "First Name" fields false)
       (text-input "Surname" :surname "Enter surname" fields true)

       [:div.field
        [:label "TextA"]
        [:textarea]]
       [:button.ui.button
        {:type     :button
         :on-click #(submit-monitoring-form! fields error)}
        "Submit"]])))

submit-monitoring-form

1. The text fields should have on-change which dispatch the newly entered value (which then gets stored in app-db) 2. The "Submit" button's :on-click should also be a dispatch which is handled by making the necessary HTTP request

So view fucntions are as dumb as possible. They just dispatch. All the work is done in the event handlers

ah

interesting

ok, i’m still wrapping my brain around everything is part of the app state lol

thanks will do a bit of refactoring

that raises a style/convention question i guess. So would you conceivably have an event for every field in your app? Presumably namespaced to forms. Or would there be maybe one per form, that’s say takes field/value pairs as data?

I can imagine either way working. I don't write many forms so I don't have first hand knowledge. I might leave it for others to jump in

ok thanks 😉 will play around with it. I’ve the opposite problem, what i’m looking to do is very form ‘heavy'

I can imagine (dispatch [:field-change :first-name "Barry"]) being effective

(def-event-db 
   :field-change 
   (fn [db [_ k v]] 
      (assoc-in db [:fields k] v)))

yeah that looks good, thanks. will just need to see how it ‘scales’ in terms of more forms etc. But gonna start with that 😉 thanks again 🙂

I am trying to move to re-frame-http-fx but I am having trouble with the cljs-ajax part. I have an api call that works with js/fetch and the request string produced by http-xhrio works when pasted into a browser, but still the request fails with a useless error from the server (which I don't control). Any ideas?

@mac: Can you post some sample code?

Also, make sure you are including cljs.ajax in your file or it won’t work.

cljs.ajax included 🙂

(defn ajax-get-meetups []
  (ajax/GET ""
             {:params  {:member_id member-id
                        :key api-key
                        :fields "self"
                        :only "id,name,status,venue.name,self.rsvp.response"}
              :response-format (ajax/json-response-format {:keywords? true})}))

@shaun-mahood Currently using a straight cljs-ajax function for debugging.

@mac: Ok, what have you got for the http-fx translation of that?

@shaun-mahood

Ok, give me a second - I’ll give you a translation that should work to a reg-event-fx

@shaun-mahood The thing is the http string works in the browser, but both the ajax/GET reqyúest and the reg-event-fx equiv fails.

@shaun-mahood Which makes me think it is a header issue or something.

@danielgrosse I suspect its not about the amount of time, but that the call stack can be traced back to a user initiated event, like a button click. Since re-frame processes your dispatched event on nextTick then this boundary is likely causing your warning

@mac: That’s annoying - maybe try changing from the ajax/GET command to ajax-request - I thought it was working with cljs-ajax and just not with re-frame-http-fx, so I ay not be able to help much.

@shaun-mahood Tried that already 😞

@shaun-mahood Great conj talk btw.

Thanks!

@mac: Maybe check in #clojurescript? Can you see any difference in the headers between working/not working in devtools?

@mac: Oh, I just looked there - the other option could be to get it working with the google Closure version, then make your own fx handler (which shouldn’t be too hard)

@shaun-mahood The js/fetch version works no problem. Is there some guidance on how to do a custom fx handler?

@shaun-mahood Found this: https://github.com/Day8/re-frame/wiki/Effectful-Event-Handlers

@mac: Yeah, it’s actually pretty easy (once you’ve figured it out, at least 🙂 ) - docs are the best place to start https://github.com/Day8/re-frame/blob/master/docs/Effects.md - and I’ve got a pretty simple one at https://github.com/smahood/whats-up-doc/blob/master/src/whats_up_doc/github_fx.cljs#L348 if you want to see how it works, it is using :http-xhrio but it might give you an idea of how one could work on top of what the docs have/

@mac: Read the one you linked and the one I linked and you should be good 🙂

@shaun-mahood If the ajax call only fetches data is coeffects then the way to go?

@mac: I'm not sure, I've thought of the ajax fetch as an effect and the return as another effect, but it would be easy enough to get it working as an effect and then move it to a coeffect and see what happens - it's something I've been thinking about the past few days but I haven't had a chance to test it.