How can I use octane / glimmer components?

[Bouke]

I've been using ember-islands for some time now, with great success. However with the advent of Octane / Glimmer components, I'm not use how to use them with ember-islands. Suppose the following file structure:

- components
  - input
    - datetime.hbs
    - datetime.ts (or .js for that matter)

In normal template use, I would invoke it like so:

<Input::Datetime />

However with ember-islands I've tried input::datetime and that results in an error in the console: "fullname is required".

[mitchlloyd]

I haven’t used Ember Octane yet so I’m behind the curve here. Previously you could invoke a nested component like this with a slash “input/datetime”. Does that still work? This is part of a growing list of items that may necessitate a major change with how this library invokes components for newer version of Ember.

…

On Wed, Mar 4, 2020 at 3:16 AM Bouke Haarsma ***@***.***> wrote: I've been using ember-islands for some time now, with great success. However with the advent of Octane / Glimmer components, I'm not use how to use them with ember-islands. Suppose the following file structure: - components - input - datetime.hbs - datetime.ts (or .js for that matter) In normal template use, I would invoke it like so: <Input::Datetime /> However with ember-islands I've tried input::datetime and that results in an error in the console: "fullname is required". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59?email_source=notifications&email_token=AAADWQM6UMYEI4TX4IZGB3TRFYE5PA5CNFSM4LA63DRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ISJCQCQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADWQISHN72TSOTPDWUGCLRFYE5PANCNFSM4LA63DRA> .

[Bouke]

I couldn't get it to work with a slash (input/datetime). There's also no message in the console to aid debugging.

[alexlafroscia]

I'm working on seeing what I can do to get this working, as it's blocking our ability to migrate to Template Colocation in our applications.

So far, it's been a challenge to get things working with Template Colocation.

Basically, the approach that ember-islands takes to calling create on the component class does not work, both when the component has and does not have a .js file associated.

If there is no JS file, there's actually no class at all to call .create on. I have no idea how we might move to support that.

If there is a JS file, calling create does not work as the layout property is missing. I've tried everything I can think of to locate the template for a "template colocation" component in the registry to provide the layout attribute automatically (as some other cases in ember-islands do) but it doesn't seem like these templates are registered at all.

One thing we might be able to support is template colocation only in cases where

• A JS file is present
• The JS file explicitly imports the template and sets the layout property

I did attempt a large-scale refactor to use the in-element component along with the component helper, in an effort to use more of Ember's public API and avoid some of these issues. About half of the tests pass that way, but there are some core places where things fall down

• No way to pass an unknown set of arguments to the component helper (you would need something akin to ...attributes but that supported props instead)
• in-element appends the component to the destination, rather than replacing in, which breaks the way that innerContent works

I'm going to keep working on this tomorrow, but wanted to leave some details around what I have tried and what I found.

[mitchlloyd]

Thanks for the notes, @alexlafroscia. I also took a shot at getting glimmer components working back in March. I just pushed those changes and WIP commit for what I had in progress on my computer.

It's been awhile but I think I came to similar conclusions. Since Octane landed, there is no longer a clear seam in Ember for creating components. Getting this to work seems possible but it's a question of how brittle we'll allow the implementation to be.

You should also know that when moving to Ember 2, the core team was invested in making sure that Ember Islands kept working. Some tests from this work still exist in Ember. However, I think the tests as they stand today demonstrate an alternative proposal from @chancancode using application.visit as an API to reimplement Ember Islands. I can't remember why this didn't end up working out, but it may be worth exploring again.

in-element, component, and ...splat was the avenue I was most excited about after -in-element and splat was proposed back in 2015. This came up before in another/pr issue on Ember Islands. However splat never landed as far as I know.

At this point I'm not opposed to a breaking change since moving to Octane is a large undertaking for most code bases. I'm not bothered by the append-to-marker vs replace-marker issue. It seems like something that could be managed by most consumers as long as they know it's coming.

The ...params issue seems stickier. I think Yehuda was pushing me toward just passing the json attributes from the marker container as a single param using the component helper. My biggest issue with that is that the rendered component is now an odd ember-islands-only component. I guess if we must choose between making this unfortunate trade-off and not having a working approach then maybe I need to give that up. But it feels pretty bad to me.

[alexlafroscia]

The “ember-islands-only” component is an approach that I’m considering as well; that would also make it obvious why there’s a handful of components that can’t be updated to use the new features/patterns.

Another thing I’m considering is whether something like this addon might be a better approach

https://github.com/Ravenstine/ember-custom-elements

It seems like a more “modern” approach using features that weren’t available when this addon was first written. I think I’m going to try that out and see if that could fit the use-case that we have instead..