This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-17
Channels
- # adventofcode (2)
- # bangalore-clj (1)
- # beginners (45)
- # boot (26)
- # cljs-dev (8)
- # cljsrn (25)
- # clojure (41)
- # clojure-austin (2)
- # clojure-belgium (6)
- # clojure-mke (3)
- # clojure-russia (37)
- # clojure-sanfrancisco (3)
- # clojure-spec (57)
- # clojure-taiwan (1)
- # clojure-uk (7)
- # clojurescript (27)
- # clr (1)
- # code-reviews (3)
- # core-async (1)
- # datascript (5)
- # datomic (19)
- # emacs (12)
- # hoplon (59)
- # lambdaisland (9)
- # lein-figwheel (3)
- # off-topic (4)
- # om (1)
- # onyx (51)
- # pedestal (1)
- # protorepl (2)
- # re-frame (12)
@alandipert: I see new things are brewing!! What is your stack built with?
gonna work with jesse on a 'canonical' full-stack example that shows use of all the stuff we advocate
at work
all the demos are small and out of date
Awesome! Good idea!
and hopefully this example could serve as a living doc, and source of things like templates
Like a demo documentation app
I like it đź‘Ť
yeah, something close to real. and deployable to heroku
@alandipert @jumblerg Thank You Panoply is what some of us need đź‘Ź đź‘Ź
@alandipert @micha is there any way to top *-tpl
from caching the elements
in my case i’d like to know that the local state is reset to initial values every time my elem is attached to the dom
if you used for without the tpl it wouldn't cache... but maybe i don't fully understand what you're trying to accomplish.
my understanding is that if i don’t use tpl i’ll run into memory leaks
i can’t get rid of the elements i don’t want?
caching is the approach hoplon has taken as an alternative to lifecycle methods/destructors/etc.
not without some kind of explicit call to release all the references, which i do not believe the javelin cells in particular support right now.
i thought you could destroy cells so they can be gc
the only drawback to this approach that i have experienced is that cells pertaining to elements that are not in the dom will continue to evaluate in the background
yes, that’s the issue i have
(destroy-cell! c)
;; Disconnects c from the propagation graph so it can be GC’d.
there's not any logic to release their corresponding watches that set the properties on the elements though.
i've found that writing my formula cells to handle all the values, including those that might occur when an element is outside the dom, is pretty easy once you get used to it.
but i was having a conversation with micha last week about the possibility of preventing this behavior
the problem i have is that one of my cells relies on bubbling events
seems to somehow be getting events triggered when its not in the dom
but in a way that could never happen normally
i end up with an assert that gets triggered
javelin is the library i've worked the least on, but i am familiar with the watch mechanisms in hoplon (and alan is in an aluminum tube at 50,000 ft or so).
i got a 3 tier structure in the dom and i track the “current position” in a cell
so if you focus/click something the current position is pieced together as the event bubbles up through the tiers
seems to trigger a focus on one of the lower tiers that then does not bubble up to higher tiers
because detached dom elements do not bubble events
at least i think that’s what’s happening
easiest solution in my mind is just guarantee that the cursor is reset to nil
at all levels whenever the elem goes back into the dom
fresh slate 🙂
holds the current position
and how does the position get placed in the cell? via a handler at a root node the events bubble up to?
and 3 nested nodes below the root
1 for each tier
i don't think i fully grasp the problem. could you do away with the assertion since it appears the claim the assertion is making cannot always hold true in this model?
sure, except that it should hold true
i mean, sure i can get rid of the assertion but it’s a useful safety net
my approach has typically been to handle the exceptional values that may occur when cells evaluate and set properties on elements outside of the dom - typically nil footguns - rather than trying to prevent those situations from occuring.
you get fewer guarantees and have to handle more cases within the cells when dom management is devolved to the -tpls.
that has been largely fine
i can see how there might be some ugly corner cases though where this is less easily done, but i think my instinct would be to reevaluate the larger approach first.
or maybe what you're doing is entirely reasonable and we need to support that case somehow. :)
seriously, it should all be good if i can reset the position cursor to nil
i don’t care if the vals go crazy after the el is detached
but i want it back to something sane before either that el or a new one is attached again