Panic when component uses ComonentOrHTML field as child

[bzub]

#78 discusses the panic I'm running into. vecty: next child render must not equal previous child render (did the child Render illegally return a stored render variable?) There are other tickets mentioning that panic, but I think this might be a bug that's not represented yet.

Here's a simple repro: (gist/jsgo). This case panics on any rerender of the Button component. Check the checkbox to trigger rerendering of all buttons.

I am able to work around the panic when the Button's child element Label is *vecty.HTML by dereferencing/copying/creating a new pointer as seen here (gist/jsgo). However there seems to be no workaround when the child element is vecty.List.

[emidoots]

It'll be a few weeks before I will be able to investigate whether or not we should remove this panic or not. My initial assumption is that we probably should, but I don't recall my original motivation for it. I'll need to go back & relearn / remember why this panic was added originally.

The current way to fix your code is: do not store a vecty.List but instead create a new one each time Render is called, and return that instead.

[bzub]

@slimsag Thanks, I am starting to get familiar with vecty's code so I'll see if I can help.

To your point about creating a new vecty.List, a workaround for users who aren't interested in debugging so much is to wrap the inner element(s) in a component that implements vecty.RenderSkipper. This lets you store any kind of ComponentOrHTML dynamic type as long as you handle it correctly as shown below. My previous attempts to make a new list and copy into it failed with the same panic. Additional code will probably need to be added to this workaround to prevent a render skip when someone actually changes the stored vect.List.

gist: https://gist.github.com/bzub/962d4cda9cf469d06d96c3d8c4ace2a7 jsgo: https://jsgo.io/gist.github.com/962d4cda9cf469d06d96c3d8c4ace2a7