Fork me on GitHub

@neurogoo you could use the react lifecycle method :component-did-update to play the audio after the src has updated and propagated to the real DOM.


take a look at form-3 reagent components.


If I wanted to build a reactive app with re-frame, should I understand / build something reagent first?


Any recommended step by step tutorials on reagent & reframe for relative novices? I'm running a hackday for 20+ Clojurians and would like to build a reactive app step by step in Clojurescript and we got stuck with Om last time as we didnt have enough info to help us. One of the ideas is to build a live voting app for presenters, so the audience can give feedback as they are speaking. It would be great if any tutorials also used Dev cards. Any suggestions appreciated. Thank you


sounds websocket-ey to me?


i'm definitely no pro, but i think reagent and re-frame are so intertwined that it makes sense to learn both at the same time


i can't imagine building an app strictly in reagent to any scale without having something (re-frame) to manage the state, even if it's really simple. especially if you're using figwheel with hot reloading as your state might disappear between reloads. that's just my two cents 🙂


in terms of a voting app, you'd probably be looking at IO to a server to collect the votes which might go a little beyond the very basics. there's some documentation here:


@jr0cket here's the repo from a talk i did a while back - it implements a simple chat system with reagent on the front-end, aleph on the back end and comms over websockets - there might be some inspiration there -


@mccraigmccraig: thanks for sharing. Did you have the slides too? Unfortunately I doubt I'll have time to understand the code before the hack, but will share it with the others as an example.


@jouerose i've got the slides, and you are welcome to them, but the presentation was oriented towards mesos rather than clojure - the chat thing was a demo app to deploy on mesos. i also wouldn't do the server part the same way for a hackday - i would get rid of the kafka dependency for ex. anyway, pm me an email if you still want a copy of the slides given all those caveats 🙂


ps @jr0cket after your spacemacs workshop the other day, i'm converted !


@mccraigmccraig: happy you got something from the Spacemacs workshop. For the hack tomorrow I found some step by step tutorials that will give a gentle intro. The we can have a look at some examples, such as your sparky elephants and see how much we learnt :)


yep, definitly no going back after learning the flow. I still find it hard to believe I used to do stuff in jQuery (direct dom manupulation) and then plain react. I really miss the joys of figwheel after getting assigned an ES6 project at work last week....


you can really apperciate the simplicity of cljs when your boss tells you to go work on a js project and you're already struggling with this bindings and sharing mutable state on your first day. It took me hours to reminds myself that in the crazy land of mutable data structures, both {} == {} and [] == [] are false expressions.


those crazy mutants


Hi everyone, haven’t used re-frame since 0.7 and I’m evaluating it for our app now, very impressed with the progress since then!


One of our requirements is to have access to the latest app-state in an event handler even when events fire quicker than react refreshes the component’s props. I wrote a component that onKeyPress, dispatches an :inc-counter event with the current counter value as an arg. I was kind of expecting things to get out of sync, but even after cranking my keyboard repeat rate to 3ms, the handler arg always matched the current value in the app-state. Though that’s absolutely what we want I don’t understand how that works given the usual limitations of react props not refreshing faster than requestAnimationFrame?


☄️ magic ☄️


The UI is indeed updating every annimaetionframe, but events are quued up and processed en mass, one after the other.


So one UI update every 16ms might be reflecting the accumulated changes of 100 events.


Right that makes a lot of sense, the event loop is queued at a next tick resolution, and the render loop depends on requestAnimationFrame


Ok I think I get the magic, if your event handler derefs the subscription outside of the render loop you’ll still get to see the state at the tick resolution level? This would have been why I could fire off events much faster than the counter was being rendered and yet it looked like the state was always consistent


@jr0cket The answer is "it depends" :-) Mostly on how much time you have. Using re-frame would triple the amount of upfront learning (over pure Reagent) and it sounds like you are in a time constrained environment. I believe there are big benefits to using re-frame as an application starts to get more complex but if you don't have the time to cover it, then maybe pure Reagent would be best. Do you have the option of asking participants to read any documentation beforehand? If so, that could change the equation. A fair bit of re-frame is simply reading time. None of it is particularly hard.


@mikethompson does the queueing of events on nextTick guarantee that dispatching things rapidly, say in a loop, will ensure the events are processed in order and will always see the side-effects of the previous one?


Events are processed FIFO. So they are always processed in order. And they will always see the effect (on app-db) of all previous ones. nextTick means the event will be processed as fast as is possible (given the constraints of living in a browser. )


If an event handler triggers other effects, like an HTTP GET, then that might not be complete (no response yet) before the next event is handled.


But historical effects on app-db are always present when an event is processed.