Allow HTML elements in `<svelte:element this={...} />`

[lassebomh]

Describe the problem

I'm making a CodeMirror component with the goal of making it as thin/native as possible, while being able to use it in the Svelte way. Creating a CodeMirror editor gives me a view.dom element that I need to insert, which forces me to have a wrapping element to insert it into:

<script>  
  let { ...rest } = $props();
  
  const view = new EditorView({
    doc: value,
  });
  
  let wrapper;
  
  onMount(() => {
    wrapper.appendChild(view.dom)
  })
</script>

<div class="wrapper" bind:this={wrapper} {...rest}></div>

As a consequence, the rest props are passed to the wrapper instead of the actual editor element, so if the component user sets style="height: 300px" it will actually behave like style="max-height: 300px" on the editor element. All workarounds I've found have significant downsides and/or nasty edgecases.

TLDR

There is no way of placing elements created via document.createElement into the root of a component or use Svelte features/syntax on them.

Describe the proposed solution

Given an HTML element, writing <svelte:element this={node} /> would:

1. Insert the HTML element into the component at the provided location.
2. Allow passing attributes and event handlers to it, just like any other element.

Behaviour in case of conflicting child elements / attributes is something that would need to be defined. For my use case it would be fine to overwrite children/attributes if provided in the component, but otherwise left as-is.

Looking at my example, this would fix my styling issue and make it more concise:

<script>
  let { ...rest } = $props();
  
  const view = new EditorView({
    doc: value,
  });
  
</script>

<svelte:element this={view.dom} {...rest} />

Importance

nice to have

[paoloricciuti]

You could do something like this to have this very effect...however libraries that build on top of codemirror actually do the opposite...create an element through svelte and pass it down to codemirror as the host.

[lassebomh]

In my use case it wouldn't be a problem if CodeMirror v6 exposed a host option, but checking the EditorView constructor, it shows that the element in question is created no matter what.

Also your solution will delete any props added to the container element, for example if you added styles. repl

[paoloricciuti]

Also your solution will delete any props added to the container element, for example if you added styles. repl

Because it's not the container element anymore...if you want the element to stick around you append instead. If you want to preserve it you can also copy the style and class prop in the action

[paoloricciuti]

Also take a look at what neocodemirror from @PuruVJ is doing

https://github.com/PuruVJ/neocodemirror/blob/4e7de700fff0a65c05feb6bf8d5929591e848fa6/packages/svelte/src/index.ts#L473-L476

[lassebomh]

Also take a look at what neocodemirror from @PuruVJ is doing

https://github.com/PuruVJ/neocodemirror/blob/4e7de700fff0a65c05feb6bf8d5929591e848fa6/packages/svelte/src/index.ts#L473-L476

They have a wrapping element, the one the action is used on.

Because it's not the container element anymore...if you want the element to stick around you append instead. If you want to preserve it you can also copy the style and class prop in the action

I don't want:

• a wrapping element
• a temporary wrapping element & prop sync

I've messed enough around with problems similar to this to know that replace will break unmounting and I'm sure both solutions have issues that I haven't discovered yet.

I really do appreciate the suggestions, but I have plenty of potential workarounds. So far, none of them address the problem in a way thats nice, hence the feature proposal.

For @PuruVJ or anyone else finding this, my current solution is to extend the EditorView with a class that overrides the dom attribute with a getter and setter (that does nothing). Slightly cursed and CM will override any classes added to the element, when they set "cm-editor". The code looks something like this:

const cls = class extends EditorView {
  get dom() {
    return node; // node is set via bind:this
  }
  set dom(_) {}
};

But thats beside the point in regards to the proposal.

[paoloricciuti]

Ok I think it's doable. However this poses some question that make me nervous about this, you already identified one...what to do with already present children? One option could be to just append the children of svelte:element to the ones of the passed in element. This would allow freedom-ness but it's also a bit counter intuitive (maybe?).

Another problem is SSR...right now it would not SSR anything unless you purposely do something like

<svelte:element this={dom ?? 'div'} />

I'll try to craft a PR so we can try stuff

[lassebomh]

Awesome. I use Svelte a lot but only FE, so I'm of no help when it comes to SSR 😄 In regards to passing children, my thinking was to match the behaviour of mount by appending, exactly like you suggest.

[paoloricciuti]

Since we decided against this feature I'm gonna close this issue, thanks for reporting anyway 😊