Fork me on GitHub

@piotrek indeed i got away with the .hl extension and since clojurescript 1.9.something i don't even have to differentiate between :refer-macros and :refer anymore. :refer :all is still impossible unfortunately, so we settled on referring the most commonly used functions and maintain an example file which we can copy from for new namespaces:

(ns ns.template
  (:refer-clojure :exclude [+ - * /])
    ; Establish project-wide NS aliases and refer most common symbols
    [javelin.core :as j :refer [cell cell= defc defc= cell-let with-let]]
    [hoplon.core :as h :refer [defelem when-tpl if-tpl case-tpl for-tpl]]
    [hoplon.ui :as hui :refer [elem]]
    [hoplon.ui.attrs :refer [+ - * / c r pt em px d]]
    [material.ui :as mui :refer [form-with container row paper]]
    [material.colors :as c]
    [hoplon.ui.elems :refer [box doc out mid in elem?]]



i can imagine if you are using hoplon, u might want to :refer some DOM element constructors too which u use most often, which is probably the div and i and maybe td, tr. the rest of the primitives are used a lot rarer, because u should build higher level abstractions from them and work with those instead, like we did in the material.ui ns with container, row, and paper. (there is some "rule" about this distribution, btw, that 10% of the things occur 90% of the time and the remaining 90% of possibilities are distributed over the 10% probability range. forgot the name of this "empirical law")


@piotrek btw, i have an example repo too which i use as a template for quick experiments:


Thanks @onetom , it’s all super useful


@grant: everything ui-related working ok now?


It feels like I stills have lots of holes is my knowledge, so I tend to assume it's me, not UI when I'm having trouble.


You mentioned that you were going to be moving to a more production ready stance, at least on the commits, if that includes more documentation, I'd be happy to help with a newbie perspective on sticking points.


@grant: that would be awesome, it is easy to forget all the little issues you encounter as someone getting started when you've been doing it for a while.


i know i ran into a lot of them myself back in the day (micha can attest to this), but i can't recall what the issues were. it seems pretty simple to me now.


how do we feel about watches being run in the order they were added


currently order is arbitrary


@alandipert Is there a reason that a user of javelin should know and depend on the order of watchers? Or is that a question about internal implementation that should be invisible to a javelin user?


@alandipert: that seems like a sensible guarantee to me.


I'm not sure it matters for real but o thought about it here


What I want is to know when for-tpl is done so I can scroll the text area to the bottom


Also makrs me wonder if -tpl might need gasp a configurable :after callback


If watches ran in add order, I would also no I was good, since I know Ill run after for-tpl has done stuff


derp, i can just do the scroll after i call the function that adds a line to the cell


@alandipert @micha I'm trying to dynamically change the style of an element, which means--I think--I also need to refresh the element. Here's the code for changing the style: (aset (.-style e) "color" "blue")


And here's the code that calls it and tries to do the refresh:


Any idea what I'm doing wrong here?


I only see blue when later I reuse the same elements. So my refresh is likely the problem.


(I know I'll need to set a default style later to prevent spurious styling, but that's later.)


(set! (.-style e) "color: blue;") perhaps? @laforge49


the style property of dom nodes is a string


OK, great. Then perhaps my problem is not with the refresh. 🙂


Same. When I reuse the elements in the display, some of them come up blue.


Still looks like a refresh issue @alandipert