fix: publication site selection and action label flicker - #31
Merged
Conversation
dataset.publicationSites is a list of "<type>:<id>" strings that itemValue resolves into an object through the context. With no itemKey, json-layout fell back to using that resolved object as the key, and vjsf re-derives the key from the resolved value (valueComparator, prepareSelectedItem) rather than from the raw item. On that second pass the item is already an object, so context.publicationSites[item] returned undefined and every item ended up with the key "undefined" — the comparator then reported every item as equal to the current selection, leaving only the first one selectable. The title collapsed to "undefined (undefined)" the same way. Give the node an explicit itemKey and make both expressions accept either the raw string or the resolved object, so the key survives the round-trip. This predates the vuetify 4 migration: valueComparator and prepareSelectItem are identical in vjsf 3.26 / json-layout core 2.4.
The plugin overrides actionLabels through its own i18n messages, merged in a watcher once the plugin request resolves — after the catalog one. Since the schema computed reads t(), that merge gave it a new identity, and vjsf rebuilds its whole state tree whenever the schema changes identity: the form appeared with the generic labels, then tore itself down and came back with the plugin's. Wait for the merge before building, so the form is built once, already carrying the final labels. Also stop writing defaultAction from inside the schema computed: side effects in a computed are a reactivity hazard. availableActions and defaultAction become computeds of their own, which reads better and drops the hidden ordering between them and the schema.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes to step 1 of the new publication form.
itemValuebut noitemKey, so the resolved object became the key. vjsf re-derives the key from that resolved value (valueComparator,prepareSelectedItem), and on that passcontext.publicationSites[item]returnsundefined: every item collapsed to the key"undefined", the comparator reported them all equal to the current selection, and only the first option was ever selectable — the title collapsed to"undefined (undefined)"the same way. Both expressions now accept either the raw"<type>:<id>"string or the resolved object.actionLabelsthrough its own i18n, merged once the plugin request resolves, after the catalog one. The schema computed readst(), so that merge gave it a new identity, and vjsf rebuilds its whole state tree whenever the schema changes identity: the form appeared with the generic labels, then rebuilt with the plugin's. It now waits for the merge and is built once, already carrying the final labels.defaultActionalso stopped being written from inside a computed.Why: both reported on staging — only the first publication site was clickable, and the labels flickered between the generic and the plugin-overridden ones.
Heads-up:
valueComparatorandprepareSelectItemare identical in vjsf 3.26 / json-layout core 2.4, and the migration touched neither the page nor the schema.itemKeyuses the site'surl— the only field present both in the raw item and in the resolved object. Two publication sites sharing a URL would collide.