Fork me on GitHub
#re-frame
<
2016-10-12
>
spiralganglion00:10:49

Huh. Not sure why that didn't turn up in my search. Thanks x2!

shaun-mahood00:10:33

@ivanreese: I have trouble finding it and I know exactly where it is :)

shaun-mahood00:10:17

Also, my re-frame talk for the conj got accepted :) @mikethompson

josh.freckleton01:10:30

in regards to my question just above here: https://clojurians.slack.com/files/josh.freckleton/F2N5VMQKX/Untitled.clj is the following understanding correct? the order of operations would be 1. pre-append "A" 2. pre-append "X" 3. console.log(v) 4. post-append "Z" 5. post-append "Y" and then the resulting "AX hello ZY" is just lost in this case? if that's the case, is it safe to say that the :before fns are for coeffects exclusively, and :after fns are for effects exclusively? So I couldn't pass "AX hello ZY" around in a pure sense, but it could pop out in some effect?

mikethompson01:10:00

@josh.freckleton > if that's the case, is it safe to say that the :before fns are for coeffects exclusively, and :after fns are for effects exclusively? Yes, that's typically what happens. But there'll be plenty of exceptions to this rule. There are some useful Interceptors which don't change either :effects or :coeffects ... they are there for side effects only ... eg: log to js/console or other destination, or check a schema is still valid, etc.

josh.freckleton03:10:00

@mikethompson hey mike, thanks for all of your work on re-frame! I just got mildly curious about what Day8 is all about, and my google-fu is failing me... who are you guys? is it an ad hoc team? super secret project? startup? now I'm dying to know where all of the genius that is re-frame comes from, because I'm used to seeing this level of project backed by serious businesses, and I can't find anything about Day8!

danielpquinn04:10:41

@mikethompson thanks for the suggestion, I’ll check out async flow fx.

richiardiandrea06:10:26

First time user of the :<- syntax here, good job, reads and works great

mikethompson07:10:44

@richiardiandrea excellent, that's what we like to hear! @josh.freckleton Naturally, I would like to say that Day8 is a stealthy, startup stocked with young Phds, and 10x genius, which is working on a change-the-course-of-the-universe tech. Except, nothing could be further from the truth. We're actually a small group of older, cantankerous programmers who work in a domain where we have the same clients now that we had 20 years ago. The steadiness of our business would give VCs nightmares :-) Technically, we're recent refugees from Flash and all this new-fangled HTML5 stuff just makes our head hurt. The path prior to Flash is long and storied (never get a grey beard started on the old days). Only one of us is a smartypants Phd and the rest barely graduated from kindergarten. Well, except for the new kid who graduated in music, of all things. Bah humbug, didn't happen in my day. And we have a hysterically bad website, that I absolutely refuse to divulge because it is too embarrassing. Your estimation of us would plummet if you ever found it, I assure you. I personally created it in 1999 when blinking text was cool, and it hasn't been touched since. Just realized that makes it almost 20 years old. It was sooooo on the leading edge when I did it. The Smithsonian called the other day to see if they could preserve it (kidding). In summary, I would encourage you to immediately stop seeking us. You'll only be disappointed. :-) The only good news is that we're going to continue to improve re-frame as best we can.

andre09:10:18

@mikethompson I'm working with the flash technology last 17 years 🙂 I held on to it despite the all negative things happening around this technology , while an unknown force was brought me to the clojurians and re-frame, and i feel here like at home, and now i understand why 🙂 but Flex still alive on mobile, and i still working with it on my pet mobile projects, i have my small library for featherssdk (https://github.com/flexsurfer/feathers_mxml_spark) to work like with old friend spark mxml

limist12:10:52

When using re-frame, is there a way to get the "raw" events stream from the browser, and then filter for events of interest? One example is: I'd like to know what links a user ends up clicking, without setting event-handler info on every [:a...] of the page. Thanks in advance for any advice.

plexus13:10:05

@limist not sure, but event bubbling might help. Try setting an on-click on some (grand-)parent of the [:a ...]

plexus13:10:02

that's also an option, sidestepping React and using actual DOM events

plexus14:10:11

Has anyone here had a look at what React is doing with its new "Fiber" algorithm?

plexus14:10:46

