Closed (fixed)
Project:
Experience Builder
Component:
Page builder
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Aug 2024 at 10:40 UTC
Updated:
3 Sep 2024 at 12:39 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
jessebaker commentedComment #3
jessebaker commentedI'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.
Comment #4
wim leers⚠️ 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 aDynamicPropSourceis not yet defined. Once it is defined, it'll need #3464017: [PP-1] HTTP API: new /xb/api/field-form route to load form for editing specific entity base/configurable field, but that's not in scope for the Barcelona demo (#3454094: Milestone 0.1.0: Experience Builder Demo).👇
Proposal:
[later phase]StaticPropSources, because that's what the scope of #3454094 is — that would be a pure back-end issueComment #5
jessebaker commentedRE #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.
Comment #6
wim leersYay, glad to be wrong then! 😄
Comment #7
bnjmnmThis can also happen if there are JS errors - what is the console telling you when this happens?
Comment #9
bnjmnmMR fixes this by effectively closing the panel between selections, though to a civilian nothing is different.
Needs tests, though.
Comment #10
lauriiiComment #11
balintbrews@bnjmnm — I did some digging, because it felt like based on the current code in
0.xthings should already properly re-render without having to dispatch new actions. I found out that the culprit is the component tree thathyperscriptifyreturns: 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 whathyperscriptifyreturns 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
hyperscriptifythat 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:
We might even make
keya required argument instead of an option if we deem this behavior as expected, but I really would like to hear your thoughts.Comment #12
wim leersComment #15
balintbrewsComment #16
wim leersTests are present.
It’s looking solid to my non-trained-on-React eyes, but it also makes some pretty significant
xb-general.cy.jschanges 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 👍
Comment #17
wim leersAlso: major kudos for that very thoughtful description on the MR! 👏
(Making sure that people looking at this d.o issue find that GIF in there.)
Comment #20
bnjmnmVery 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.