Attaching custom renderers to devtools

[marvinhagemeister]

I'm currently revamping the devtools code for preactjs but I'm running into a few problems. The existing code tries to mimic the stack api by providing a stub reconciler, similar to how infernojs or other projects have done it.

For our next version I tried to switch to providing a stub fiber-based renderer, but the more I work on it, the more difficult it get's to convert our internal vnode structure to a fiber for react due to fundamental differences in how updates work in both frameworks.

So I've read through the devtools the past days and I'm wondering if we could introduce a way to allow third party alternatives to more easily integrate with the devtools. In our case we'd love to provide our attachRenderer-function instead of relying on the built-in ones. That way library authors could create the events themselves and don't have to pretend to share the same internal objects. This would be tremendously helpful and remove quite a bit code from our current devtools integration.

I'm happy to explore more ideas on integrating third party renderers into the devtools and would love to work something out.

/cc @Havunen

[bvaughn]

Just to connect the dots here, I responded to this on Twitter but I'll summarize my response here too:

DevTools already has the burden of supporting all past versions of React. This adds runtime performance overhead and maintenance complexity, and prevents us from doing certain types of architectural changes that we might otherwise like to do.

My experience with open source is that once you agree to support something, the barrier for removing it is high because people come to depend on it. I'm concerned that agreeing to support additional frameworks would dramatically increase maintenance and release process complexity. As a result, releasing a feature as large as the new profiler– (already a lot of work despite controlling both React and DevTools)– might become too much effort to be worth it if we have to plan the architecture and coordinate release schedules with others too.

This is specifically a concern with DevTools because browser extensions auto-upgrade rather than following a process like semver

That being said, I think some small adjustments (e.g. PR #1178) are reasonable though and we can probably incorporate them so long as there's an understanding that we may refactor things in the future in ways that require changes on Preact's end.

[marvinhagemeister]

We already talked about this on twitter, but posting my response here for completeness:

I fully agree with your statement, after all this repo carries the react- prefix in its name. When working on the devtools integration we ran into 3 problems:

1. The topmost vnode needs to have set the treeBaseDuration property for the devtools to be enabled.
2. memoizedInteractions is the only property that is not read from the .data property but from the fiber node directly. PR Pull memoizedInteractions from DataType instead of Fiber #1178
3. No easy way to attach a custom renderer

Since the we wrote on twitter a few days have passed and I managed to finish our integration. I'm excited to say that we managed to work around both 1) and 3) on our side. Point 2 is something that I think would help the devtools regardless of third-party libraries as it makes the code more consistent in where data is pulled from.

To make this issue more actionable I'd see #1178 as an acceptance criteria. I'm happy to close this when the PR is merged.

[bvaughn]

👍

[marvinhagemeister]

Fixed via f109374