This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (54)
- # announcements (1)
- # beginners (145)
- # boot (122)
- # cider (10)
- # cljs-dev (25)
- # cljsrn (20)
- # clojure (173)
- # clojure-art (4)
- # clojure-austria (1)
- # clojure-berlin (3)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-russia (117)
- # clojure-switzerland (1)
- # clojure-uk (3)
- # clojurebridge (6)
- # clojurecup (36)
- # clojurescript (218)
- # clojurex (1)
- # core-typed (17)
- # cursive (23)
- # data-science (1)
- # datavis (2)
- # datomic (28)
- # emacs (3)
- # flambo (1)
- # hoplon (28)
- # ldnclj (19)
- # lein-figwheel (2)
- # leiningen (1)
- # luminus (1)
- # off-topic (1)
- # om (158)
- # portland-or (1)
- # re-frame (72)
- # reagent (48)
- # remote-jobs (1)
- # slack-help (7)
What toolchain or hosting option should we use for Reagent's docs: https://github.com/reagent-project/reagent/issues/209
Could you add to ticket, so nothing gets lost and all conversations are contained.
@mikethompson: I was half expecting nodejs to crash, but not to have a wrong implementation. Are you sure that while waiting for a timeout, events should be processed?
Ah, sorry, no. i got distracted by one of those idiot conversations one has every now and again on the internet
The clojurescript core.async implementation is here: https://github.com/clojure/core.async/tree/master/src/main/clojure/cljs/core/async
Yeah, and it looks like the dispatch releated code uses
(go-loop  (timeout event-timeout) (if (> (- (.getTime (js/Date.)) start-time) total-timeout) (do (println "Done pre-rendering at " (- (.getTime (js/Date.)) start-time)) (.send res (reagent/render-to-string [views/main-panel]))) (do (println "Not done yet " (- (.getTime (js/Date.)) start-time)) (router/-run-queue router/event-queue) (recur))))
@pupeno, how do you watch these? I'm logged in but it says > Because of its privacy settings, this video cannot be played here.
@dm3: i logged in and am viewing... didn't have to do anything special - are there perhaps geo-restrictions or something ?
Dear all, I've written up a page on using stateful JS components from within Reagent/Re-frame: https://github.com/Day8/re-frame/wiki/Using-Stateful-JS-Components It is a very green document. Almost certainly has typos. Any feedback about content appreciated
@mikethompson: I think the doc is useful. Afaik this stuff is only documented by example in the Reagent cookbook.
On a related note, what does seem a bit lacking in Reagent docs generally is a discussion of
props and how to use them, how they differ from just normal args passed to a subcomponent etc.
for example this page https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components explains the forms, but does not mention how you would pass args to a form-3 such that *-mount fns could use them, whether props or otherwise.
Hey I asked this over on #C03S1L9DN, when I didnt realise there is a #ref-frame channel
I’ve been looking at re-frame for a SPA. I really like the event driven pipeline, but would prefer to just use type-1 reagent components, instead of type-2 and the reactions etc. Is there a really good reason I couldnt just use the type-1 components?
this page explains it pretty well: https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components in short, if you need setup, local state etc then you need more than form-1
The question you would have to ask yourself is how would you re-render when state changes? Sure, you can just use form-1 components, but at some point you'll have to react to state changes
@jstew: but cant you already do that by just using normal reagent? ie passing the atom around which registers the components. I guess what I want to know is the reasoning behind using the form-2 over the form-1, and the tradeoffs.
I get the local state part of form-2. But I dont think I undestand the full reasons behind why re-frame suggests to use them all the time.
We want any subscription to be created once. The stream of values it produces should trigger many rerenders over time. If you go with Form-1 then the subscription will be recreated each time you rerender.
And is the reason to use subscriptions to abstract away the structure of the atom data store? ie the way re-frame chooses to do the equivalent of Om.Nexts static query function?
Yeah, there is a description of the dream situation here: https://github.com/Day8/re-frame#subscribe
I had a look at the testing part of the wiki. thanks for the link though. I guess thats my sticking point for the form-2 components. I just dont like the testing story.
With form-1 it seems pretty easy to pass in the atom and validate the data structure coming back. But form-2 components seem to make that more difficult. which is a shame.
Yeah, testing views is harder, if you want to use subscriptions. There are ways of doing it, if you are dedicated. But I find these days I almost never test views. There just don't seem to be many bugs in that part of my code. Bugs tend to come in the control logic ...event handlers.
BTW, the dedicated way of doing it is to always have an inner and outer version of the function. The outer sources the data and passes it in as props to the inner. Then the inner is pure.
Some discussion of that approach here (but not for the purposes of testing) https://github.com/Day8/re-frame/wiki/Using-Stateful-JS-Components
@underplank: on testing views, if you keep all the logic out of your views then there is a lot less to test
@underplank if testing was critical to you, you could easily enough create a macro which did the whole inner/outer thing automatically.
@danielcompton: yup agree. The road I was/am trying to go down is to have property based testing do most of the heavy lifting for me. ie generate the state from a schema, and then push that through and get the resulting datastructure.
To put an alternative point of view: every line of code you write is a liability. You only want to write tests where there is genuine value. Cost benefit and all that.