class and style are not formatted correctly when set inside object as x-bind="{ style: {...}, class: {...} }"

[JuroOravec]

Came across what I believe is a bug:

When I define HTML like so:

<div x-data="{
  data: {
    style: {
      color: 'red',
    },
    class: {
      hidden: true,
    },
  },
}" x-bind="data">
    bug
</div>

Then the rendered HTML is

<div
  x-data="{
    data: {
      style: {
        color: 'red',
      },
      class: {
        hidden: true,
      },
    }
  }"
  x-bind="data"
  style="[object Object]"
  class="[object Object]"
>
    bug
</div>

The style and class attributes are not rendered properly.

Instead of [object Object], it should be

style="color: red;"
class="hidden"

Basically, it looks like style and class are not treated as special attributes when using x-bind="{...}"

[SimoTod]

The docs is not super clear but the object syntax is only supported when binding class and style directly (x-bind:class and x-bind:style). It may be possible to adjust the implementation to support it for the generic case but it needs to be added.

[JuroOravec]

Hey @SimoTod thanks for reply!

I can make a PR for that. I'm new to the codebase, though, so need some sanity check:

I found the relevant code here and here.

My guess is that in the code of the second link (applyBindingsObject), we'd want to call bind, if the keys are style or class.

How should I approach this when it comes to managing lifecycle? E.g. for :class and :style, the change is made within mutateDom, and there's also cleanup call afterwards. Should I call _x_undoAddedClasses/ _x_undoAddedStyles in the returned function?

[SimoTod]

I wouldn't go down the route of trying to use low level functions. The cases in the initial posts were not meant to be supported so if the implementation is too complex, it's not likely to be approved

The code is already converting the standard attributes (such as class and style) to x-bind:class, x-bind:style, etc and Alpine will then process the directive singularly (so the object syntax is already kind of supported). The problem is that line 51 casts everything to a string and it converts your object to [object Object].

The easiest way would be to make line 51 understand properly what type of value you are binding so the directive is processed correctly. I think it could be as simple as using a function (which alpine would resolve with the real type and handle when processing the x-bind:... directive) instead of trying to convert it to a string in there.

Now, my gut feeling is that it would just magically work for the previous cases as well (I changed it quickly on my local branch and all tests are passing) but if it doesn't (or you want to minimise the risk of breaking something), you can have something like value: (check if the value is an object) ? () => attribute.value : "${attribute.value}"`

You'll need to add some tests for that as well.

[JuroOravec]

Thanks for the guidance! Really appreciate that 🙏

As for tests, I haven't searched yet where this feature is tested, and I just briefly saw that there are both unit with jest and integration with I think it was cypress. Which tests should I write for this?

[SimoTod]

No worries, the tests are written using cypress. jest tests are deprecated as far as I know.

Once you've implemented it, you may want to update the documentation as well (it's in the same repo) because currently for x-bind, it says: "The object values are either plain strings, or in the case of dynamic Alpine directives, callbacks to be evaluated by Alpine." (See https://alpinejs.dev/directives/bind#bind-directives).

[ekwoka]

make your binding object keys be :style and :class instead, so that it invokes the directive handlers

[ekwoka]

Right a function or string is necessary...

So a function that returns the object would work. That must have been what I was thinking...

Since it would allow reactivity.

On alpines side the options are to have a functionfromobject or a special case in x-bind (for object expression) or in the bind function x-bind calls...

[SimoTod]

Dunno, I think it would be nice and would make more sense if it was working like VueJs instead of expecting people to know that they can/must use a function in those cases.
See https://codepen.io/SimoTod/pen/xxvLazY
the only line I changed is

value: `${attribute.value}`

to

value: () => attribute.value

[ekwoka]

one problem is it would be a breaking change for places people currently use a string expression there.

[SimoTod]

string expressions work as well (I've covered a few cases in the codepen). All existing tests pass, too.

[JuroOravec]

Hey, so for my project, I wrote a function that receives the attributes, and wraps them in functions (what @SimoTod suggested), prefixes the keyswith : (for keys that don't start with @ or x- and who's values are not functions already). And this seems to work well.

So with that in mind, and also what @ekwoka said about potential breaking change, then I'd suggest to go with @SimoTod's original suggestion, which was to use

value: (check if the value is an object) ? () => attribute.value : "${attribute.value}"`

Having an object for value for one of the entries in x-bind is IMO currently an undefined behavior, because at best it leads to HTML like this:

<div class="[object Object]">

Which nobody should be using intentionally.