Using $store with x-data

[asbjornu]

I found myself in a situation where I wanted to reuse much of a navigation component on two different places in the HTML document and thought I could just do x-data="$store.navigation" to access the navigation store's properties both places. That, however, lead to the error described in #1940:

Uncaught TypeError: can't redefine non-configurable property "$nextTick"

Using x-data="$store.navigation" worked when there was only one occurrence of it, but when I added the second, the above error started appearing. I ended up removing x-data in both places and referencing $store.navigation.* everywhere I needed to access one of its properties or methods.

My takeaway here is that it would be nice if Alpine would either:

1. Yield a more intuitive error message when this happens.
2. Make it possible to use $store with x-data more than once.

[ekwoka]

There is absolutely no reason to do such a thing.

X-data is for local components that have their own state.

Store is for globally shared data.

[asbjornu]

I understand that. But it does make for more legible code. Two things make the code more verbose and less elegant (imho) by not scoping a component to the Store. Example:

<nav x-data="$store.navigation">
  <ul>
    <li x-show="!isFirstPage"><a href="#" @click.prevent="back">Back</a></li>
    <li x-show="!isLastPage"><a href="#" @click.prevent="next">Next</a></li>
  </ul>
</nav>

Versus:

<nav>
  <ul>
    <li x-show="!$store.navigation.isFirstPage"><a href="#" @click.prevent="$store.navigation.back($el)">Back</a></li>
    <li x-show="!$store.navigation.isLastPage"><a href="#" @click.prevent="$store.navigation.next($el)">Next</a></li>
  </ul>
</nav>

Not only does the latter example need to fully qualify $store.navigation, it also needs to change the function reference of back and next into back($el) and next($el), because this (for some reason) gains another meaning when $store is fully qualified. To elaborate, say back() originally did something like the following:

back(event) {
  const element = event.target;
  this.manipulateElement(element); // Works when $store.navigation is scoped with x-data
},
manipulateElement(element) {
  // Manipulate element
}

The call to this.manipulateElement() stopped working when I fully qualified $store, for some reason. Thus I had to rewrite the function to:

back(element) {
  this.manipulateElement(element);
} // …

And invoke it with $el as an argument. Is this behavior intentional?

[ekwoka]

this.$el should work, but the other function wouldn't

But I'd also be even more shocked and confused about what manipulate element is doing in this case. Major code smell to me.

you can make the calling a bit cleaner with just a custom magic

Alpine.magic('nav', ()=> Alpine.store('navigation'))

then just do $nav.next($event) or whatever

But yeah, major code smell.

Why does the $el need to be accessed at all for a next button? Is is local scoped or global scoped? If you have two of these global navigation components, why do they need reference to their local elements?

And why are the tags a instead of button?

It begs many many questions.

[asbjornu]

The code samples are just examples reduced to what's relevant to this discussion. Whether the navigation elements should be a or button depends on the context. If the navigation has a server-driven fallback, a makes perfect sense (but of course with something like href="?page=4" instead of href="#").

The reason $el was accessed was to add a few properties to the navigation element. I agree that might be a code smell and should be replaced by x-bind attributes in HTML. But from your answer, I gather that the change in behavior of this between the two uses I've shown is intentional, which would still beg the question of how the DX of this deemed wrong usage can be improved. Thoughts?

[ekwoka]

I'm not sure if it should be...

If you really must

const nav = Alpine.reactive({
  next(){},
  back(){}
})

Alpine.data('navigation', ()=>nav)

Will work how you want.

[asbjornu]

Thanks for the suggestion! 🙌🏼 I've accepted that I can't use $store the same way as $data, so I've rewritten the component to now fully qualify $store in every reference to it and also replace the use of $el with x-bind.

[SimoTod]

A better error message and a mention in the documentation is probably the right path. You can't really use a $store in x-data in that way.

If you put it as a root object, as you saw, alpine tries to inject the magic twice, leading to an error. If it didn't error, magic like $el and $root would be wrong because they would point to the wrong html element in one of the 2 components. Using it for one component works by chance but it may lead to unexpected behaviors if you start using the store sub properties somewhere else.

If you put it in a property, it's even more worst. One may think that it works but in reality you are reassigning the property of the single component, non the global store so the component won't stay in sync. In this case, you either get something you didn't expect or, if that what you wanted to achieve, you should have use alpine.data. See https://codepen.io/SimoTod/pen/WNWwKep

[ekwoka]

depends on what you mean by "globally scoped replacement".

the Store is a reactive object/value available in all components and to outside JS.

That's what it is.

data represents the local context of a specific component, which is also a reactive object, but that is inherently bound to elements in the DOM.

for some common reuse values (for example, a global Cart store, and a local cart drawer component) defining getters on the component can reflect onto the store.

like

Alpine.data('cartDrawer', () => ({
  get cartItems() {
    return Alpine.store('cart').items
  }
})

This can help abstract an isolate the access to the stores.

Or the aforementioned reusable Reactive object...but that's also a code smell....

[asbjornu]

@ekwoka, right. I feel there's some dissonance between what the documentation claims $store to be, your statement "the Store is a reactive object/value available in all components and to outside JS" and the behavior I'm experiencing. Please have a look at this Codepen example.

[ekwoka]

You need to put the () otherwise it will run the function with this being the local data stack and not the store.

[asbjornu]

@ekwoka, ah, of course! 🤦🏼‍♂️ Yep, it now works. Thanks! 🙏🏼

[SimoTod]

Yes, they are interchangable as ekwoka said, the limitation is that you shouldn't use the store inside x-data as you tried to do at the beginning.