That document is the best explanation so far, although it's woefully incomplete. Seems the big thing is to batch and defer flushing updates, so it's possible to "drop frames" when the browser is too busy. It will also allow for prioritization, e.g. an animation needs more regular redrawing than a comment box

plexus14:10:38

I'm not sure how this would impact CLJS. Most wrapper libs already use requestAnimationFrame under the hood, so in that sense it's (once again) JS catching up with CLJS

plexus14:10:28

it's an implementation detail, public APIs should stay the same, but there might be new knobs and dials to take advantage of

limist14:10:34

@plexus Where can i rtfm how to do that please? 🙂 Not finding much in the docs so far...

plexus14:10:24

(defn foo []
  [:div {:on-click #(,,,)}
    [:a ,,,]
    [:a ,,,]])

limist14:10:49

@pepe Thanks for the detailed response! As @plexus pointed out: have you kept React and DOM event handling separate?

pepe14:10:55

@limist only for scrolling

plexus14:10:57

yeah to be honest I have no idea how to help you beyond that, not sure how hard it is to get a reference back to the a, just shooting some suggestions 🙂

pepe14:10:29

I think event.target is always what have been clicked on. But not sure 😉

pepe14:10:01

@limist you are welcome

pepe14:10:15

BTW. today, on @darwin's recommendation I removed the figwheel repl in favor of the Dirac's one and compilation seems smoother. Maybe my feelings only thou. Does anybody tried the same?

si1418:10:21

am I right that subscription like this

(reg-sub
 :by-id
 (fn [db [_ key]]
   {key (get db key)}))
will be pretty efficient, despite depending on the whole DB? The plan is to use it in the following subscriptions to "scope" their updates to a subset of DB

si1418:10:27

my gut feeling is that subscription like

(reg-sub
 :panel/test
 :<- [:by-id :by-id/foo]
 :<- [:by-id :by-id/bar]
 (fn [[foos-by-id bars-by-id] _]
   ...))
will create 2 "actual" subscriptions and will be triggered only if (get db :by-id/foo) or (get db :by-id/bar) returns different value (where "different" is "not identical"). Is it true?

si1419:10:51

@plexus re: React Fiber: it seems that it goes deeper than what we have in CLJS. If I understand that correctly, they are going after virtual DOM diffing between "DOM versions", so projects like re-frame will immediately benefit from that

si1419:10:25

I'm wondering how much the Fiber will degrade throughput. I can see that they mostly care about releasing main thread to maintain decent FPS, but their custom scheduling and call stack will probably hurt perf somehow.

josh.freckleton20:10:39

is this the best way of handling form inputs? it seems inefficient to fire a dispatch every time the input changes:

[:input {:on-change #(re-frame/dispatch [:search-input-entered (-> % .-target .-value)])}]

danielcompton20:10:24

@josh.freckleton the inputs in re-com allow you to fire a dispatch only on-blur

danielcompton20:10:38

probably can do the same for a standard input too

josh.freckleton21:10:03

@danielcompton thanks, that's not a bad idea. i was tempted to avoid needing to keep the inputs' values in the main db atom, but, that'd be dodging the point of re-frame I think. also, I'm happy to make a PR on this feature if I have a little guidance as to what's going on: https://github.com/Day8/re-frame-http-fx/issues/6

josh.freckleton21:10:20

(or help with documentation)

josh.freckleton21:10:33

(and I just tested on-blur, works great)

mikethompson21:10:11

@si14 > will create 2 "actual" subscriptions and will be triggered only if (get db :by-id/foo) or (get db :by-id/bar) returns different value (where "different" is "not identical"). Is it true? Not quite true. Changes will propagate through a signal graph when nodes in that graph compute a "different" value. And "different" is determined by = (it used to be identical? prior to Reagent v0.6.0) . So it is not that (get db :by-id/foo) is not = to the previous value, rather it is that the value computed by nodes like {key (get db key)} is not = to previous. So the propagation of values through the signal graph is "pruned" when a node computes a new value which is = to what it previously computed.

escherize23:10:05

@josh.freckleton if you change :on-change to :on-blur you wont fire a dispatch each time it changes (only when the search box leaves focus..), but you might want to search for a way to debounce the event