Values in props edit form do not always match the selected component

I've also just spotted that if you get into the state described above then updating the values in the fields no longer automatically updates the components shown in the preview.

Click the first and observe that the values in the form on the left match the values shown for the selected component
Click the second and observe that the values in the form still show the values matching the first component.

⚠️ This is likely explained by the default component tree using DynamicPropSources, i.e. fetching a value from the host entity. The UX for components with >=1 component prop populated by a DynamicPropSource is not yet defined. Once it is defined, it'll need 📌 [PP-1] HTTP API: new /xb/api/field-form route to load form for editing specific entity base/configurable field Postponed , but that's not in scope for the Barcelona demo ( 🌱 Milestone 0.1.0: Experience Builder Demo Active ).

👇

Proposal:

1. keep this issue, but prefix its title with [later phase]
2. create new issue to change the default component tree to use only StaticPropSources, because that's what the scope of #3454094 is — that would be a pure back-end issue
3. #3++ — spotted that too → but that is AFAICT a pure front-end issue, i.e. a bug in ✨ Contextual form values need to be integrated with Redux Active

RE #4

I think the issue I'm reporting is purely a front end problem and perhaps the issue you are describing is something different. You can work around the bug, purely on the front end, but closing the context panel in between selecting different components. See the two attached screen recordings.

Yay, glad to be wrong then! 😄

This can also happen if there are JS errors - what is the console telling you when this happens?

MR fixes this by effectively closing the panel between selections, though to a civilian nothing is different.

Needs tests, though.

@bnjmnm — I did some digging, because it felt like based on the current code in 0.x things should already properly re-render without having to dispatch new actions. I found out that the culprit is the component tree that hyperscriptify returns: React doesn't know that it's supposed to re-render that. I didn't manage to find out why that is the case. I am, however, fairly certain it is the root cause of the issue. I did extensive testing, and components added as siblings to what hyperscriptify returns are properly re-rendered without any code changes. Any ideas why this happens?

The solution I came up with is adding a new option to hyperscriptify that allows us to pass a key, then adding that key to the fragment element. How do you feel about that?

This is how that might look like:

diff --git a/ui/src/components/DummyPropsEditForm.tsx b/ui/src/components/DummyPropsEditForm.tsx
index 5fd3df4..a63dfcb 100644
--- a/ui/src/components/DummyPropsEditForm.tsx
+++ b/ui/src/components/DummyPropsEditForm.tsx
@@ -65,7 +65,7 @@ const DummyPropsEditFormRenderer: React.FC<DummyPropsEditFormRendererProps> = (
             React.createElement,
             React.Fragment,
             twigToJSXComponentMap,
-            { propsify },
+            { propsify, key: dynamicStaticCardQueryString },
           )
         : null,
     );
diff --git a/ui/src/local_packages/hyperscriptify/index.js b/ui/src/local_packages/hyperscriptify/index.js
index 2950ed7..ff850c7 100644
--- a/ui/src/local_packages/hyperscriptify/index.js
+++ b/ui/src/local_packages/hyperscriptify/index.js
@@ -108,7 +108,9 @@ export default function hyperscriptify(
       break;
     case Node.DOCUMENT_FRAGMENT_NODE:
       component = Fragment;
-      attributes = {};
+      attributes = {
+        key: options.key,
+      };
       childNodes = domElementOrFragment.childNodes;
       break;
     default:

We might even make key a required argument instead of an option if we deem this behavior as expected, but I really would like to hear your thoughts.

balintbrews → credited effulgentsia → .

Tests are present.

It’s looking solid to my non-trained-on-React eyes, but it also makes some pretty significant xb-general.cy.js changes so I think @bnjmnm's explicit +1/-1 would be great :)

Conveying that it's down to the final review stage by marking this RTBC 👍

Wim Leers → closed merge request !171

Very nice @balintbrews! While my original solution addressed the symptom, it felt more like a hack than an actual improvement / fix. Your solution, on the other hand, addresses the underlying cause and removes some debt in the process.

Automatically closed - issue fixed for 2 weeks with no activity.