Locker Service DOM accessibility when action invoked via method

Question

I have a lightning component setup where in a parent component I dynamically create a component and assign it to an <aura:attribute type="Aura.Component" />. The dynamically created child component has an <aura:method /> on it. The controller action for that method does some DOM manipulation on a node inside the dynamically created component (this should be totally valid in Locker Service since we are accessing a DOM node inside the same component). However, getElement() is not available when the component was dynamically created. If I instead directly place the component inside the parent component with <c:myCmp /> when I call the same function getElement() is available.

Is there something special I need to do in order to make sure dynamically created components have getElement() available within their own controller code or is this simply a bug in Locker Service?

UPDATE - GIST

Here is a gist that will showcase the issue: https://gist.github.com/dsharrison/bf2ceaf22820bbfb79cef042fd2e5d8d

With Locker Service disabled, both buttons will report that getElement() is available. Once enabled, the dynamic button will lose access to getElement().

Answer 1

The gist is excellent - thank you!

I would actually expect both scenarios to "fail" because Component.find() and $A.createComponent() should both yield a SecureComponentRef and not a SecureComponent. Component.find()'s behavior is the expected/working as designed one and we will closing the createComponent() hole soon.

A component is meant to be an encapsulated unit and the supported public API it exposes consists of its attributes, methods, and events - not its internal DOM structure. Lightning Components are secure/encapsulated by default. The internals of c:LSTestChild are its private parts in unless it explicitly chooses to expose them.

Answer 2

Okay, so I finally figured out where we were going wrong with help from the comments from @TrevorBliss. The difference between our actual code and the gist is that we were using window.setTimeout to perform the DOM manipulation in the init event to animate some elements so that they would transition from an initial state to a a new state. In that context component.isRendered() is false because the DOM has not finished updating. This did not pose any actual functional problem for us since by the time the timeout started its updates the DOM was always ready. However, moving this logic to the afterRender allows the DOM updates to be complete so that component.isRendered() is true and we can use component.getElement() to access the actual node.