Fork me on GitHub

What toolchain or hosting option should we use for Reagent's docs:


It might be too geared toward APIs tho


Could you add to ticket, so nothing gets lost and all conversations are contained.

Pablo Fernandez06:12:13

@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?


Yeah, absolutely sure.


Give me a sec, i just want to look at core.async


See what it does on Node

Pablo Fernandez06:12:18

I have a very poor understanding of this non-thread model in js

Pablo Fernandez07:12:35

@mikethompson: did you find anything useful?


Ah, sorry, no. i got distracted by one of those idiot conversations one has every now and again on the internet


Back to it now


The idiot being me for getting involved

Pablo Fernandez07:12:58

I suppose dispatch/queue-delay is the critical bit?


Yeah, and it looks like the dispatch releated code uses goog.async.nextTick and js/setTimeout

Pablo Fernandez07:12:34

That means that the problem is in my code and not core.async, correct?


Yeah, I'm thinking that.

Pablo Fernandez07:12:30

My code looks like this:

Pablo Fernandez07:12:34

(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)

Pablo Fernandez07:12:08

I suppose instead of just

ring, I should try to give control back to re-frame.


I'm sorry to do this ... but I have to go to dinner


@pupeno: in that code above, shouldn't it be (<! (timeout event-timeout))


@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 ?

Pablo Fernandez11:12:48

dm3: it just worked for me, where are you based?



Pablo Fernandez11:12:28

I wonder if that’s an issue. I would reach to skillsmatter, they are very responsive.


Dear all, I've written up a page on using stateful JS components from within Reagent/Re-frame: 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 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: 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.


Ah. And if we want to use subscriptions, then we want to do that. ok.


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:


ahh righto, that makes sense. Next question. Testing.


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.


Right. yup. I guess that makes sense.


Some discussion of that approach here (but not for the purposes of testing)


The outer becomes quite trivial.


Ahh thanks. that Wiki is pretty extensive simple_smile


@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.


But I agree with @danielcompton there's often not much to test in the view.


yup. These are all things I need to think about. Thanks a lot for your help!


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.


oh sure, hence the wanting to make it as easy as possible to verify.