This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-19
Channels
- # aws (4)
- # aws-lambda (2)
- # beginners (67)
- # boot (38)
- # cider (32)
- # cljs-dev (12)
- # cljsrn (2)
- # clojars (2)
- # clojure (190)
- # clojure-chicago (1)
- # clojure-dusseldorf (2)
- # clojure-germany (1)
- # clojure-greece (3)
- # clojure-italy (5)
- # clojure-russia (6)
- # clojure-spec (47)
- # clojure-uk (10)
- # clojurescript (59)
- # cursive (9)
- # data-science (14)
- # datomic (24)
- # devops (16)
- # emacs (8)
- # fulcro (25)
- # graphql (30)
- # hoplon (123)
- # juxt (15)
- # lambdaisland (2)
- # leiningen (4)
- # luminus (6)
- # lumo (9)
- # off-topic (11)
- # om (7)
- # onyx (8)
- # re-frame (14)
- # reagent (5)
- # ring-swagger (5)
- # shadow-cljs (46)
- # spacemacs (41)
- # specter (8)
- # testing (8)
- # unrepl (31)
- # yada (18)
ok i'm reading about flapjax 🙂
it was pretty sweet for its day
@alandipert i'm only a few pages in, keep getting distracted, but it reminds me of https://cycle.js.org/
thedavidmeister https://www.youtube.com/watch?v=xaxF5RDdVRE#t=22m21s is a lightning talk i gave on flapjax in cljs in 2012
oh i hadn't seen that one
@alandipert so would i be right in saying that in flapjax terminology javelin cells are like behaviours and there isn't really an event system?
that's right
one thing we saw is several systems like flapjax implemented events/streams after they had behaviors. by putting random values or counters in behaviors, causing them to fire each time
or, a timer, causing propagation every tick
the thing you need though to achieve max behavior is pervasive useful equality
which is what made flapjax fail in cljs in the end, it had weak equality baked in. so javelin started as a close port of flapjax w/ cljs = as the test
yeah, so i've been taking the random value approach and it mostly works, but finding edge cases where i don't know how to make it work nicely or at all 😕
the way i'm thinking about it atm is that if you implement events using behaviours, then you're modelling behaviours as "events + a cache" and then you manually bust the cache with that counter/random value
but it doesn't 100% work if you want to trigger side effects/callbacks with meaningful event values that aren't counters/uuids
(defmethod do! :focus
[elem _ v]
(with-timeout 0
(if v (.focus (js/jQuery elem)) (.focusout (js/jQuery elem)))))
if i want to trigger focusout
twice then i have to artificially cycle between nil
and false
ha, that's a cool trick though
but this relies on an implementation detail of :focus
that actually doesn't meet the spec atm
(defmethod spec/do! :focus
[_]
(spec/attr :hoplon.spec/boolean))
yes it's definitely a cool trick 😛
if i strictly had to pass a boolean to :focus
then i cannot trigger focus or focusout twice without artificially cycling through the other event, which could easily generate FOUCs or jank, etc.
altho, why would you want trigger focusout twice?
:focus (j/cell= x)
so whenever x changes, trigger an event
but x changing and the current state of the element aren't related in any way
it seems the flawed assumption is that :focus
is singularly responsible for or at least accurately tracking the focus state of the element
yeah, i'm not sure focus is a good thing to be an attribute
since it's a singleton state in a way
also it interacts with children, e.g. focusin
vs. focus
in jquery
there very easily can be something outside the sensible responsibility of x
that is adding/removing focus from the element
i think it might make sense for that to be a subsystem of some kind
so x
needs to explicitly focus in/out as needed, it can't just assume that if it gets 2 false
values in a row that everything is fine
yeah, some separate coordination system seems necessary, to keep things in sync
i gotta run, my brain will consider this further in the shower tomorrow
just whether the equality check should "cache" the result
i'm suggesting that rather than implicitly working around the internal cache to simulate events by generating counters and uuids and whatnots
making it explicit somehow that the cache should not apply in certain situations
then you'd basically have "real" events
e.g. an un-cell=
for "unconditional" or "unchecked" propagation downstream
i have done things like that, but then you have global state to deal with
the whole DOM is global state, conceptually 😛
i sort of see what you mean
like, triggering focus on something implies that something else somewhere loses focus
but that doesn't sit well with bubbling and whether parents are in focus
you don't just have a single "focussed element"
there's a whole chain of elements in focus, at least in the jquery model with focusin
yes, i have done exactly this, built up a set of elements that are "in focus"
but then you have a lot to co-ordinate and you're just re-implementing what already exists
sort of like a virtual dom...
it seems like :focus
is an event, and a :focused
property should be specifically supported by hoplon
and this is just focus, what about mousedown, is that not also an event with all the same characteristics?
or keyup?
or the majority of events, really
w.r.t. wanting to trigger them on an element more than once without juggling counters/uuids
bubbling was a reason why co-ordinating this is more difficult than simply having a "currently focussed" element
but the goal is to trigger DOM events reliably, and still leverage all the javelin goodness
yeah, or any other event
forget the specific event, they broadly all function the same for the purpose of this discussion
(elem :eventname cell)
triggers eventname
whenever cell
is truthy
so to trigger it more than once, you have to make sure it's a different truthy value (according to =
) for each trigger
hence, counters and uuids
but that's just a workaround/trick really
well i agree, yes, that's why i'm thinking an extension or new type of cell atm
that's the flapjax reference ^^
they distinguish between behaviour and events
yeah i see it's probably relevant to https://github.com/hoplon/javelin/issues/35
well whatever the final outcome is, i hope it has nice hoplon support 🙂
"Custom error propagation strategy per graph. E.g. you can set the graph to behave like Excel and propagate #ERR on formula errors instead of the default throwing behaviour." - seems pretty close to custom value propagation 😉
oh ok, what were you working on?
I have a CEP part based on an event query language which then signals state transitions to the cell graph
sort of select * from ThisHappened where average(window(5 minutes)) > 5
-> (defc happened? false)
-> more cells
ah sure
so each query was a different graph of cells?
ah yeah i see
not really a use case for hoplon >.<
the added benefit of custom propagation vs. event streams
is that custom propagation could also address https://github.com/hoplon/hoplon/pull/193 at the javelin layer
which is the situation where direct user input modifies the DOM "underneath" hoplon, so setting the same value twice is necessary even for a behaviour
dm3 sounds really cool, what kinds of actions to you have hung off your cell graph? is it for UI or something different?
@alandipert no, it’s for alerts. Like sending messages to Slack, etc