Accessing this.element throws exception for single root element with extra whitespace

With the following template:

<div class="container">
  <h1>My App</h1>
</div>

Trying to access this.element in the didInsertElement Lifecycle Hooks throws an error:

Uncaught Error: The 'element' property can only be accessed on components that contain a single root element in their template. Try using 'bounds' instead to access the first and last nodes.

I found out that this is because of the newline at the end of the file, which is treated as a separate node. this.bounds.lastNodecontains a separate node with the content "↵" Even adding a singe whitespace character at the end of the div node makes this.element access fail.

This behavior seems kind of unintuitive, since according to my first impression of this, this should be considered to be a single root element. Would you say this is expected behavior, or is it recommended to always use this.bounds instead?

---

To reproduce: Add a single space immediately after the end of this template i.e. after </nav> https://github.com/glimmerjs/glimmer.js/blob/master/packages/%40glimmer/component/test/browser/element-test.ts#L50 Once you re-run the tests, the 'elements are supported' test fails.

[rwjblue]

In general,gimme.js will follow suit with Ember and remove this.element all together. The main blocker for this is adding proper element modifier support.

[rjschie]

I agree, this is very unintuitive (and annoying tbh), and difficult to find the problem. Would we lose anything by always having this.element return the same thing as this.bounds.firstNode? That should solve this problem in a performant way, not change functionality, and be a more intuitive issue to solve for those who perhaps meant to grab a different node.

I guess another option would be updating the template compiler to strip surrounding whitespace? Or does the bounds assert check happen before it’s compiled? I’m not very familiar with how template compilation works, and where it fits into the pipeline.