This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-17
Channels
- # admin-announcements (17)
- # announcements (1)
- # aws (8)
- # beginners (5)
- # boot (125)
- # cider (28)
- # clojure (33)
- # clojure-berlin (21)
- # clojure-italy (1)
- # clojure-japan (1)
- # clojure-nl (12)
- # clojure-poland (90)
- # clojure-russia (120)
- # clojurescript (284)
- # clojurex (2)
- # cursive (6)
- # datomic (14)
- # devcards (4)
- # events (2)
- # funcool (2)
- # hoplon (238)
- # ldnclj (32)
- # off-topic (27)
- # onyx (9)
- # re-frame (3)
- # reagent (22)
@peterromfeld: thanks
@tbrooke: nice!
Pretty impressive flexbox library for reageant — doing some interesting things there - with impressive demo. Something to learn from for hoplon perhaps :http://re-demo.s3-website-ap-southeast-2.amazonaws.com/#/h-box
that's great! too bad those aren't functions
they sure are documented like them 😉
I really do think having equivalent out-of-the-box functionality for hoplon would be a huge win as far as interest / uptake of hoplon.
jumblerg showed me some interesting flex type stuff he's been doing with hoplon this morning
seconded. I would gladly learn 50 new functions (that return custom DOM elements) that make sense. Right now it seems like everything is a div
in html
I should start writing my app so I get more hands-on experience with hoplon, but got too much work on my hands lately. And I'm really lazy setting things up 😞
looking at this I don't see this defined in castra https://github.com/hoplon/demos/blob/hoplon6/castra-chat/src/castra/demo/core.clj#L24
I see wrap-castra-session
and wrap-castra
in the middleware namespace. I guess those can be used as other ring middleware?
so something like (-> app-routes wrap-castra app-defaults)
makes sense right? app-routes
being the defined route(s) and app-defaults
coming from ring defaults
alandipert: micha: as i understood it's possible to provide kids as a cell to a hoplon dom element but it's not recommended. the reason is performance, if i understood it well. we have experienced a massive "memory leak" and huge slowdowns in our app because our menu implementation was something like this:
(div :id "module-segment"
(cell= [(when (= "#/module-x" route) (module-x)))
(when (= "#/module-y" route) (module-y)))
...]))
as a side-effect - in the chrome js profiler - we've noticed tons of timers being spinning, mostly kicked off by when-dom
under certain situation which we couldn't narrow down, when-dom
seemed to never terminate.
i guess it's something which never should happen but it did, so i was thinking maybe it's a good idea to add some guard conditions to when-dom
, just to make it fail a bit more gracefully. something like this maybe:
(defn when-dom [this f]
(if-not (instance? js/Element this)
(f)
(timeout
(let [retry (atom 60)]
(fn doit []
(swap! retry dec)
(if (.contains (.-documentElement js/document) this)
(f)
(if (pos? @retry)
(timeout doit 20)
(do (.log js/console "This element is never attached to the DOM:" this)))))))))
@onetom: the "cell children" thing is only recommended when the contents of the cell are stateless, meaning the only allocation is dom elements
so how would u define "stateless". some dom element which attributes or kids doesnt depend on any cells?
the other day u said something like "nested formula cells are not a good idea, because something something"
nested formula cells are just a pain to use with the cell= macro, and i haven't yet seen a case where they're needed
so i was thinking what exactly does it mean.
(defc stem1 nil)
(defc= formula1 (some-transform stem1))
(defc= formula2 (other-transform formula1))
is okay, but
(defc stem1 nil)
(defc= formula2 (other-transform (cell= (some-transform stem1))))
is not?but in practice that what happens when we work with hoplon, just there are a few more layers in between
generally if the formulas are getting complicated you're probably better off making a function that takes regular data and just calling that from the formula
but you don't want to do hardcore computing in there, instead you compute in functions that you can call from the formulas
(defelem elem1 [] (div :class (cell= {...}))
(defelem elem2 [] ...)
(defelem container []
(cell= (if condition (elem1) (elem2)))
and there u have a formula cell (the map for the :class) created/allocated within another formula cell (the conditional kids)
i got that, but is there anything inherently wrong with this structure, or it's just more prone to memory leaks or it does memory leak for sure?
i.e. they're pointers that don't increment the reference count of the thing they point to
@onetome you will get DOM errors that way (I am dealing with this right now)
or the point is that u won't do that because the structure of your program just wont allow that to happen?
well like javelin for example needs to keep a graph of all the cells and how they're connected to each other
it would be better if the graph could be GC piecewise, depending on whether your code references cells or not
micha: but then u would run ur own special cell graph GC to clean up the refs to the disposed cells, no?
@onetom: sure, yesterday I ran into the issue where my nested cell's wouldnt work as expected because the cell's had already been evaled (maybe dereferenced?) so trying to reset the cell wouldnt work i.e. "Error: cannot change Number 0...." something along those lines it wasnt a cell anymore
i was using the same method as your example
okay. what i mean i never saw such an error u just showed, that's why i suspect there was some other reason for that
pressing a button would constantly throw the error, I asked micha and he suggested getting rid of the cell=
haha yeah 😛
especially when you are seeing them all day 😞
how are your nested cell's being built?
@micha but what about the case as @onetom pointed out? that will happen in most apps at some point no?
every time i thought i needed them i always realized that there was a simpler way to do it
brain explode
so i explained this to my colleagues today like this:
u can control the attributes of dom elements reactively via cells,
but the dom elements themselves should not be added to or removed from the dom reactively.
loop-tpl
however can "safely" add/remove elements to/from the dom
so if u really want some elements to be sometimes present sometimes absent from the dom, then use loop-tpl
somehow.
loop-tpl will cleverly pool any allocated memory and reuse elements from the pool when possible
brain more explode
when i ask myself "why would it be good to not have the invisible elements in the dom?" im not very sure what would i answer, beside it's a bit confusing / disrupting / annoying to see a bunch of style="display:none"
s in the chrome inspector
plus there is no 1-to-1 mapping between what i see rendered and what i see in the dom inspector
but do we agree on the reason why would such a thing be good? are there any other reasons? do these reasons worth having the added complexity?
i keep finding myself worrying about what goes into the dom... it's just not a good mental model that "things are there just hidden"
not sure if CSS rules which rely on adjacency wouldnt break for example with the current model
imagine u have sections below each other but u dont want extra top margin before the 1st and after the last
we want to get to the point where we've carefully designed all the places where we're moving things in and out of the dom
which i found myself telling to other people too, but then i realized i couldnt explain myself clearly enough what does that mean, so probably they dont understand it either..
with hoplon we can eliminate 90% of this kind of thing by just not churning things into and out of the dom
i also wanted to ask u if this when-dom
is really necessary and why?
is it just the handling of some edge case or it's a regular state during the dom assembly?
i saw there is with-dom
using it but with-dom
itself was not used anywhere within the hoplon lib at least
micha: oh, yeah, another important thing i wanted to mention.
we saw some errors thrown from the test.clj
...
1st i was puzzled and thought some test suite got packaged together with hoplon, but then i saw it's a helper namespace which was made to house a test result reporter within the browser.
but it defines some cells and those were throwing errors when we were having these memory leaks...
and to make it absolutely clear: i was not trying to use it. i was not even aware it's there...
i've also upgraded to 1.78.122 as i saw in hoplon/build.boot is it necessary for some reason or just that was the latest cljsc version which u tested?
i was experimenting with goog-define and there is a bug with that that was fixed in .122
(that sounds a bit scary though... such an instrumental piece in the gcl still have bugs after so many year?!?)
@onetom: not much left of it 😲
@micha do you know of any examples or references for castra with a db?
id like to use it with mongo
but im not sure how im to wire the user auth up with castra
yeah I was looking at that one
you can have a precondition (the :rpc/pre
key) that checks that and throws an exception if no auth is in the session
so thats how I can persist session data between calls
is there a session accessor in hoplon?
seems i need to run a local copy of the old site 😛
@micha: ok im looking at the castra-chat example https://github.com/hoplon/demos/blob/master/castra-chat/src/castra/demo/core.clj is this still a valid example ?
ok so then I dont really do much work with the response at all, just drop it at a cell and let the formula's react on it, the real work should be on the backend yes?