feat: control container option

[kevinchappell]

activates the existing controls.container option. Controls will now be appended to the element defined in this option.

[Copilot]

Pull request overview

Activates the existing controls.container option so editor controls can be mounted into a user-specified DOM element/selector.

Changes:

• Add controls.container to default editor options.
• Introduce dom.resolveContainer() utility (with unit tests) to resolve selector strings to DOM elements.
• Update editor/controls initialization to resolve and use the configured controls container during render.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/lib/js/editor.js	Uses resolved containers and attempts to mount controls into controls.container during render.
src/lib/js/config.js	Adds default controls.container: null configuration.
src/lib/js/components/controls/index.js	Resolves controls.container via dom.resolveContainer() when applying options.
src/lib/js/common/dom.js	Adds resolveContainer() helper for selector/element resolution.
src/lib/js/common/dom.test.js	Adds unit test coverage for resolveContainer().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

dom.empty(controlsContainer) will clear the editor root when controls.container is not set (default null), because controlsContainer falls back to this.editor. That removes the stage DOM nodes you just created in elemConfig.content, so the rendered editor will only contain the controls. Instead of emptying unconditionally, only clear/replace when an external controls.container is configured (or remove/replace an existing .formeo-controls node) and leave this.editor content intact.

[Copilot]

If controls.container resolves to the same element as editorContainer, controls are appended and then immediately removed when dom.empty(this.editorContainer) runs (and similarly if the controls container is inside editorContainer, it gets removed by the empty call). Consider handling the “shared container” case by clearing once and appending both controls + editor in the intended order, or documenting/enforcing that these containers must be distinct/dedicated.

[Copilot]

resolveContainer currently returns any non-string value as-is and doesn’t guard document.querySelector against invalid selector strings (which throw). This can lead to hard-to-debug runtime errors later (e.g., calling DOM APIs on a non-element) or immediate initialization failures for malformed selectors. Consider validating with isDOMElement and returning null (or throwing a clear error) for unsupported types, and wrapping querySelector in a try/catch to return null for invalid selectors.

Suggested change

	return typeof container === 'string' ? document.querySelector(container) : container
	if (typeof container === 'string') {
	try {
	return document.querySelector(container)
	} catch (e) {
	// Invalid selector string
	return null
	}
	}
	if (this.isDOMElement(container)) {
	return container
	}
	return null

[Copilot]

This change introduces/activates controls.container behavior, but there doesn’t appear to be any Playwright coverage asserting that controls render into a custom container (and continue to render correctly on re-render). Adding an e2e test that configures controls.container (and optionally the interaction with editorContainer) would help prevent regressions here.