This gist describes a challenge I've encountered while maintaining the React DevTools browser extension, and briefly explores one possible way to address that challenge. I would be happy to talk more in depth about this topic with anyone from Chrome/Firefox/Edge who would be interested in exploring.
The React DevTools browser extension supports all versions of react-dom released after 16.0.0-alpha (2017). We do this because developers often switch between projects built with different versions of React, and installing/enabling multiple versions of the extensions would be cumbersome.
This has a cost though: It adds a lot of complexity to the extension.
The implementation details of a library change frequently. Sometimes they change in a straightforward way. Other times, the changes can be more complex and impact multiple parts of the extension. In some cases, we have to resort to forking large sections of the extension. Sometimes we get this wrong and cause serious bugs for applications using specific, older versions of react-dom.
Even when we get things right, the size and complexity of the extension will grow over time, as will the effort required to regression test and maintain it.
Developers using React should only have to install a single browser extension. The user experience of having to install multiple extensions, and remembering enable/disable them when switching between projects, would be awful.
Does this mean we are at an impasse?
What if a browser extension could act as a shell, one that includes some minimal amount of code to detect things like which version of react-dom is present on a page, and then load (and cache) a build of the extension capable of interacting with whatever it detected?
This would provide several major benefits:
- It would simplify regression testing and eliminate an entire category of bugs (e.g. changes made to support
react-dom@^17could no longer accidentally breakreact-dom@^16). - It could make the download and parsing cost of running the extension cheaper. (If I'm only building websites with
react-dom@16, I shouldn't need to download code that knows aboutreact-dom@17.) - It would enable extension developers to more easily change and improve an extension in newer releases (without the burden of permanently maintaining backwards compatibility).
Some constraints would be necessary for this new type of extension. For example:
- They could only load code from trusted sources (e.g. the browser extension store) to ensure that any code running in the extension had been properly reviewed.
- They would probably have minimal interoperability (to reduce coupling between releases/versions).
- Some sort of fallback hook would need to exist for extensions running offline (if a matching implementation had not already been downloaded and cached).