Skip to content

Discussion for v2: make the attrs take precedence over what the selector provides #2172

@pygy

Description

@pygy

Currently,

m("foo[bar=baz]", {bar: "qux"})

results in:

{tag: "foo", attrs: {bar: "baz"}}

In other words, the selector has precedence over the attrs. This kind of made sense as an optimization prior to this PR, (so that classes would end up set on className which is faster to set according to Leo). But it may be useful to let the attrs take precedence, so that a common selector string can have its attrs overruled in some circumstances.

Once we have that, however, comes the question of null-valued attrs:

As far as m.render() is concerned, an attr with a nullish value is equivalent to a lack of attribute. How should m() work in similar situations?

Should m("foo[bar=baz]", {bar: null}) produce {bar: "baz"} or {bar: null} as attrs?

The former is easier to document, the the latter is more powerful, especially In a ES6+ world, where you can do {...(condition ? {bar: null} : null)}.

Thoughts? This is related to #1773 which I had overlooked for v2.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type: Breaking ChangeFor any feature request or suggestion that could reasonably break existing code

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions