Brr-lwd; reactive attributes have a poëted behavior

[panglesd]

Reactive attributes in brr-lwd have a strange semantic. See for instance this example (also available here)

let ui =
  let v = Lwd.var true in
  let click= Elwd.handler Ev.click (fun _ -> Lwd.update (not) v) in
  let button = Elwd.button ~ev:[`P click] [`P(El.txt' "Salut")] in
  let at1 =
    let$ b = Lwd.get v in
    if b then At.name (Jstr.v "name1")
    else At.title (Jstr.v "title1")
  in
  let at2 =
    let$ b = Lwd.get v in
    if not b then At.name (Jstr.v "name2")
    else At.title (Jstr.v "title2")
  in
  let el =
    Elwd.div ~at:[`R at1; `R at2] [
      `P (El.txt' "Try clicking the button and see how the attributes change.");
    ]
  in
  Elwd.div [ `R el; `R button ]

Basically at1 and at2 are two reactive attributes, depending on a reactive boolean. They set name or title depending on the boolean, but never the same (if b is true, at1 sets name and at2 sets title, if b is false, at1 sets title and at2 sets name)

This results in attributes being canceled when updating the boolean:

Peek.2026-02-14.16-52.webm

(expected behavior is to have (name=name1 AND title=title2) OR (name=name2 AND title=title1), not half of that)

It is tricky to fix. We could have the key not be reactive, but we probably have the same problem with sequences? We could have "absent" values not be unset, but have values as options (and None means unsetting). Those options are all breaking.

And I'm opening this as I'm working on reactive styles/properties. Especially in the prop values, unsetting when a prop is not present anymore is questionable.

[voodoos]

Would it be too restrictive to simply assume and document (and maybe enforce at runtime instead of the current undefined behavior) that users should not modify the same attributes multiple time in the same At.t Elwd.col ?

Your example is somehow reasonable, but most other use cases seem wrong anyway.

[panglesd]

Yeah, it's just good to be conscious about this limitation.

As I think about it, I would have preferred that `R were of Jstr.t * (Jstr.t option Lwd.t) instead of of (Jstr.t * Jstr.t) Lwd.t to make the problem above less likely. But that is fine.

[voodoos]

And in fact, the docstring does state:

If [at] specifies an attribute more than once, the last one takes over with the exception of {!At.class'} whose occurences accumulate to define the final value.

Maybe we could simply add that this also means that removing the last one,results in an unset attribute.