This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-14
Channels
- # admin-announcements (2)
- # beginners (32)
- # boot (217)
- # cider (20)
- # cljsjs (25)
- # cljsrn (9)
- # clojure (87)
- # clojure-android (7)
- # clojure-austin (4)
- # clojure-belgium (10)
- # clojure-canada (13)
- # clojure-dev (28)
- # clojure-dusseldorf (2)
- # clojure-greece (119)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spain (3)
- # clojure-spec (81)
- # clojure-uk (54)
- # clojurescript (32)
- # community-development (2)
- # core-async (19)
- # cursive (18)
- # datascript (5)
- # datomic (1)
- # dirac (22)
- # emacs (22)
- # hoplon (198)
- # incanter (1)
- # instaparse (4)
- # jobs (3)
- # keechma (15)
- # ldnclj (2)
- # lein-figwheel (14)
- # mount (8)
- # om (78)
- # om-next (4)
- # onyx (37)
- # other-languages (1)
- # pedestal (6)
- # re-frame (22)
- # reagent (25)
- # ring-swagger (17)
- # robots (1)
- # slack-help (1)
- # spacemacs (7)
- # specter (50)
- # spirituality-ethics (3)
- # uncomplicate (5)
- # untangled (1)
- # yada (17)
Where can I learn about Hoplon routing?
@micha: i’m thinking it would be helpful if ->node
were made extensible so we can pass different types of children into hoplon-extended elements, and they can self-prescribe how they want to be rendered into the dom.
either by multimethod or by creating a protocol for ->node
, curious to hear your thoughts when you have a few
@leontalbot: there’s no explicitly-supported routing methodology baked into hoplon atm
there’s some code you could borrow from my ui experiments though, since i’ve built a solution into the window elem
does it also make sense to support INode
as a protocol behind the attribute multimethod while at it?
i have cases, however, where certain types need to render to different things depending upon whether they’re a js/Attr
or a js/Element
, so I’m wondering, if we agree on a protocol for attibutes, if we should have separate IElementable
and IAttributeable
protocols.
i also just remembered that js/Attr
no longer inherits from js/Node
in newer implementations of the dom, so i guess they should be separate.
excuse my noobishness: how are these protocols useful? like, what is possible once Hoplon has them?
but if we open it up, then users can define new types of things, such as i’m doing in the ui lib, and simply specify how hoplon should go about inserting those types into the dom.
very much agreed. this is just one fn to allow things to describe how they want to render into the dom, not the first in a set of lifecycle methods.
i’m reticent to open a can-o-worms here, but if we were to attempt to gc things at some point in the future, which requires explicitly detaching things in the absence of weak references, another unrendering fn could prove useful. the issue with React appears to me, in my unofficial and somewhat uninformed opinion, is that the lifecycle methods leaked out in such a way they seemed to be getting implemented on everything.
for a very small set of primitive types, they could makes sense, internally, so to speak
i’ve seen a few libs where custom components seem to implement a bunch of lifecycle methods. i think this was not what the creators of React intended either, incidentally, based on a blogpost i recall reading at one point. i suspect they were abused by third parties because they were there. but i should probably stop talking now, because i’m speaking of things i know nothing of. 🙂
yeah, a detach lifecycle function would be a departure from the hoplon way of doing things
like sure, there are some ways you can do things that will leak memory, but you can always find lots of ways to do that in the browser
@micha: ithe *-tpl stuff prevents leaks, but if things were gc’d, i wonder if the overall memory profile could be reduced.
say someone renders a bunch of images in an infinite scrolling thing… the current approach will remove them from the dom, but do the images hang around in the tpl cache?
say i navigate from one state that has a bitmap image via img
to another, then back… doesn’t that image element retain its bitmap data while detached from the dom?
the “infinite" scroll is a bad example, basically, even through it is controlled, the memory profile of the app will expand as i navigate through more states and more things are added to and removed from the dom because they are cached by the *-tpls, and if some of these elements are heavy, such as bitmap images, this might not be great for certain cases.
in this case, unless my previous assertion is incorrect, a more pragmatic approach could be to purge img elems of their bitmap data in certain cases, make the memory management model a bit more sophisticated via ref counting in the future.
i don’t think it makes sense to expose a detach lifecycleish method. i’m completely on board with the current approach, i think it is a much better model. just playing a bit of devil’s advocate to explore the drawbacks of this approach and understand what we can do to make it better or applicable to even more cases.
things that are in the pool will consume memory, but i don't think that's a big deal in practice
like for instance your image thing, the image URL will be nil while it's in the pool probably
agreed in the case of most web app. if i jam a ton of high-res images in there because i’m building a photo sharing app - building getty images - i imagine it become problematic at some point.
i think they retain the bitmap data, i’ve preloaded images by passing the elems urls before putting them in the dom before
@jumblerg: looks good, but perhaps without the last commit, d3afd653dd7fe8faee661f4cbc5f39e06a0dcbbb
(defprotocol INode
(-as-node [this]))
(defn- ->node
[x]
(cond (string? x) ($text x)
(number? x) ($text (str x))
(satisfies? INode x) (-as-node x)
:else x))
esp in the ui project, where i have a bunch of attribute constructors that need a reference to the elem
they’re separate here https://github.com/hoplon/hoplon/commit/9f16da1cdad11647fd31fa72f90c459d4f62e716
i do think the elem var is, in a way, simply modeling the messy context we’re dealing with
we can’t construct an attribute without a reference to the elem it is being associated with anymore
and things like this https://github.com/hoplon/hoplon/blob/node-protocol/src/hoplon/core.cljs#L93-L98
we're operating on a higher level, those are craeted when you actually do something to an element
since for our purposes we don't actually intend to add attributes to the actual dom node
we extended it with the do!
and on!
multimethods, so you can add your own methods essentially to the prototype
do you think it makes sense to expose a protocol like IAttr
, with a ->attr
similar to ->node
behind the do!
and on!
mulimethods?
(deftype Elem [o m i]
IPrintWithWriter
(-pr-writer [this w _]
(write-all w "#<Elem: " (.-tagName o) " " (.-tagName m) " " (.-tagName i) ">")) ;; todo: print all attributes
hoplon.core/INode
(->node [_]
(with-let [_ o]
(.appendChild m i)
(.appendChild o m)))
hoplon.core/ICustomElement
(-append-child! [_ new-elem]
(hoplon.core/append-child! i new-elem))
(-insert-before! [_ new-elem old-elem]
(hoplon.core/insert-before! i new-elem old-elem))
(-remove-child! [_ old-elem]
(hoplon.core/remove-child! i old-elem))
IManageLayout
(-align-horizontal [_ v]
(align-horizontal- o m i v))
(-align-vertical [_ v]
(align-vertical- o m i v))
IFollowLayout
(-position-vertical [e v]
(set! (.. e -style -verticalAlign) (or v o-verticalAlign))))
the first versions were done with fns, but it seemed it reached a point where things needed to be structured better
i have a considerable number of cases i’m juggling that we should probably work through together so you can get a holistic sense of things
i can just tell the users of my webapp to upgrade, if for whatever reason, they’re still running an old one
but maybe we should survey the rest of the community to see what browser support they need
http://netmarketshare.com says ie8 is > 6%
but i guess we support 8 and up for the time being, until we have something to gain by dropping a version or two?
@jumblerg Thanks!