Limits of jQuery .data() cache reconciliation with data-* attributes

Direct Answer

Treat the current data-* attributes as authoritative after a rollback or markup replacement. The jQuery .data() cache is not durable: the first read pulls an attribute into the cache, and .html() or .replaceWith() run cleanData() on removed nodes, discarding that cache. Explicit re-initialization from attributes is the supported way to rebuild state on new elements.

Confirmed Behavior

• First .data('key') read copies the matching data-key attribute into jQuery's per-element cache; later .attr('data-key', ...) edits are ignored for that key.
• .data('key', value) writes only to the cache and never updates the attribute.
• .html(), .replaceWith(), .empty(), and .remove() invoke cleanData(), which clears cached data and removes handlers from discarded nodes.

Detection

There is no public API to ask whether a key was already cached on a removed node. The internal $._data(elem, 'data') can inspect the cache, but it is undocumented and may break between versions, so use it only for debugging. Before replacement, record which keys matter; after replacement, read them from the new markup's attributes.

Resolution Steps

1. After .html() or .replaceWith(), re-read each expected key from the new element's data-* attributes and call .data('key', value) to populate the cache.
2. Re-bind handlers on the new elements, or attach one delegated handler to a stable ancestor so replacement does not require re-binding.
3. Use .detach() only if you intentionally move an existing node and need to keep its cache and handlers; it does not replace re-initialization after discarded markup.

Verification

const el = $('#target');
el.attr('data-role', 'original');
el.data('role'); // pulls attribute into cache
el.attr('data-role', 'changed');
console.log(el.data('role')); // still 'original' in jQuery 3.x
console.log(el.attr('data-role')); // 'changed'

Assumption: this describes jQuery 3.x behavior. Verify cleanData() behavior in older or customized builds before relying on it.

Missing diagnostic detail: are replacement nodes newly created, or are existing nodes detached and reattached? Detached nodes retain their cache, which changes the recommendation.