I understand the benefit of PropTypes, but I'm curious as to when it's a not good idea to use 'isRequired' in React PropTypes. I understand that if isRequired is not passed, then the value that is being passed to the object wont throw a warning if that props is not in use.
I've been working on quite a big project and i don't really see any specific reasons as to why 'isRequired' is given or not. Is it passed when the object using that prop wont function without it? if so, then when is there a case when 'isRequired' is not a good idea?
Related
I'm writing React with Typescript and, after making a change to my code, I started seeing Objects are not valid as a React child errors.
I had changed a property from a string to an Optional<string>, so the error totally makes sense since my <div>{property}</div> code was no longer correct.
So, this is a type error being caught at runtime.
I'm not doing any casting or any other code "tricks" to try to subvert pre-existing type checking; I'm just rendering a value that React detects at runtime to be an object.
It seems to me that an appropriate linting rule or typescript configuration should have been able to capture that property is no a valid React child.
Here's a very simple example (TSPlayground):
type Props = {
example:{}
};
const Foo = ({example}: Props) => <div>{example}</div>
I would expect an error pointing to the use of example inside the JSX.
I've been doing some googling, but I can't find a rule that seems like it would catch this.
Is there one that anyone knows of?
As others have mentioned there's no such a feature available right now. Furthermore linters are more geared towards styling than capturing compilation errors. I don't think what you're asking is possible because example is a dynamic type and setting it to a string makes it a valid JSX node while setting it to an object makes it invalid. Since JS is a dynamic language we cannot know this ahead of time. Typescript helps in this case, but that's a separate type system from eslint rules and as #jonrsharpe has mentioned in the comments there's an issue on typescript repository to add the feature you're requesting (#35622).
I have a component that works fine but one of the props is type "string" and I would like to pass a component or simply make the data type "any". Is there a way to do this?
To make this more clear, I am trying to modify the behavior of a third-party class. This is in this case very safe and I have changed the 3rd party code directly but it is much better, if possible in Typescript, to inherit and in the inherited class, change the data type of the prop so that I can, instead of simply displaying text, display, for example, a list.
Well, imo passing in type any usually defeats the purpose of using Typescript in the first place. The way I understand it , you have two options:
Separate the props: have a prop of type string and another of type ReactNode since it is a component you are planning on passing in.
If for some reason it has to be a single prop, use string | ReactNode as its type. Although I would recommend option 1 over this.
Thinking even further, you might want to consider not passing a component as a prop at all(for performance reasons). Designing your components such that you can work with doing regular ES6 import to get in a component would be much much better, but again this depends on your usage and design.
I'm using React with Flow. If I forgot to set some requiring props when rendering, Flow gives me error so I can prevent the problem.
However Flow is not actually working on runtime. So if the value that I used were treated as number wasn't number, Flow can't catch this. For example, if the value was coming from somewhere else, like server side and if it was string, but Flow just treated as number so eventually I will get some errors in runtime.
But PropTypes works in runtime, so in the same case I'll get the error message that PropType expected number but actually it was string.
It's also possible to happen when the API were changed and returning data is different. It could undefined or whatever, possibly not actual value I expected.
So I'm using Flow and PropTypes both actually, however I searched on about using both together, but couldn't find any related informations.
Instead, all I found was just "Flow" replaces "PropTypes". I don't think so, I already mentioned about difference between these two. These two works totally different and each of them have so many good benefits to use, so combine them will have nice synergy, I think.
However now I'm using both, I have to define types for props and also define propTypes and defaultProps always, and it makes my code actually pretty long and takes lots of time just make single component.
Should I stop using Flow and PropTypes together? I think Flow is better than PropTypes, there were so much benefits when using static type checker so I want to keep using it. Also there's nice VSCode support for Flow, but not proptypes.
If I use Flow, is PropTypes doesn't needed? Any advice will appreciate it.
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
This question already has answers here:
What's the difference between "super()" and "super(props)" in React when using es6 classes?
(10 answers)
Closed 4 years ago.
Can someone please tell me why we need to pass in props to constructor() and super(). I've read a lot of questions regarding this, and also a lot articles too. All saying you should pass in props to constructor and super so that you may access this.props.....
All of my code still works if i do not pass in props to constructor or super. And I can't see any scenario where this would change. Unless i wanted to console log this.props, which could be achieved by console logging this anyway.
Also on a side note, half of the developers I've spoken to, do pass in props, and the other half do not, because they feel they don't need to, yet aren't exactly sure why this happens.
Can anyone shed some light on this for me please?
Thanks
The only reason someone needs to pass props is if you want to do something with them in the constructor. Maybe you want to do some computation on props in the constructor -- I'm not sure you can just do that outside of the constructor even though you have access to props without the constructor.
The documentation gives the example of assigning initial state utilizing props in the constructor. In the case of components with local state, this is a good use case for passing props to the constructor.
Additionally, this this SO answer sheds some light on why you need to pass props to super in ES6.
Though, much of this can be disregarded in the sense that you could just not pass props to constructor and initialize your local state without it due to class properties of state and props. Check this Hacker Noon article going through some of the "use cases" of constructor and their alternatives. One thing to point out is that the author mentions that Babel transpiles your code for you to add a constructor -- you just don't see it. Ultimately, I suppose if it is a matter of removing the constructor, you can do it as a matter of preference as also pointed out by Dave Ceddia. Removing the constructor, though, seems to have the added benefit of removing boilerplate and keeping code a bit cleaner.
Ultimately, the author concludes:
We’ve seen that for setting our initial state, we no longer need a constructor (or any other instance property for that matter). We also
don’t need it for binding methods to this. Same for setting initial
state from props. And we would most definitely never fetch data in the
constructor.
Why then would we ever need the constructor in a React component?
Well… you don’t.
[However… If you find some obscure use case where you need to
initialize something in a component, both client-side and server-side,
you still have an out. There’s always componentWillMount. Internally,
React calls this hook right after “newing” the class (which calls the
constructor) on both the client and the server.]
So I maintain that for React components: The constructor is dead, long
live the constructor!
New to ReactJS. Got this on a "join reactJS event questionary" but was unable to compile it. It seems to be missing a React Component class definition for the Item and List.
Is this shorthand style valid?
Is this shorthand style valid?
yes, it is valid code, List and Items are Stateless functional components
In order to run this code you need use babel with babel-preset-react
Yes, they are stateless functions, aka "pure components". They take their props as their only parameter and return the render results. If you do not need to keep track of any state, they are very lightweight both to understand mentally and in terms of the resources needed by React to manage them.
As to why you were unable to compile it, possibly you do not enable the right ES6/ES2015 features in whichever compiler you're using. You are using among other things super calls, object destructuring (in the parameters) and arrow functions. For help with this, provide the specific error message.
It is a valid javascript es6 code, except that multiple dynamic children (here the list of Items) need to have key prop https://facebook.github.io/react/docs/multiple-components.html#dynamic-children