Re: Frame timing API question

>
> Pardon my ignorance of React.. I'm looking at the docs, and it looks like
> it accepts a third callback parameter [1]: "If the optional callback is
> provided, it will be executed after the component is rendered or updated."
>

The callback gets called after the initial update (which is synchronous
therefore would happen immedately before mark()) and after any update to
the component (so if somebody changed the state of an internal part of the
component). For the purposes of this discussion, the important thing is
that ReactDOM.render() will insert HTML into the DOM that displays the
"hello" component to the user.

We once ran into a request from amazon for
requestCallbackWhenElementOnscreen().
> Similar concept. Goal was to know when you got rendered --- and if there
> was a delay due to late stage pipelient higns like eg image decode, or
> rasterization, we'd include that in the timing.


Yes, that's essentially what we want.  That said, we'd be willing to settle
for something slightly less than "the item is painted on screen" as we know
:visited is an issue. For example, it'd be reasonable to get a callback
when the element is laid out an is about to be painted. I'm pretty sure
this can be done very hackily using rAF + triggering layout on our own.
Maybe we could use IntersectionObserver to accomplish this as well.

-b

On Fri, May 6, 2016 at 12:27 PM, Nat Duca <nduca@google.com> wrote:

> We once ran into a request from amazon for
> requestCallbackWhenElementOnscreen(). Similar concept. Goal was to know
> when you got rendered --- and if there was a delay due to late stage
> pipelient higns like eg image decode, or rasterization, we'd include that
> in the timing.
>
> Fundamentally, this whole space bumps up againt the :visited problem. So,
> to do anything here, we need to move the community forward on :visited
> mitigation, I fear.
>
> On Fri, May 6, 2016 at 11:42 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> On Wed, May 4, 2016 at 3:10 PM, Ben Maurer <ben.maurer@gmail.com> wrote:
>>
>>> Hey guys --
>>>
>>> There was some discussion internally at FB about the frame timing API
>>>  and that prompted a question today.
>>>
>>> Imagine the following JS code:
>>>
>>> function RenderHello() {
>>>   ReactDOM.render(
>>>     <Hello name="World" />,
>>>     document.getElementById('container')
>>>   );
>>>   window.performance.mark('hello_rendered');
>>> }
>>>
>>> The developer wants to know when the Hello react component is "done" and
>>> so they set a performance mark once the element is inserted into the DOM.
>>>
>>
>> Pardon my ignorance of React.. I'm looking at the docs, and it looks like
>> it accepts a third callback parameter [1]: "If the optional callback is
>> provided, it will be executed after the component is rendered or updated."
>>
>> ^ what does the above encompass, exactly?
>>
>> [1]
>> https://facebook.github.io/react/docs/top-level-api.html#reactdom.render
>>
>> However, this isn't actually correct. The user only sees the Hello
>>> element once the browser paints that frame. For example, if a setTimeout()
>>> call executed during the frame that took 1 second the user would only see
>>> the element at the end of that second.
>>>
>>
>>
>>> This seems like a problem that the Frame Timing API would ideally help
>>> to solve. But it wasn't clear that it was possible to determine this via
>>> the API.
>>>
>>
>> FT doesn't address this. As specced, it only lets you know if there was a
>> slow frame... what was painted within that frame is completely opaque.
>> Potentially, if we can work out the technical bits, I could see us exposing
>> some high-level attribution information on what may have been the cause of
>> the slow frame (e.g. script task, another frame, etc), but I don't think
>> we'll ever get to element-level insights due to technical and
>> privacy/security constraints.
>>
>> FWIW, related discussion:
>> https://github.com/w3c/frame-timing/issues/53#issuecomment-206512574
>>
>
>