This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-01
Channels
- # beginners (15)
- # boot (3)
- # cider (10)
- # clara (2)
- # cljs-dev (19)
- # clojure (31)
- # clojure-uk (9)
- # clojurescript (60)
- # core-async (1)
- # datomic (10)
- # docs (4)
- # fulcro (5)
- # hoplon (33)
- # juxt (1)
- # luminus (1)
- # off-topic (3)
- # om (20)
- # parinfer (2)
- # portkey (61)
- # re-frame (6)
- # reagent (39)
- # shadow-cljs (18)
- # spacemacs (4)
- # specter (8)
@flyboarder well it fails 😛
:baz/class
overrides :class
rather than adding to it
actually i'm not aware of a good way to build up classes on an element without juggling data structures 😞
i often find myself wanting to do something like this
(defelem my-basic-foo [_ _] (div :class "foo"))
(defelem my-edge-case-foo [_ _] (my-basic-foo :edge-case/class "edge-case"))
and get back a div.foo.edge-case
@thedavidmeister I'm not sure it should work that way, usually my edge cases grab the existing class before modifying it, that's specific to the edge attribute tho
It makes sense that it overrides it
that's a lot of boilerplate...
As it's a namespaced version of the generic class attribute
well no, it makes sense that :class
overrides :class
but i wouldn't expect :foo/class
to override :bar/class
I would depending on the implementation, :foo/class may/may not preserve the existing class
Same with :bar/class
the default implementation
it seems a lot more useful to be able to merge classes than have later calls blow away earlier calls
That would depend on the CSS lib tho wouldn't it? My thought is that we just can't test for these things and the attribute providers should have proper tests for their implementation. However I see the value in merging the data.
you can test for your expectations using the implementation provided by hoplon
this isn't about testing the lib
this is about what hoplon does
Right the default is a "set" style
yes, but it calls that "set" once for each different :x/class
i could imagine a hoplon implementation that tracks the classes used for each ns and has the merge behaviour in it
using the same lib
it already has some logic around setting true
/`false` to add/remove classes, so it could probably extend that
Yeah, ok so that makes sense, if I use a non hoplon element with a :class call I would expect any existing classes to remain, so we should probably be merging
mmm basically
that's what i'm thinking
that it just doesn't touch any classes it doesn't know about
Yep I'm on track with that
Can you open a ticket to remind me :)
sure thing
"merging" might even be more sophisticated than what i'm suggesting 😛
it's really just about not blowing away unrelated classes that already exist