This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-08
Channels
- # admin-announcements (7)
- # aws (5)
- # beginners (37)
- # boot (39)
- # cider (4)
- # clara (2)
- # cljs-dev (32)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (235)
- # clojure-austin (3)
- # clojure-belgium (7)
- # clojure-berlin (11)
- # clojure-dev (36)
- # clojure-france (10)
- # clojure-japan (10)
- # clojure-poland (2)
- # clojure-russia (39)
- # clojure-uk (4)
- # clojurescript (81)
- # code-reviews (9)
- # core-async (6)
- # core-logic (1)
- # datomic (32)
- # editors (7)
- # emacs (1)
- # hoplon (191)
- # jobs-discuss (14)
- # juxt (4)
- # lein-figwheel (4)
- # leiningen (3)
- # off-topic (7)
- # om (49)
- # onyx (34)
- # other-lisps (1)
- # overtone (11)
- # parinfer (1)
- # proton (5)
- # re-frame (11)
- # reagent (12)
- # spacemacs (2)
- # untangled (90)
- # yada (15)
Nice!!
Hello! @alandipert @micha Should Hoplon readme mention Transit instead of Cljson?
@leontalbot: if you’re updating the readme, i imagine it should probably be struck from it entirely, since transit is merely a dependency of castra (and cljson has been deprecated in favor of transit).
Thanks @jumblerg.
@micha: am thinking about the do!
multimethod in the context of trying to build up larger components. while do!
specifies how to “write” to each component, it does not specify how to “read”. maybe it should take two functions instead for both get and set to facilitate the construction of a general maplike api over the concrete oop element interface. should be able to do not only (div :css/width “100px”)
, but also (div :css/width)
/ (:css/width div)
.
as such, a lens might come in handy here. the use of cells on the read side can also help ameliorate many of the timing issues associated with getting the computed properties of elements when they are rendered in the dom.
maybe also consider extending the js/Element type with IAssociative
, ILookup
, IMap
, et. al
i’m thinking of each Element as a model with two interfaces: the first used by the browser for rendering, the second defined and used by hoplon. lenses can be used to prescribe the two way bindings between them (with the added benefit of replacing the remaining jQuery machinery used in the do!
multimethods).
the user should be able to interact with each element as a map, one that contains properties on the left side and corresponding values as cells on the right. this would make possible things like computing the width of an element to fill a remaining space once it is rendered. eg (div :css/width (cell= (- (:css/width window) (+ (:css/width elem-a) (:css/width elem-b)))) …)
.
this allows you to just declare what you want the element to do, whenever it is the browser happens to compute the sizes of the dependent elements (and, assuming the window object is given a similar treatment), readjust the size of the element when the window is resized.
perhaps. i’ve been thinking of hoplon as a sort of shim between other stuff (like my ui lib) and the browser, where every abstraction in hoplon has a 1:1 correlation with the corresponding thing in the browser.
that would be a lot of cpu cycles to create all those cells, perform reflection on every single element to get its properties
and a lot of those properties are weird native code things that aren't even valid javascript things
it seems like the right abstraction to me, but is it practically implementable? i dunno. hoplon could only expose a subset of those properties, the ones ppl would need.
think about how you would handle the case where an object gets a new property after you've created the map interface
well, the map would be immutable, but the cells as the values, as reference types, would not be in this approach.
well, there would be two possibilities in this case, it would be change by (1) one, the browser, or (2) the application. in the case of the application, you’d know because it would be set via the same interface. insofar as the browser is concerned (in which case it would only be changed by maybe some third party style sheet) it might not be possible.
i’m sure there are holes, i just wonder how many there would be in practice if it was worked through. it might not be possible.
my general observation is that the read/get/query side of things has been neglected by hoplon so far.
if it were possible to make improvements here, it would make composing larger components on top much easier.
i’m really talking about two things, i guess: 1. creating a general interface and 2. making that interface reactive.
i guess the drawbacks in my proposal are, in the case of 1, suggesting a mutable Element has semantics of an immutable object by implementing a map like interface might not be ideal.
and in the case of 2, the hooks might not exist to detect changes to a large number of the properties
for 2. there's http://caniuse.com/#feat=mutationobserver
(there’s always polling, which if just a hook into the event loop, might not make that big a difference, i dunno. everything is possible if you ignore performance entirely. :)
most of these things (like the cssom stuff) tend to be ie 10 up and everything else.
@dm3: lol. my error message for incompatible versions of ie typically read, “you’re using internet explorer x. now please download a web browser. <links here>."
can look at https://github.com/Polymer/observe-js for inspiration
another thought: if we have 2 (via mutation observer), we’ll also be able to solve 1.
yeah, object.observe seems to be a fairy tale: http://caniuse.com/#feat=object-observe
"Probably the biggest audience for this new api are the people that write JS frameworks, mainly to solve problems and create interactions they could not have done previously, or at least not with reasonable performance. Another use case would be situations where you are using frameworks that manipulate the DOM and need to react to these modifications efficiently ( and without setTimeout hacks! )."
iirc mutation observers are dead
Mutation Observer - LS
Method for observing and reacting to changes to the DOM. Replaces MutationEvents, which is deprecated.
right now every element is backed by a couple atoms anyway, if we shove a bit more state in that atom by way of a mutation observer, then use lenses to create two way bindings to an associative api...
i misremembered, that was Object.observe which is a JS thing, not a dom thing
and the atoms are only modified when you add or remove elements from the dom, which is rare in hoplon
if every element created in Hoplon registered a watch in the observer and a cell for an attribute would only be created when requested e.g. (:css/width elem)
all the cssom stuff (like the apis i used to implement media queries) started in 10.
also MutationObserver can only observe things that are visible in the HTML (.innerHtml of the node)
@micha: can we defer cell creation, make it lazy? thereby create cells only for properties we need to bind to?
if element implemented IGet
(or whatever), then on (:attr/width elem)
it would create a cell/atom and put it into a collection observed by the MutationObserver. Then the cell would be removed from the observed collection once the element is removed from the DOM. Would this work?
there was a discussion on having a map interface on elements and I recall Micha being opposed to that
such as the one above, where you need to calculate sizes and positions based on values that aren't set until an element is rendered
the idea of attributes being cells is very attractive to me also
i feel like it's compatible with clojure to the extent that the reference to the object that has the attributes is immutable
i guess that's still problematic, because what if you dissociate an attribute and someone held on to a cell view of it
i assume theres a protocol associated with dissociation that can be implemented the way we need
i mean, it isn't a map per se, it is a elem type with the appropriate protocols implemented accordingly
there's a reason all these fns aren't all part of the same IMap protocol. separate comcerns.
but regardless of whether you tuck it i to a small mcv triplet or distribute it across the larger cqrs pattern, we back mutable displays with versioned models all the time.
maybe the Element is a different mutable thing altogether, but just has the ability to fire formula cells when attributes change
hm what if the set of attributes on an object was its own cell
if you take a thing and make every mutable aspect of a cell, maybe you have a thing
as big a deal as being able to declaratively specify attributes of one elem based on others is, could also trigger cyclical infinite rerenders
of course, i guess you run that risk anytime you do a calculation and do something stupid
massive undertaking though, probably better just to put a sane api over the existing one