Fork me on GitHub
#re-frame
<
2018-10-01
>
genekim20:10:45

Just closing the loop on a question I asked 7 months ago, and the surprising resolution — I had asked about why one event handler was so ugly, and @mikethompson and @joelsanchez provided some wonderful and fantastic feedback on how to clean it up. I put “clean up messy event handler” on my TODO list 7 months ago, with the intent fo fix it “someday.” Over the weekend, I was trying to figure out why in my app the ESC key was working in one context, and not in another context — and ran into that messy event handler again. Armed with @mikethompson’s advice to try moving logic into the view, and force each event to be an expression of user-intent, I jumped in… 1. I was amazed at how safe it was to refactor, moving chunks of code into the view. Figwheel (hi @bhauman! :) is so amazing at giving fast and constant feedback, and I was a little incredulous that I moved 30 lines of code that I no longer fully understood into the view without a single problem. 2. I was doubly amazed to then discover that once I moved the logic into the view, there was nothing left over in the event, and I could delete the remaining 15 lines in the event handler. 3. And I was amazed yet again when I found the three lines of code to handle ESC key logic could just be copied into the other view context. Problem fixed! 4. I then opened up my “clean up messy event handler” TODO, and discovered that there was nothing to clean up — it had been entirely deleted. I’m amazed at how re-frame obviously forces you into a wonderfully clean way of working. Thanks again, all! (post from 7 months ago posted below to jog your memory.) >>> From Mike Thompson: @joelsanchez @genekim here’s an alternative point of view on that event handler containing the cond ... I would argue that the event itself is a problem (not the handler) ... there should be 3 events, not one. Events should capture “user intent” but, instead, that event is currently capturing UI interaction. Looks like there is three kinds of user intent “:search”, “:abandon-search”, “:clear-search”. So, perhaps it is the view code which should be doing the cond and selecting which event to dispatch. (edited) >>>

(def enter-key 13)
(def escape-key 27)
(def slash-key 191)

(re-frame/reg-event-fx
 ::searchbox-key-down
 [check-spec-interceptor]
 (fn [{{:keys [left-pane-view filter-list-string]} :db} [_ {:keys [keycode list-subset]}]]
   {:dispatch-n
    (condp = keycode
      enter-key
      [(handle-filter-enter list-subset)]

      escape-key
      [[::unfocus-searchbox]
       (when (contains? #{:leftpane-select-board
                          :leftpane-select-list
                          :leftpane-moving-board
                          :leftpane-moving-list
                          :leftpane-create-new-list}
                        left-pane-view)
         [::left-pane-select-list])]

      slash-key
      (when (empty? filter-list-string)
        [[::save-and-clear-searchbox]
         [::left-pane-move-select-board]])

      :default [])}))

🎉 4
genekim20:10:20

@mikethompson PS: there’s a wonderful talk from ClojuTRE 2018 that has a shout-out to re-frame from Jarppe Länsiö. At the 24m mark. I echo his sentiments: after starting to use re-frame, the problems I’ve had for decades have mostly disappeared. It’s an almost uncanny feeling, and a wonderful testament to re-frame! Kudos! https://www.youtube.com/watch?v=WtdegIqQbrg

👏 28
lwhorton16:10:40

that was an awesome talk. just saw it last week. i wish everyone could manifest that amount of energy.

dfcarpenter22:10:12

I'm trying to figure out how to create a subscription to a single item from list of items which is pulled in from an api. Basically I navigate to a "detail" view which is just a "detail-id" key with a value of the id in re-frame and then I want to have to new view/panel load with the right item pulled out of the re-frame db list based on the id.