Offer a <code-mirror> custom element

[justinfagnani]

Embedding CodeMirror will be a bit easier with:

<code-mirror></code-mirror>

than:

<div style="" id=editor></div>

let view = (window as any).view = new EditorView(state)
document.querySelector("#editor").appendChild(view.dom)

Custom elements are natively available in Chrome, Safari, Opera and Firefox Nightly, and polyfilled in Edge and older browsers.

[marijnh]

Doing this in a way that only supports a very dumbed-down interface would be easy, but that'd be annoying in that I'd expect people to run into its limitations very quickly, at which point they have to refactor to the non-custom-element interface.

That being said, I don't have a lot of experience with custom elements, and maybe there are ways to model a projection of most of the API this way. How do you pass non-string data in and out of such elements? Element attributes are still constrained to be strings, right?

In any case, this won't be part of the core library, but it'd make perfect sense to provide it as a separate wrapper package.

[jarek-foksa]

@marijnh Custom element would allow you to mimic the API of native widgets such as <textarea> or <input>. This means you could expose functionality as:

• JS method, e.g. editor.showLineNumbers();
• JS getter/setter, e.g. editor.lineNumbers = true;
• HTML attribute, e.g. editor.setAttribute("linenumbers", "");

While the HTML attribute value must be a string, you could also provide a corresponding getter/setter which reflects the attribute value as a number, boolean, array, etc. Check Xel for example, I think Polymer is also using this pattern extensively.

[justinfagnani]

@marijnh Big +1 to what @jarek-foksa said.

Elements are objects and have regular JS object semantics, so they can have methods and properties like any other object. They are not limited at all to attributes and strings. For instance, look at the HTMLMediaElement interface which has an extensive set of properties and methods: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement

HTML markup, of course, is limited to children, attributes and strings, so you won't be able to do very complex configuration just from markup, but you'll be able to set the simple-valued flags. Most templating languages these days, like Vue, Angular, Polymer, lit-html, support setting properties declaratively, so in those cases one could do complex config declaratively. Then as a fallback you have imperative configuration.

You could also use subclassing:

class MyCodeEditor extends CodeMirrorElement { ... }
customElements.define('my-code-editor', MyCodeEditor);

<!-- already configured -->
<my-code-editor></my-code-editor>

In any case, this won't be part of the core library, but it'd make perfect sense to provide it as a separate wrapper package.

Seeing as how Web Components are the Web platforms native component model and CodeMirror is vending a component-like thing, this seems unfortunate to me. I think many of the simple use cases could be even easier and more obvious to use with custom elements.

[curran]

Agreed this would make total sense as a wrapper package, not part of the core.

[marijnh]

I've taken another look at custom elements and decided that no, the core library will not be based on them. Again, I do think a 3rd party library wrapping the editor in a custom element would be a useful thing, if someone wants to write it, but I'm going to close this.

[justinfagnani]

@marijnh do you have any rationale that you could share? Not to try to convince you otherwise, but just understand.