What toolchain or hosting option should we use for Reagent's docs: https://github.com/reagent-project/reagent/issues/209

perhaps https://github.com/tripit/slate would be good?

It might be too geared toward APIs tho

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

certainly

thx

Hello.

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

sigh

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

See what it does on Node

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

@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

Ah… hehe

It happens.

😉

The idiot being me for getting involved

The clojurescript core.async implementation is here: https://github.com/clojure/core.async/tree/master/src/main/clojure/cljs/core/async

timeout is here: https://github.com/clojure/core.async/tree/master/src/main/clojure/cljs/core/async

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 https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/dispatch.cljs

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

Yeah, I'm thinking that.

My code looks like this:

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

I suppose instead of just

recur

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

np.

bon apettite!

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

https://skillsmatter.com/skillscasts/7227-clojurescript-architecting-for-scale

Thanks

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

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

switzerland

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

ok, thx

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.

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: https://github.com/Day8/re-frame#subscribe

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

Yep: https://github.com/Day8/re-frame/wiki/Testing

And debugging: https://github.com/Day8/re-frame/wiki/Debugging

And more !

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) https://github.com/Day8/re-frame/wiki/Using-Stateful-JS-Components

The outer becomes quite trivial.

Ahh thanks. that Wiki is pretty extensive

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