Log render reasons in browser console

[frederikhors]

I'm new to Preact.

Long time ago I was using React and it was almost necessary to use this tool to speed everything up: https://github.com/welldone-software/why-did-you-render.

Today I started working with Preact for the first time and I was wondering if today we still need a tool like that.

And if so, how can we make it work for Preact?

From here it seems to me that nobody knows how: welldone-software/why-did-you-render#113.

[developit]

Hi there! Preact has its own developer tools that you can install as a browser extension:
https://preactjs.github.io/preact-devtools/

As for the "Why Did You Render" library, the reason there is no specific documentation on how to set it up with Preact is because it works out-of-the-box with preact/compat. Just set up the aliases and it'll print the same data it would for React.

Here's their codesandbox that I forked and dropped in the aliases on:
https://codesandbox.io/s/why-did-you-render-preact-6kcum?file=/package.json
(in the case of codesandbox the aliases are a little weird, normally it's {"react":"npm:@preact/compat"} or similar)

I'm going to close this one out since it's a question, but feel free to ask any further questions on Slack - Saturdays aren't as quick to get an answer, but it's generally a better avenue than GitHub for things like this.

[marvinhagemeister]

As for the "Why Did You Render" library, the reason there is no specific documentation

Even better, it's included in our devtools extension as part of the Profiler. It will record why an update was triggered. See the following screenshot 👍

[frederikhors]

@marvinhagemeister I wanna know why an update is trigger as an alert in console during development. Is this possible today?

[marvinhagemeister]

@frederikhors I'd love to hear more about the use case before adding such a feature. What kind of information you're aiming to get via the console.log output that's not present in devtools? Or are you looking for a different way to visualize renders over time?

[frederikhors]

Ok. I will explain it differently. I'm developing a new app with React/Preact.

I would love to install why-did-you-render or something else and during my development I have my browser's console open. When some update isn't useful I would like to see an alert (a warning, a console.log()) in my console to fix it with shouldComponentUpdate() or with a refac.

Is it clear now?

[marvinhagemeister]

Thanks for the explanation. That sounds reasonable, I can add such a setting to the devtools. My main worry initially was that it could get a bit noisy depending on the app in question, as I'm unsure how we can differentiate useful renders from non-useful ones. But if it's a custom user setting it's good enough imo.

[frederikhors]

how we can differentiate useful renders from non-useful ones

I think this is what https://github.com/welldone-software/why-did-you-render does. Nope?

[frederikhors]

Hi @marvinhagemeister, we are evaluating Preact for a job where every single FPS counts. Do you think this feature will ever be implemented?

[marvinhagemeister]

Yes, I do like to have some form to judge the usefulness of a render.

[frederikhors]

Like what they already do in https://github.com/welldone-software/why-did-you-render? Nope?

[JoviDeCroock]

@frederikhors if you have a specific thing that you want let's make an RFC? We can also help you out if you want to contribute this change yourself, insisting/pressuring someone else to do it won't solve the issue at hand 😄

[frederikhors]

@JoviDeCroock there is no RFC to write. Everything is very simple: "why-did-you-render" for Preact.

I didn't "insist"; today I just asked - after almost two months - if this feature will ever be inserted or not since in the coming weeks a project for which we are also evaluating Preact starts.

Just to clarify. Thank you all for your immense commitment.

[DanielHeath]

So, I have some more concrete requests here which hopefully shed some light:

Firstly, if a component is re-rendered, but no DOM changes are made as a result - that's a prime opportunity for applications developers to improve performance. I would find it very useful to have devtools separate "render with no updates" from "render with updates".

Secondly, there's useful details regarding the render reason missing. In development mode, at least, I'd like to see a way to figure out what state changed.

For class components, which keys of state changed? Capturing a stack trace in setState would be very useful here also - though clearly high enough overhead to restrict to development mode builds.

For function components, one could make use<hook> calls capture a stack trace in development mode, so I can figure out which of the ten hooks my component uses caused the update.

For context updates, including the displayName of the context would be helpful (failing that - again, a stack trace showing where the context was initialized).