You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 26, 2020. It is now read-only.
basically this would be a new tab in the devtools displaying what's inside the caches, giving the author control over key-based invalidation for easier testing and debugging. I'm sure there are more needs we don't even know about yet, but generally the idea is to have a cache-library-agnostic way to hook into caches (so that hopefully we don't all have to install a million other chrome extensions, but also take advantage of unique knowledge about Placeholders that the React Devtools should own).
There's a possibility that every cache library will want to implement their own devtools but that feels duplicative and it's likely to be a hurdle to smaller teams wanting to try writing cache libraries. I feel like the best place for this is with react-devtools, but reasonable people might disagree. Anyway, just raising the idea.
Because version 4 was a total rewrite, and all issues in this repository are related to the old version 3 of the extension, I am closing all issues in this repository. If you can still reproduce this issue, or believe this feature request is still relevant, please open a new issue in the React repo: https://github.com/facebook/react/issues/new?labels=Component:%20Developer%20Tools
basically this would be a new tab in the devtools displaying what's inside the caches, giving the author control over key-based invalidation for easier testing and debugging. I'm sure there are more needs we don't even know about yet, but generally the idea is to have a cache-library-agnostic way to hook into caches (so that hopefully we don't all have to install a million other chrome extensions, but also take advantage of unique knowledge about Placeholders that the React Devtools should own).
There's a possibility that every cache library will want to implement their own devtools but that feels duplicative and it's likely to be a hurdle to smaller teams wanting to try writing cache libraries. I feel like the best place for this is with react-devtools, but reasonable people might disagree. Anyway, just raising the idea.
Relevant code:
The text was updated successfully, but these errors were encountered: