Related Work reached via View button may display incorrect dropdown values

[rhigman]

This is another bug caused by jgthms/bulma#3390, related to #228/#229, introduced under #325.

Each item in a Work page's Related Works list has a View button allowing the user to navigate directly to the Work (similarly to the Publications list). Because the Work component is already loaded for the current Work, the page is not refreshed/recreated, but the details of the newly-selected Work are instead retrieved from the database and loaded into the existing component. This is currently the only instance where a user can navigate directly from one instance of an object to another instance of the same object.

Because Works have some dropdown values (e.g. Work Type, Work Status, Imprint), this leads to us potentially changing the underlying <selected> values of these dropdowns via code rather than through the interface. This means we may hit the Bulma bug whereby the displayed dropdown selection can go out of sync with the underlying value.

As an example, in testing, I navigated from a monograph with test imprint "C" to a related edited book with test imprint "H". Whereas inspecting the dropdowns with browser developer tools showed that they were correctly set to "edited book" and "H", their displayed values were "Book Chapter" and "Select Imprint" (the topmost values in the list).

(This did not occur until after a few rounds of clicking between related works, and is not consistently repeatable. The status for both happened to be "Inactive", and this was displayed correctly throughout. Also of interest, I tried clicking "Save" at this point, and was given the GUI warning "Please select an imprint", although an imprint was underlyingly selected.)

It is not clear why this issue does not appear to arise when a component is initially created, as this process uses similar logic of creating a default Work object and then updating it (including updating its dropdown selections) as soon as the correct database values are retrieved.

[rhigman]

#368 is also affected by this Bulma bug (jgthms/bulma#3390), as it introduces code which changes the underlying value of the Publication modal "Publication Type" dropdown. The displayed value of this dropdown may therefore become out of sync with the true value.

[rhigman]

As discussed in the Bulma issue, this is probably actually a Yew bug. The suggested workaround can be attempted once #370 is complete.

[rhigman]

As discussed in the Bulma issue, this is probably actually a Yew bug. The suggested workaround can be attempted once #370 is complete.

The linked bug is marked as fixed in Yew 0.20.0, which has been released (we are still on 0.19.3). Documentation here appears to be relevant. Upgrading to 0.20.0 may be time-consuming. I'm not clear on whether the linked workaround will still work under 0.20.0. I've experimented with it under 0.19.3 but not yet had success.

[tosteiner]

further display issues in the backend UX, this time with the Work Type selection box.

Entering data for an edited collection, when I add new chapter-level entries to the database, they always revert back to work type Monograph 🙁

Chapter items are listed in the relational child-parent view, but when opening those individual chapters, they are being displayed as Monograph (first item in the drop-down list menu), even though I'm 100% sure I had saved that entry as Work Type Chapter. @brendan-oconnell has helpfully pointed out the underlying data has been stored correctly - all items are listed as chapters in GraphQL - but the display issue persists.