x-if seems buggy ('sticky')? #2540

tbjolset · 2021-12-28T14:16:52Z

tbjolset
Dec 28, 2021

x-if seems to be a nice way to do component based design: use x-if to only evaluate/render a block if the element exists, otherwise ignore the object/component. However, there seems to be some weird behavior that this works initially if the object in question is null, but if you set the object non-null, then back to null, the x-if template insists on trying to evaluate the object. Easier to see from an example:

<head>
  <script src="//unpkg.com/alpinejs" defer></script>
</head>

<body x-data="{ user: null }">
  <template x-if="user">
    <div>
      <div x-text="'user: ' + user.name"></div>
      <button @click="user = null">Log out</button>
    </div>
  </template>
  <template x-if="!user">
    <button @click="user = { name: 'lebowski' }">Log in</button>
  </template>

</body>

Initially this works perfectly: The x-if template doesn't try to render/evaluate the logged in block, since the user is null. When tapping log in, it also shows the username correctly. However, after tapping log out, the x-if template now renders the log in div again, as it should, but also tries to evaluate user.name, for some reason, leading to uncaught type errors.
alpinejs:1 Alpine Expression Error: Cannot read properties of null (reading 'name')

kylethielk · 2021-12-31T20:45:53Z

kylethielk
Dec 31, 2021

hey @tbjolset unfortunately this is a bug. Its been reported a few other times as well see #2296 #1837 #1917

Essentially x-if does not currently guarantee that any child expressions will not run when x-if evaluates to false.

11 replies

kylethielk Jan 4, 2022

Great point @SimoTod. I've updated PR to include a fix for x-for case as well.

janzikmund Sep 27, 2022

@kylethielk - thanks so much for #2556, it looks like for some reason the bug still shows up if there is x-modelable directive used within the <template>.

Please see the attached sample code below, I also made a fiddle

<html>
<head><script src="https://unpkg.com/alpinejs" defer></script></head>
<body>
    <div x-data="{ user: { number: 5 }}">
        <template x-if="user">
            <div>
                <div x-data="{ count: 0 }" x-modelable="count" x-model="user.number">
                    <button @click="count++">Increment</button>
                </div>
                Number: <span x-text="user.number"></span>
            </div>
        </template>
        <button @click="user=null">remove user</button>
    </div>
</body>

The weird thing is, that if you click the remove user button as first, you get the errors. While if you at least once click the increment and then click remove user, the errors don't show up anymore. Do you have any idea what's behind this?

kylethielk Sep 27, 2022

Hi @janzikmund unfortunately x-modelable was released after I pushed my fix so I am not familiar with its inner workings. It might be worth looking to see if my changes are applicable to the x-modelable directive: https://github.com/alpinejs/alpine/pull/2654/files#diff-af620dcff7cc59b1c7efe7e9cef800c8622ab637447075c1cd725d3d8ab8e306

janzikmund Sep 28, 2022

@kylethielk - thanks, I checked your code, but I still wasn't able to pinpoint the problem. Apparently it's caused by the effect(() => innerSet(outerGet())) line in x-modelable directive. If I remove it, the errors are not triggered anymore, but obviously the value from x-model isn't transformed.

Strange thing is, the error doesn't only show up for the element with x-modelable, but also for all the others in the same x-if; the single x-modelable is enough to start raising it for all other elements. See my updated fiddle - the error shows for all three fields - count, name and country.

I tried to check and fix it in x-if similarly to what you did, only the dequeueJob didn't seem to work and the effect still showed up in console, so I added a different code as per below. Now the _x_effects queue in console is empty, but still the errors show up the same, not sure where else they can be wired:

el._x_undoIf = () => {
  walk(clone2, (node) => {
    if (!!node._x_effects) {
      node._x_effects.forEach(dequeueJob);

      // one way
      node._x_effects.forEach((effect) => {
        node._x_effects.delete(effect);
      });
      // another way, seems to do the same
      node._x_effects.clear(); 
      // shows empty _x_effects, but still the errors are thrown
      console.log(node, node._x_effects);  
    }
  });
  clone2.remove();
  delete el._x_currentIfEl;
};

Also, this _x_effects clean up is only happening on the element with x-modelable, while the errors are thrown for all the other fields as well, so the problem must probably lie somewhere else.

janzikmund Oct 24, 2022

For anyone interested, I haven't found a way to fix this in Alpinejs, but the easiest way to circumnavigate the problem was to bind the x-if on a different variable than the one assigned to x-model on the modelable field, then no problem seems to happen anymore. For my example above, the modified code would look something like this:

<html>
<head><script src="https://unpkg.com/alpinejs" defer></script></head>
<body>
    <div x-data="{ userVisible: true, user: { number: 5 }}">
        <template x-if="userVisible">
            <div>
                <div x-data="{ count: 0 }" x-modelable="count" x-model="user.number">
                    <button @click="count++">Increment</button>
                </div>
                Number: <span x-text="user.number"></span>
            </div>
        </template>
        <button @click="userVisible=false;user=null;">remove user</button>
    </div>
</body>

Rock1raw · 2025-02-20T18:52:55Z

Rock1raw
Feb 20, 2025

V

1 reply

ekwoka Feb 21, 2025

If you bumped this for having the same issue, it was fixed already.

Uh oh!

x-if seems buggy ('sticky')? #2540

Uh oh!

Uh oh!

Replies: 2 comments · 12 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 2 comments 12 replies