Expose a parentElement property for (tagless) components

[simonihmig]

Components have an element property that gives you the DOM element of the component itself. Getting its parent is pretty easy, using element.parentElement or this.$().parent(). But these approaches fail when dealing with tagless components, which have no element and no this.$() either. Obviously, they still have a parent though!

So far I have used this utility function:

import Ember from 'ember';

const { get, $ } = Ember;

export default function getParent(view) {
  if (get(view, 'tagName') === '') {
    // Beware: use of private API! :(
    if (Ember.ViewUtils && Ember.ViewUtils.getViewBounds) {
      return $(Ember.ViewUtils.getViewBounds(view).parentElement);
    } else {
      return $(view._renderNode.contextualElement);
    }
  } else {
    return view.$().parent();
  }
}

This seems to work for all Ember versions (pre and post Glimmer2), but is obviously pretty hacky as it is using private APIs. And there does not seem to be any way to get the parent element for a tagless component using just public APIs, unless I am overlooking something!?

So my suggestion would be to introduce a parentElement property, in analogy to the element property.

An example use case: I want to make a tooltip component, that should be used like this:

<button>
  Create
  {{bs-tooltip title="Just create something"}}
</button>

The tooltip component must have access to its parent element, to attach event listeners to it, but should not (until the tooltip is actually shown) add anything to the DOM. Thus a tagless component.

Any thoughts?

[rwjblue]

As you discovered, there is private API in Ember 2.9+ that allows access to a components bounds (including parentElement). This support was added for glimmer2 support in Ember Inspector.

I think we would definitely consider making that method (Ember.ViewUtils.getViewBounds) public API, but I doubt we would want to add another property to the component itself for it.

[nathanhammond]

This also seems like something where element modifiers might play in as well.

[simonihmig]

@rwjblue would be fine for me as well!

@nathanhammond to be honest I don't see the connection here. Could you elaborate on it?

[miguelcobain]

There's also the "eternal" emberjs/ember.js#12500
Might be interesting for the discussion. :)

[simonihmig]

@miguelcobain Thanks for pointing this out! Yeah, if that PR would land, it would solve this issue as well. Maybe It's time to "revive" your PR when Glimmer2 has finally landed in 2.9? :)

[simonihmig]

As it has been quiet on this one for a while, how can we proceed?

Is making Ember.ViewUtils.getViewBounds public the preferred solution then, as @rwjblue suggested? If so, should I try to put an RFC together that goes into that direction?

[rwjblue]

Ya, an RFC for that seems like a good next step.

[simonihmig]

Ok, great, will go for it.

My motivation for this came from the specific use case of getting the parent from a tagless component. But Ember.ViewUtils.getViewBounds does actually provide more than that, in particular the component bounds. Are there any additional valid use cases to make that whole thing public, that should be mentioned in the RFC?

[kybishop]

@simonihmig is there an official RFC for this?

In the meanwhile, @pzuraq came up with a clever workaround for ember-popper where we get the parent node of an {{unbound}} element which we stick in our tagless component.

[pzuraq]

Oh yeah, this would be much better than my hack. Would definitely love to see this become an RFC 😄

[mehulkar]

@simonihmig now that modifiers are a thing, I think this can be closed right?

[simonihmig]

now that modifiers are a thing, I think this can be closed right?

Well, 2.5y later I wasn't even aware this was still open! 😝

And yes, now with Glimmer components the original request to extend Ember.Component with something does not make too much sense anymore.

But still not sure how we could implement the use case properly with modifiers or whatever other public API we have now. Given the original example:

<button>
  Create
  <BsTooltip @title="Just create something"/>
</button>

<BsTooltip> is a tagless component (Ember or Glimmer) that renders into another destination element using in-element. So attaching a modifier to anything it renders would not allow to traverse to the parent.

FWIW, it's still using that empty TextNode hack...

[Panman82]

To move this to a modifier, what about instead of using {{in-element}}, have the user put a <BsTooltipContainer /> component in their application.hbs template. The component would then monitor a BsTooltipService service which the {{bs-tooltip}} modifier would add/remove things from/to/whatever. That would open the door to;

<button {{bs-tooltip "Just create something"}}>
  Create
</button>

Which provides access to the element to add/remove event listeners (hover). I might have a second to create a quick demo if you'd like.

[chriskrycho]

A quirky workaround that I think should get the job done, and which doesn't require any hackery or use of services, though it isn't necessarily great:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { guidFor } from '@ember/object';

export default class WillHaveTooltip extends Component {
  @tracked id;

  constructor() {
    super(...arguments);
    this.id = guidFor(this);
  }
}

<button id={{this.id}}>
  Create
  <BsTooltip @title="Just create something" @parentId={{this.id}}/>
</button>

Then BsTooltip can just do something like this:

const targetEl = document.querySelector(`#${this.args.parentId}`);
assert(targetEl instanceof HTMLElement);
// off to the races

This is, to be clear, less elegant than we might like – in particular, it would be nice if we could do all of that nicely in a template-only component – but it should work.

[simonihmig]

@Panman82 Thanks for the suggestion, which probably would work. But given that the motivation for bringing this topic up is to have a public and easy to use API for that use case, the amount of orchestration needed in your approach does not really qualify as easy 😉

Also it wouldn't work for <BsTooltip>'s bigger brother, <BsPopover> which is used in block form:

<button>
  Create
  <BsPopover @title="Popover">
    Can contain <FancyComponent>arbitrary</FancyComponent> content.
  </BsPopover>
</button>

A quirky workaround that I think should get the job done, and which doesn't require any hackery or use of services, though it isn't necessarily great

Yeah, that's possible, and indeed is already supported as an alternative way to specify the tooltip's triggerElement, using a CSS selector. But the default is to automatically attach to the parent element, and that seems to require some hackery - one way or the other...