matthewp / corset

Declarative data bindings, bring your own backend.

Home Page:https://corset.dev/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow multi-binding properties on the left side

matthewp opened this issue · comments

Suggestion from @propjockey; managing multi-binding properties is a bit cumbersome in CSS and in Corset. In Corset we try to allow a selector to override only the bindings that it sets and not all of them. There are likely bugs here though.

What if we changed it so that the type (the first value) was part of the property instead of in the value. So for example:

.profile {
  class-toggle: admin var(--is-admin);
}

Becomes

.profile {
  class-toggle[admin]: var(--is-admin);
}

Another example for events:

.login-form {
  event[submit]: var(--handler);
}

One use-case we want to preserve from the current array form is to allow dynamic types. For example you can do:

#app {
  class-toggle: var(--mode) var(--mode-enabled);
}

The above will allow you to change the class name being toggled by setting --mode. An example where you might do this: if you have light/dark mode and toggle them by setting a class name either .dark-mode or .light-mode. Using --mode allows you to choose that class name dynamically rather than making either light or dark the default.

With the left-side approach we could still allow this dynamism like so:

#app {
  class-toggle[--mode]: var(--mode-enabled);
}

The presence of -- in the type would signal that it is a var; normal var lookup rules would apply.

Another use-case for using --prop is if the type is not a string. For class-toggle, attr, attr-toggle, data, and prop they are always strings. For events there's a chance that Symbols might eventually be allowed as event names. There wouldn't be a way to set the event name in the short syntax if only identifiers were allowed.

We might also allow for JS insertions here, I could see:

#app {
  event[${Symbol.for('some-event')}]: var(--handler);
}

Although I don't know how we would know when one overrides the other, so I would probably put off allowing this for now.


One exciting thing about potentially doing this, is it would possibly solve #52, as identifiers-as-strings are mostly necessary for the "type" of a multi-binding property. Moving to this method would take away that need. Freeing us up to implement special identifiers like initial.

I'm thinking that the name for the thing between the bracket could be called a property modifier, in that it modifies the meaning of the property and specifies what to bind to.

These should be called a property key, since that's what they are.