Fork me on GitHub

A question: in the timer example on, how is the timer disposed once it's no longer needed?


It's never not needed? The way to control it would be to pass a cell argument to the defelem that once false, cancelled timer


Like an optional attr


@flyboarder: You mentioned Firebase previously. Why don’t you add Firebase example to Brew?


@tbrooke: that's a good idea, I'll whip something together today


I've been looking into Hoplon after the awesome interview on and I am pretty interested. I was looking at Castra and wondering if I could bring it in to some of my existing applications, as the RPC style seems to be a much better fit than what I have in there right now. Is it possible to use Castra with a react based front end (reagent, rum, om) and are there any examples?


@shaun-mahood: totally possible, i'm not aware of any examples


@alandipert: I assume I would have to pull in Hoplon and integrate cells in some fashion? Then just use the react based library in place of Javelin?


you would pull castra into your server and client. on the server for the ring middleware defrpc macro, and on the client for the mkremote macro


javelin would come transitively


mkremote creates a javelin cell, which behaves like a clojure atom


so you could attach your rendering lib to the mkremote javelin cell the same as you'd attach renderign stuff to a clojure atom


does that make sense?


Totally makes sense, doesn't even sound like it would be hard 🙂 Thanks!


err, mkremote doesn't even create a javelin cell, it takes the cell to put results/errors into as an argument


i believe you can pass it atoms and it will work


cool, yeah, looking at mkremote - - it only does reset! and swap! on the state/error/loading arguments. so you could pass it anything that implements the IReset/ISwap protocols including native atoms


Oh that's really cool! My current apps are built with re-frame and the RPC nature of Castra looks like it should fit really nicely with re-frames concept of subscriptions and events. Now I'm curious if javelin cells might make for a more interesting atom to store the data though too.


I'm really enjoying the concepts and thought put into Hoplon so far, seems like a really solid project and a really interesting take on thngs.


@tbrooke: has everything I think you’ll need for the actual hoplon/javelin integration this version was recreated from production code and needs to be tested ie. with-auth! may not work


^ added a wiki page for brew


@shaun-mahood: oh i should also mention, shows a peculiar way of using javelin outside of hoplon that might be helpful in understanding


mostly it shows how to work with values instead of channels/events


@alandipert: Oh that looks useful, thanks. I have a couple of legacy jQuery applications I support right now too, so I may end up using it for that too 🙂


> It's never not needed? In the example yes but generally there might be parts of your application that need a thing and then these parts are removed from the page, thus the thing is no longer needed. I was wondering how hoplon deals with the, I'm afraid to use the word, lifecycle of components


Yeah, one would need to develop ones own lifecycle convention


Of the conventions, dynamic binding seems the most common


As far as I've seen and used anyway