This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-24
Channels
- # admin-announcements (2)
- # beginners (5)
- # boot (29)
- # cider (46)
- # cljsjs (1)
- # clojure (19)
- # clojure-quebec (1)
- # clojure-russia (73)
- # clojure-spec (30)
- # clojure-uk (23)
- # clojurescript (35)
- # datascript (12)
- # datomic (7)
- # emacs (26)
- # hoplon (168)
- # leiningen (7)
- # off-topic (2)
- # om (32)
- # perun (8)
- # protorepl (8)
- # ring (45)
- # specter (10)
- # test-check (2)
- # yada (6)
Thanks in advance... and for the continued work.. it's definitely fun to play with.
One thing that's helping me: When I use hlisp in standard Hoplon, if I define an element with (defelem ...)
in a namespace in a .cljs.hl page outside of the one with the Page declaration, boot-reload will not auto-refresh when I save the external namespace file. But this is working with hoplon/ui elems , so I am able to enjoy the boot-reload repl-y flow when working in sub files. And this is critical when doing a lot of visual changes to visually inspect things as I go...
Is there any way to overload the styling of the markdown elements? Or does that need to be baked in at the library level?
here goes:
1. ids and classes. there isn’t support for these, and i’m opposed to adding it: ids and classes are for use with selectors, which we’re trying to avoid using. however, i’ve had others ask about this as well for debugging, and am instead working on a scheme where the same symbol passed to defelem will correspond to the name of the outer div: eg <hoplon.ui.mycomponent …>
or something similar based on hoplon’s existing munging mechanisms.
2. css transitions. yes, we’ve introduced a notion of states, and transactions are the next logical step to add on top of them after we work through a few more issues with the way elem states are being handled.
3. hidden. this value can also be used to set the visibility attribute. it may also reappear as some part of the api to control scrolling/overflow, which has proven particularly tricky to get right.
4. jQuery. no, if you need jQuery for something, then we need to add something to our own api.
5. markdown. this is an api that is very much still in the works. the idea is that you will ultimately define your own function for each markdown element via a function (multimethod or map) that you can pass to an element’s :markdown
attribute; this will be inherited by all the other elems
below it in the display hierarchy.
checkbox made from hoplon/ui
toggle
elem ctor and state fn:
(defelem checkbox [{:keys [label] :as attrs} _]
(toggle :sh (r 1 1) :g 10 :av :mid :f 18 :fc grey (dissoc attrs :label)
(elem :s 20 :a :mid :r 5 :b 1 :bc (c 0xCCCCCC) :f 14
(s :over-on "X" :up-on "X" :down-on "X"))
(elem label)))
@jumblerg: looks good! So my understanding regarding ui is that everything is directly modifying the dom element correct? No external styling
yes, ui functions construct and set properties on the dom elements themselves instead of going through selectors
ah here it is: https://github.com/hoplon/ui/blob/master/src/hoplon/ui/attrs.cljs#L195-L199
which evaluates to "X"
when the parent is in the :over-on
, :up-on
, or :down-on
state, or nil
otherwise
i don't understand how it works exactly though, i would think that *state*
would be unbound when the cell evaluates the formula asynchronously
i'd have expected that you'd need to capture its value in the lexical scope with like (let [state *state*] (cell= ...))
and consequently evaluates when the page is loaded so it will be accessible from the children
(def ^:dynamic foo nil)
(defc bar 200)
(binding [*foo* (cell 100)]
(cell= (pr [*foo* bar])))
(swap! bar inc)
because it's global mutation you'd need to make that thread-local in a multi-threaded environment
i think the formula cell in the s state fn returns closes over the cell value in the dynamic var when the bindings are set up?
binding just sets the value, evaluates the body expressions, then resets the value back to what it was before
so if the formula is evaluated after the binding expression is done, it will see the current global value
changing as the stack grows and shrinks below its threshold as the page is evaluated
if you make a lexical binding to close over it then you have a local variable that won't be reset when the binding
expression completes
i remember poking around in the cell implementations themselves and giving myself a headache trying to figure out how to do this
i could imagine having a dynamic var that's used internally in the binding
macro to keep track of dynamic bindings
i think interactible
and selectable
conflate two ideas, actually, one being the mouse state relative to the component, and the other being the state of the component itself
my best idea so far is to have elem
s, which are stateless, and comp
s, which have *state*
.
so anything like the s
state fn uses the *state*
of the nearest parent component on the display hierarchy.
so you can declaratively specify any attribute or child based on a component’s state
so while the state identifiers might be component specific (albeit general in many cases), the state fn is not, and works everywhere
http://help.adobe.com/en_US/Flex/4.0/UsingSDK/WSA95C9644-B650-4783-B5C0-D2C7F95A23E3.html
it covers a lot of cases. many components are binary, toggleable, ie on or off, toggle buttons, radio buttons, check boxes, dropdowns, othermenus that open and close
i represent every possible state of my hoplon app with a single keyword already that appears in the path
where i can see this maybe becoming less convenient is in the case of nested components
there’s a lot of good stuff in here: https://github.com/apache/flex-sdk/tree/eec643c453a3a1bec6ea3352b0c94ec81d36b2d6/frameworks/projects/spark/src/spark/components
the “code in front” declarative skins are here: https://github.com/apache/flex-sdk/tree/eec643c453a3a1bec6ea3352b0c94ec81d36b2d6/frameworks/projects/spark/src/spark/skins
i find it interesting to think about the way we’re constructing document object models; which are, in effect, using the same techniques often used to create immutable models in oop: you get to construct the object once by passing values to the constructor, and after that, everything is read-only.
right, but in two ways that are “implementation details”, much like the internal implementation details of stm.
a. the browser modifies them internally (but this doesn’t matter since we never read from them)
much like you can have an encapsulated mvc triplet in the super-small that manages its own local state for something like a checkbox, or your entire client-side app, or even an entire system in the large where the model is the db uses mvc or cqrs