fast icon indicating copy to clipboard operation
fast copied to clipboard

Add Callback/Promise to FAST Element to hook on when a component is done rendering updates

Open Brian-Hofmann opened this issue 2 years ago • 11 comments

🙋 Feature Request

Add a callback to an element allowing users to know when the component element is done updating properties and has finished rendering those updates in the DOM . Similar to LitElement's updateComplete method in their life cycle.

https://lit.dev/docs/components/lifecycle/#reactive-update-cycle-completing

🤔 Expected Behavior

When an element's attributes or properties change, the updateComplete callback will fire after those updates are rendered in the DOM.

😯 Current Behavior

Currently there is no way to know the exact time an element is done rendering updates. There is the DOM.nextUpdate and DOM.queueUpdate functions, but they do not guarantee the component is actually done with its update rendering. I was also informed of the new way of doing this via the "Updates" import in the new FAST beta, but this also does not appear to guarantee the element is fully rendered post update.

💁 Possible Solution

Add an update lifecycle similar to LitElement or even just an updateComplete lifecycle hook to know when the element is fully updated and rendered.

🔦 Context

I have a FAST component that is inside of another FAST component. The inner component needs to set its dimensions based on the parent component which dynamically gets these dimensions set via properties after it is already connected. The DOM functions are firing too soon when the dimensions of the parent element are still 0x0. I would love to instead have an update callback where I can call the child functions that sync the child component dimensions to the parent since I would know for sure the parent is rendered and updated to the correct dimensions at that point. I could look into ResizeObservers for this specific case, but I have other scenarios where I need to call functions after knowing for sure the element has finished updating instead of relying on the DOM updates to be correct with no guarantee.

Brian-Hofmann avatar Jun 06 '23 21:06 Brian-Hofmann

@Brian-Hofmann Would it make sense to move to dimension setting logic to the parent? In the parent component's connectedCallback or when the dimensions get set you could emit a custom event with the desired dimensions that the child components could listen to.

KingOfTac avatar Jun 07 '23 15:06 KingOfTac

@KingOfTac I did think of that, but the parent dimensions are set by a CSS variable which is not set until after the element is connected to DOM. That means that the connected callback of the parent still has an element DOM rect of 0x0, and I don't have a good hook for knowing when the CSS variables changed and are rendered. Even if the dimensions were set by a property which I could hook a changed function to, does that change function triggering guarantee the changes are already rendered in the DOM/DOM Rect?

Brian-Hofmann avatar Jun 07 '23 17:06 Brian-Hofmann

Does the CSS var use FAST's DesignToken infrastructure?

KingOfTac avatar Jun 07 '23 17:06 KingOfTac

It does not. It is not something specific to our design system

Brian-Hofmann avatar Jun 07 '23 17:06 Brian-Hofmann

How is this CSS variable set?

In the scenario you're describing, the change handler would be invoked prior to making any necessary DOM updates. Thats okay though, because the strategy would be to bind those observable property values to properties or attributes on the child element, meaning no lifecycle hook would be necessary.

nicholasrice avatar Jun 09 '23 20:06 nicholasrice

So our component uses a canvas element (it's a signature component). We want the canvas element to fully take up the height and width of the component. The issue is canvas height and width can't be 100%, so we need to know when the FAST component is done rendering in order to set its height and width.

Now this can be solved with a "doneRendering" callback OR with ResizeObserver on the FAST component itself... Seeing as ResizeObserver is relatively new, we felt maybe a callback (like the one lit does) would be safer. In reality, the callback will work for initial render, but not for dynamic resizing of the component, but we don't anticipate a signature component resizing often.

Brian-Hofmann avatar Jun 09 '23 21:06 Brian-Hofmann

The component's view will be bound and appended to the host element / shadowRoot during the connectedCallback. You should have access to the size of the host element after super.connectedCallback. Is this sort of what you're trying to accomplish? https://stackblitz.com/edit/typescript-gjtarn?file=index.ts

nicholasrice avatar Jun 09 '23 22:06 nicholasrice

Yes but the true height and width of the parent is set after all the connectedCallback functions of both the parent and child already run. On connectedCallback we have the initial/default rendering height and width of the parent prior to the CSS variables being set, but we need the updated height and width after those are rendered in the DOM (and as I said previously, we have tried a DOM.queueUpdate in the connectedCallback to try and grab the new height and width of the parent, but the CSS variables are not set by the time the update occurs). The height and width are not properties directly on the object to make observable like in your example, so we couldn't use a changed callback.

Brian-Hofmann avatar Jun 14 '23 14:06 Brian-Hofmann

Can you put together a min-repro of your scenario, or update the above stackblitz so it is reflective of your scenario? I don't think I'm understanding all the constraints.

nicholasrice avatar Jun 14 '23 17:06 nicholasrice

Sure. I can look into updating yours.

Brian-Hofmann avatar Jun 14 '23 18:06 Brian-Hofmann

Hi, just following up on this since it seems like this thread has gone stale. Are there any plans in the near future to provide a hook for when a component is done rendering updates?

ElormCoch avatar Apr 02 '24 18:04 ElormCoch

Closing this issue as stale, if a repro is created feel free to re-open this issue so we can continue investigating.

janechu avatar May 29 '24 20:05 janechu