x-data within x-for loop — inconsistently updating

[njpanderson]

Hi all — firstly, thanks for the great library!

An odd issue I've noticed — I've scoured the docs for relevant answers here and I could have still missed the blindingly obvious, but this one is driving me a bit potty so thought I'd confirm with you lovely chaps to see if I'm going mad or not. Here's the JS fiddle — I've tried to whittle this down to the smallest example I can:

https://jsfiddle.net/njpanderson/r86vxmqj/71/

Long and short is: When an x-for loop contains another x-data component, the elements within those components don't seem to update when the original object (in this case, from a store) is updated. Without the nested component, it seems to work predictably.

Note: The nested x-data component within the fiddle is of course a contrived example but there is a real use case for nesting x-data components within loops in my actual application.

From fiddling 🙄 with the jsfiddle above, it seems to only occur when an item with the same key (id) is updated (such as the label property). If an entirely new item with a new, unused key is injected (or even replaced) into the store, it updates regardless of the nested component.

Am I going mad? Is this expected, and/or is there something about this in the docs I'm simply missing?

[ekwoka]

The issue has to do with how the parent scopes are propagated downwards to the children.

Since the x-for isn't rerendering the looped item due to the key matching, the scope still contains the old item scope.

For this contrived example, the fix is simple: have the replaced items have new keys (the id field).

this should also be satisfactory for any real use case as you wouldn't realistically be replacing the array with items with the same keys but different data.

If you did, then you need a more complex key to handle differentiation for the diffing algo.

So I would say the behavior itself is exactly in spec with what someone aware of the technical implementation of alpine and how the keyed list works, but may not be obvious to people using it.

I can't imagine there is a way to handle the situation you are describing (replacing an object in an array with another object that has the same key) and having it work. The real world use case would be to update the object if you're updating it, and having unique keys if its meant to be a different object entirely.

[njpanderson]

Thanks for the answer @ekwoka — this seems to align with my initial thoughts on the matter — I had actually created a small function which essentially adds alpine specific keys to data arrays for the purposes of keeping them unique. However this doesn't feel sustainable.

this should also be satisfactory for any real use case as you wouldn't realistically be replacing the array with items with the same keys but different data.

Is this not a pretty typical use case for front-end data updated from a server side process? I could be getting the wrong end of the stick here!

The real world use case would be to update the object if you're updating it

I understand the concept here, but are you suggesting that if we're retrieving data from a server to update a list of items, that list needs to be updated entirely atomically? This is of course possible but feels like quite an important oversight in terms of documenting the management of data within an x-for loop.

[ekwoka]

If the objects themselves (presumably from a db) have an updated_at property or similar you could do

:key="`${item.id}-${item.updated_at}`"

[SimoTod]

I believe it's a bug, to be honest. There is a refreshScope function but I believe it doesn't work with nested properties.

[SimoTod]

Scratch that. The x-data is still referencing the old object. Maybe the refresh scope could also update the inner data stack but not sure how easy it could be. For now, it's probably easier to generate a different key server side when your data is updated.

[njpanderson]

@SimoTod / @ekwoka — I've looked deeper into this and the behaviour seems to make sense, I just need to adjust my expectations regarding the way keys in alpine operate. I've solved this locally by using object-hash to generate a hash of collection items as a key property on the front end on any applicable incoming data. This method has actually solved and simplified a few portions of my app which were using other techniques to ensure state updates were correctly reflected.

Code below for anyone interested:

import hash from 'object-hash';

// ...

/**
 * Adds hash based keys to a collection of objects being inserted into an
 * Alpine store for templating.
 *
 * @see https://github.com/alpinejs/alpine/discussions/3372
 * @param {array} data
 */
export function addKeysToCollection(data) {
	return data.map((item) => {
		if ('key' in item)
			debug.warn('Item already contains `key` property and it has been overridden', item);

		return Object.freeze({
			...item,
			key: hash(item, { algorithm: 'md5' })
		});
	});
}

[billksun]

I just ran into this issue as well. Solved it by using UUIDs for the keys, generated using the built-in Crypto method.

In my case, I was creating a search filter for a data set. The data set has nested arrays, and that's when this issue surfaced. To update the nested array, I replaced the original nested array with a new filtered array, with the key for the parent object unchanged, and that's when I noticed the view never updates, even though the data model updated correctly.

As I am only doing filtering, creating new unique keys every time I run the filter is fine and it is inline with the functional approach that I am using (creating new objects/arrays instead of mutating existing ones).