This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-30
Channels
- # aws (1)
- # bangalore-clj (2)
- # beginners (64)
- # boot (29)
- # cider (4)
- # clara (14)
- # cljsjs (22)
- # cljsrn (24)
- # clojure (248)
- # clojure-austin (5)
- # clojure-berlin (1)
- # clojure-china (5)
- # clojure-france (1)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-korea (6)
- # clojure-russia (76)
- # clojure-spec (2)
- # clojure-uk (59)
- # clojurescript (67)
- # cursive (12)
- # datascript (6)
- # datomic (126)
- # defnpodcast (2)
- # devcards (1)
- # docker (1)
- # events (2)
- # hoplon (14)
- # leiningen (1)
- # luminus (2)
- # midje (2)
- # mount (1)
- # off-topic (4)
- # om (6)
- # onyx (8)
- # parinfer (2)
- # perun (6)
- # proton (5)
- # re-frame (41)
- # reagent (6)
- # ring-swagger (3)
- # rum (1)
- # spacemacs (10)
- # specter (12)
- # yada (25)
@jumblerg thanks! i will try still today.
in the meantime we started to work out form use-cases on this branch: https://github.com/addplus/ui/tree/forms
and we hit an old issue which is still present to my surprise: https://github.com/hoplon/ui/issues/9
i've updated our reproduction case in https://github.com/addplus/tpl-example to use hoplon/ui 0.1.0-SNAPSHOT but the issue is still there.
since you were reworking bind-in!
not to bother handling rest arguments, i think that might solve this issue,
so it could go into master already, no?
the use-case where this is an issue is when we want to show a red border around a form input field if there are validation errors associated to it.
if you think we shouldn't upgrade bind-in!
yet, then i would submit a fix for the current implementation
@jumblerg just compared hoplon/hoplon/master
with jumblerg/hoplon/optimizations
and with boot test -e
, every option off in timeline, i get 1.28s vs 1.20s only on my addplus/ui/perf
branch
(im on the revert vflatten
commit though. not sure if that's the right one)
@laforge49: ran across your web workers slides and materials, very cool and helpful! thanks
@micha: given a task like this in my build pipeline:
(cljs :optimizations o :compiler-options {:elide-asserts true})
and the following task-options:
(task-options!
cljs #(assoc-in % [:compiler-options :language-in] :ecmascript5-strict))
can you see any reason why the :ecmascript5-strict
keyword should not be applied to the :language-in
property of the :compiler-options
map?seems pretty obvious now that i think about the implementation, which i assume curries the cljs function with a call to partial or something like that.