I’m trying to edit a content item for a model that’s rendered twice on my page. Although the model is rendered twice, each instance is actually of a different content item: I use a custom targeting attribute to download the content for each content item that I want, then render them in Next.js using two <BuilderComponent> tags.
Works as expected on the page itself but you’re not able to see a live view of your changes when editing in the Visual Editor.
Hey @ersin this is actually currently an expected behavior. The Visual Editor will target the and replace with the current content, it is how we are able to display unpublished content, for example, within the Visual Editor in real time.
You can add a key prop to the <BuilderComponent/> to make sure it is correctly getting differentiated within your React app, which helps with issues on the live page:
I will file a ticket to help improve this UX in the future, but for now this is expected. Please let us know if this becomes a critical use case for you and I can bump in priority!
Hey @TimG, I may not have understood you correctly. Basically, the problem is that unpublished content isn’t being displayed in the Visual Editor. I’m not certain why, but my strong suspicion is that it has to do with two <BuilderComponent>s with the same model being rendered in the preview.
I tried adding a key just now but it doesn’t seem to have any effect.
Hi @ersin ! Apologies, I definitely probably could have spoken better…but yes I understand and have seen this pattern many times before.
When I say it is expected, I mean it is known and in line with how our Visual Editor currently works. So even if you are passing server-rendered content into a <BuilderComponent/> or <BuilderContent/> block, within the Visual editor our app will find any of those blocks that have a model that matches the one you are editing and then override whatever content with what the current content entry is.
Discerning which element on the page you are currently editing at the exclusion of the other blocks can be a bit more complicated than just basing it off of targeting. Like I said, we do have a backlog story to update this at some point, and I will definitely keep you posted! If this use case becomes more critical and this UX pattern a blocker definitely let me know!
What I have seen many customers do it isolate those sections and only edit them as individual sections, or set up a specific editing URL, and then add them to the greater page as a symbol, or within code if you want to avoid seeing the multiple elements show the same content while editing.
Hopefully that clarifies, let me know if you have any other questions, or want to try to work through any other work arounds or preview options!
Hey @ersin the key prop is strictly speaking not required, but recommended best practice when you have multiple entries of the same model on the same page as it helps differentiate s on the page, and will most likely be utilized once we fix this UX issue in the future. Just a side note!