After clicking one up, the count increments and the button disappears. This is because <BearCounter /> is the only Component to re-render, so the only DOM sent up as part of the render message is for <BearCounter />, replacing all other DOM under the Component root.
If <BearCounter /> were its own RoC Component this wouldn't be an issue, but Components defined within an RoC Module do not currently get their own identifiers in DOM. In this implementation, the outer application would see that only <BearCounter /> was re-rendering and find the rendered DOM based on a stable identifier in the render message.
So the current demo Component would need to send a render message looking like
{
componentId: 'bwe-demos.near/NPM.Zustand',
identifier: '#bwe-demos_near_NPM_zustand [data-inner-component="BearCounter"]', // new field
node: { ... },
}
For multiple instances of the same Component, the key would need to be part of this identifier for siblings. If they are not siblings, then a distinct selector path would be required so that the correct instance is rendered.
https://roc.near.dev/bwe-demos.near/NPM.Zustand
After clicking
one up, the count increments and the button disappears. This is because<BearCounter />is the only Component to re-render, so the only DOM sent up as part of the render message is for<BearCounter />, replacing all other DOM under the Component root.If
<BearCounter />were its own RoC Component this wouldn't be an issue, but Components defined within an RoC Module do not currently get their own identifiers in DOM. In this implementation, the outer application would see that only<BearCounter />was re-rendering and find the rendered DOM based on a stable identifier in the render message.So the current demo Component would need to send a render message looking like
For multiple instances of the same Component, the
keywould need to be part of this identifier for siblings. If they are not siblings, then a distinct selector path would be required so that the correct instance is rendered.