Fork me on GitHub
#hoplon
<
2017-10-01
>
thedavidmeister03:10:53

:baz/class overrides :class rather than adding to it

thedavidmeister03:10:55

actually i'm not aware of a good way to build up classes on an element without juggling data structures 😞

thedavidmeister03:10:02

i often find myself wanting to do something like this

thedavidmeister03:10:05

(defelem my-basic-foo [_ _] (div :class "foo"))
(defelem my-edge-case-foo [_ _] (my-basic-foo :edge-case/class "edge-case"))

thedavidmeister03:10:26

and get back a div.foo.edge-case

flyboarder03:10:38

@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

flyboarder03:10:58

It makes sense that it overrides it

thedavidmeister03:10:08

that's a lot of boilerplate...

flyboarder03:10:16

As it's a namespaced version of the generic class attribute

thedavidmeister03:10:38

well no, it makes sense that :class overrides :class but i wouldn't expect :foo/class to override :bar/class

flyboarder03:10:49

I would depending on the implementation, :foo/class may/may not preserve the existing class

flyboarder04:10:02

Same with :bar/class

thedavidmeister04:10:32

the default implementation

thedavidmeister04:10:05

it seems a lot more useful to be able to merge classes than have later calls blow away earlier calls

flyboarder04:10:35

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.

thedavidmeister04:10:59

you can test for your expectations using the implementation provided by hoplon

thedavidmeister04:10:24

this isn't about testing the lib

thedavidmeister04:10:31

this is about what hoplon does

flyboarder04:10:46

Right the default is a "set" style

thedavidmeister04:10:11

yes, but it calls that "set" once for each different :x/class

thedavidmeister04:10:07

i could imagine a hoplon implementation that tracks the classes used for each ns and has the merge behaviour in it

thedavidmeister04:10:09

using the same lib

thedavidmeister04:10:06

it already has some logic around setting true/`false` to add/remove classes, so it could probably extend that

flyboarder04:10:46

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

thedavidmeister04:10:41

that's what i'm thinking

thedavidmeister04:10:47

that it just doesn't touch any classes it doesn't know about

flyboarder04:10:51

Yep I'm on track with that

flyboarder04:10:11

Can you open a ticket to remind me :)

thedavidmeister04:10:32

"merging" might even be more sophisticated than what i'm suggesting 😛

thedavidmeister04:10:44

it's really just about not blowing away unrelated classes that already exist