-
Notifications
You must be signed in to change notification settings - Fork 47.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Add react-is package #11279
[RFC] Add react-is package #11279
Conversation
packages/react-is/package.json
Outdated
"main": "index.js", | ||
"repository": "facebook/react", | ||
"engines": { | ||
"node": ">=0.10.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We support Node 0.10?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copypasta from https://github.com/facebook/react/blob/master/packages/react/package.json#L20-L22
I guess we don't include that in other packages..?
Are we going to support a |
packages/react-is/README.md
Outdated
```js | ||
import React from 'react'; | ||
import {createPortal} from 'react-dom'; | ||
import {isFragment} from 'react-is'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/isFragment/isPortal
Can be used without any dependency on React. Plausible replacement for React.isValidElement.
It's not part of the "Node" types. Although that begs the question if we should have I also think that in general it is bad practice to treat component types as something special because if you do, it means that you can't accept other types like functional components or possible future module components. That said, we do treat them as something special inside React itself anyway. |
Btw, I think that ideally the We could expose these matchers on placeholder constructors so that you could do something like this to match: match (x) {
React.Element: ...,
React.Fragment: ...,
React.Portal: ...,
React.Component: ...,
} |
This is a good idea! My two suggestions would be:
|
We should probably get back to this after ES modules. Since then it's less annoying to import this package from internals. Tree shaking ftw. |
ES modules are done, is this still something we want to do? |
@gaearon I didn't expect that we would import this from internals. This would just be stand alone package as a convenience that we don't depend on. |
It would be nicer if it was imported internally, but as long as it wa guaranteed to keep apace with React internals that’s the same imo. |
Talking with @ljharb, there are some internal methods like We expose |
I like this idea. |
Reflection is always where I get nervous. It has so much benefit and zero downside if everything stays the same forever... and that's where it is dangerous. |
For “get component name” and “is valid element”, having a separate package that doesn’t depend explicitly on React creates conveniently used abstraction points so that if React ever does change the meaning, people can transparently get the updates. I don’t see either of those as reflection, tbh. |
I believe we already expose the only reflective utilities that would be useful to expose, so For context, Enzyme uses |
To be clear I’d only include the truly safe ones. For example getComponentName is trivial but annoying to copy paste everywhere. |
|
@gaearon How do we avoid such uses making their way into popular libraries? Not saying people won't do it anyway using @aweary The things we do today are already problematic and not an argument that we should cement them further. E.g. several things on ReactFiberTreeReflection we know that we'll need to deprecate and Enzyme's usage of them is a prime example of how popular libraries makes it harder for the ecosystem to do so. I don't know if we can justify the amount of time we spent on that for 16 again. Sometimes there are legit problems that can't be solved any other way and sometimes it just requires a few more back and forths to create a design that doesn't need that introspection. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is written with our regular package structure I'd be cool with releasing it.
Superceded by PR #12199 |
Authoritative cross-realm brand checking library. Can be used without any dependency on
react
. Plausible replacement forReact.isValidElement
.Builds on the idea of https://github.com/jasnell/proposal-istypes