This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-22
Channels
- # bangalore-clj (6)
- # beginners (110)
- # boot (49)
- # cider (13)
- # cljs-dev (35)
- # cljsrn (5)
- # clojure (145)
- # clojure-conj (3)
- # clojure-dev (60)
- # clojure-italy (2)
- # clojure-nl (3)
- # clojure-russia (3)
- # clojure-serbia (1)
- # clojure-spec (116)
- # clojure-uk (58)
- # clojurescript (235)
- # cursive (14)
- # datascript (7)
- # datomic (31)
- # dirac (144)
- # emacs (1)
- # events (1)
- # hoplon (12)
- # leiningen (11)
- # luminus (60)
- # lumo (19)
- # off-topic (18)
- # om (74)
- # onyx (5)
- # pedestal (13)
- # precept (3)
- # re-frame (3)
- # reagent (15)
- # remote-jobs (7)
- # ring-swagger (25)
- # rum (1)
- # untangled (53)
- # vim (3)
@flyboarder oh ok nice, so it's an "opt in" feature at this point?
@jjttjj don't you have to configure your dev tools to display debug level console logs?
@thedavidmeister correct, runtime specs are always opt in
Macro specs happen at expansion time
yeah i think this additional structure would make things easier to test
and just generally predict the behaviour of too
but it also might introduce new boilerplate too
like, using :toggle
as an example, I can currently pass it any truthy value and not worry too much about it, in the new system i have to explicitly ensure that i'm passing true
or false
and even nil
is not OK
Yes you are correct, although just like the attribute providers, you can always override the defaults, also nil should always be used to prevent an attribute from being applied IMO
@thedavidmeister I see what you mean about nil
also not being ok, I'll refactor the specs to be nil-able.
@flyboarder yeah, if i send through nil
i don't want to have to cast it to false
every time
Right nil is always valid for the removal of the attribute