This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-29
Channels
- # aws (1)
- # aws-lambda (1)
- # beginners (34)
- # boot (61)
- # cljs-dev (126)
- # cljsjs (10)
- # cljsrn (4)
- # clojure (27)
- # clojure-russia (7)
- # clojure-spec (1)
- # clojure-uk (26)
- # clojurescript (42)
- # cursive (31)
- # datascript (4)
- # datomic (16)
- # hoplon (51)
- # klipse (1)
- # lein-figwheel (1)
- # lumo (79)
- # off-topic (16)
- # om (7)
- # parinfer (5)
- # planck (2)
- # re-frame (6)
- # reagent (3)
- # ring-swagger (5)
- # untangled (11)
@mynomoto dunno, i've got plenty of potential snippets 🤷
@chromalchemy, @grant: you might find the last commit helpful. elements can be overlaid now via the :d
istribute attribute. :d :pile
. i did the most lightweight implementation possible to get through a project, so if you want to use this feature, you'll need to (a) make sure the elem
is explicitly sized and (b) does not require the :p
ad and :a
lign attributes, which will not have the intended effect. in practice, i haven't found them necessary. here's what it looks like in practice:
(elem :s 400 :d :pile :b 2
(elem :s (r 1 1) :a :mid :c (hsl 0 (r 1 1) (r 1 2) (r 1 2))
"bottom")
(elem :s (r 1 1) :a :mid :c (hsl 240 (r 1 1) (r 1 2) (r 1 2))
"top"))
@dm3: i've been on the fence between :stack
and :pile
. my thinking was that :flow
and :pile
paired better since neither is a data structure. i could be convinced to change it though.
i was also considering a more elaborate :ltr
, :rtl
, :ftb
, :btf
implementation, but wasn't sure there was value in it. i haven't had any concrete cases where i needed right to left layout (other than for internationalization , but that applies only to text).
it does seem that stack would come more naturally to programmers too; i'll make the change on the next commit.
@jumblerg i've had to swap the layout rtl and it wasn't just text
apparently it made sense to move the sidebar too
@thedavidmeister: hm, switching a sidebar from the left to right side is an interesting case. i guess normally this would be done by reversing the order of the sidebar & body elements in the dom; is there any advantage in allowing those elements to remain in the same place while reversing the order in which they render?
this would have been in like 2010
also, if i were to to support right to left layout for things other than text, i'd probably need to implement both back-to-front and front-to-back layout.
so things were different then
i suppose the obvious thing is screen readers going from top to bottom
but if you have aria stuff on your sidebar should be ok
from memory there was something in css
ah, direction
also affects direction of flow of table cells
flexbox would also let you swap ordering
i was using that css attribute when i first added the ui distribution attribute, then took it out in the interest of simplification when i couldn't think of a concrete case for rtl layout.
@thedavidmeister may I put the snippet on the wiki for now?
@mynomoto of course
@jumblerg this was a while ago, but i think i was supporting pashto language
if that helps
it's basically that when you swap the text order, you might also want to swap the layout
as in, sidebar goes "where you start reading from" not "on the left"
seems like a sensible guiding principle. although incidentally, i remember placing the sidebar on the right for certain web apps because i'm right handed and it felt more natural to have it on the same side as my hand/mouse.
no way to win
@mynomoto i put this up as well, as the wiki entry was empty https://github.com/hoplon/hoplon/wiki/Hoplon-with-Datascript
@thedavidmeister cool! I have something like that on github client and will put in a library hopefully soon.
@mynomoto maybe you might be interested in this too?
(ns el.resize-observer.dom
(:require [hoplon.core :as h]
[javelin.core :as j]
polyfill.ResizeObserver))
(h/defelem div
[{:keys [width height]} children]
(let [el (h/div
:class "clearfix"
children)
;
el-attached? #(-> % .-ownerDocument .-body (.contains %))
cb (fn [es] (let [rect (-> es first .-contentRect)]
; Don't trigger a resize when the el is detached from the
; DOM as it will always be 0 and lead to a FOUC.
; There is another resize when the el is re-attached anyway.
(when (el-attached? el)
(j/dosync
(when width (reset! width (.-width rect)))
(when height (reset! height (.-height rect)))))))]
(.observe (js/ResizeObserver. cb) el)
el))
it's an element that knows how big it is
not sure what counts as "snippet worthy" 😛
that one needs this to work:
; ResizeObserver polyfill.
{:file ""
:provides ["polyfill.ResizeObserver"]}
because of browser support
ah, just working on something atm
i'll ping you with other stuff later 🙂