Unexpected side-effect when providing containerId

[wellyshen]

Unexpected side-effect when providing containerId

[wellyshen]

@killthekitten Sorry to confuse you. This hook will automatically creates the container element for you if it doesn't exist. I have refine the documentation in the latest version, thank you.

[killthekitten]

@wellyshen thanks for the update, looks better now. However, it feels like this behavior should be separated.

If the container is present most of the time, but not always, it might ruin the UI. Imagine a dynamic containerId, or just making an error in code. The user will see the "default" container created by the library, rather than a styled and tested container that was supposed to be there.

[wellyshen]

@killthekitten Sorry I don’t fully understand your concerning. Currently, the library will creates the container element only when needed and removes the element once it’s not used. For the overall mechanism, which part can we improve?

[killthekitten]

@wellyshen I'm concerned that providing a custom containerId can render a new element when it wasn't intended.

I can see three scenarios of using this:

• There's no element with containerId. I want to create it automatically, as a sibling to root.
• There is an element with such an id, and I want to use it.
• There's no element, but I expect it to be there. I don't want a new element to be created, and would prefer an error to be thrown rather then silently create a new element.

The library covers the first two cases, but not the third one.

I would suggest an option to enable/disable rendering the container automatically, i.e. createContainer. The naming isn't great tho.