This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-02
Channels
- # adventofcode (5)
- # arachne (2)
- # bangalore-clj (1)
- # beginners (8)
- # boot (195)
- # cider (28)
- # cljs-dev (35)
- # cljsrn (4)
- # clojure (295)
- # clojure-brasil (5)
- # clojure-gamedev (2)
- # clojure-greece (2)
- # clojure-korea (13)
- # clojure-russia (60)
- # clojure-spec (58)
- # clojure-uk (92)
- # clojurescript (31)
- # clojurex (4)
- # css (1)
- # cursive (13)
- # datomic (40)
- # devcards (2)
- # emacs (17)
- # events (1)
- # flambo (3)
- # garden (9)
- # hoplon (31)
- # jobs (3)
- # klipse (1)
- # lein-figwheel (1)
- # london-clojurians (1)
- # luminus (2)
- # mount (36)
- # off-topic (13)
- # onyx (8)
- # pamela (1)
- # pedestal (1)
- # planck (3)
- # proto-repl (16)
- # protorepl (11)
- # re-frame (78)
- # reagent (4)
- # rethinkdb (6)
- # ring-swagger (1)
- # specter (8)
- # untangled (10)
- # vim (1)
@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 [+ - * /])
(:require
; 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: https://github.com/onetom/boot-reloadable-hoplon
@piotrek regarding cursive interop u should know about https://clojars.org/onetom/boot-lein-generate more reasoning here: https://github.com/cursive-ide/cursive/issues/692#issuecomment-257907140
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
in javelin?
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")
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
Still looks like a refresh issue @alandipert