React is one of the most popular JavaScript libraries for building user interfaces, and one of the reasons it gained so much popularity is its Comp...
For further actions, you may consider blocking this person and/or reporting abuse
hi @lukeshiru it's good to go with typescript, but inn our team just few people only know typescript!
So as for now we continue the
prop-types
but if i component withPropTypes.oneOf
this is not auto suggest. so i feel it's useless âšī¸This is my code! can u give me suggestion or idea why
oneOf
not auto suggest when i import & use this component?Typescript is definitely worth learning. Your teammates that currently don't know Typescript will start writing much better code if they learn it! Also you can combine Typescript with runtime prop types checks if you're using babel github.com/milesj/babel-plugin-typ...
it's looks interesting!
For item #1, I typically use arrow functions, but that doesn't allow you to have a one liner for a default export. i.e. this invalid syntax:
But this works:
and this works:
I prefer the one liner so I typically choose
function
approach for default exports. You can still do named exports withconst
though:i enjoyed every bit of the article and even more the discussions in the comments.
thank you all guys, itâs helping my newbie career.
You can have a nameless default export like that, but then your editor doesn't know how to import it by name when using autocomplete to resolve something that's not imported yet.
That makes sense, though I like the clean look on the import side in the case of default exports. When I read the top of a file, I generally think that named exports in an import statement are "extras" of what that file is exporting, whereas the default is the "main" thing to import. It's also slightly less things for our eyes to parse when scanning imports, when the curly braces are absent. Definitely all preference though. I think pragmatically have them all named makes sense, as you suggested.
This is very much an IDE issue, not a code issue. There's no technical reason not to autocomplete the folder or file name for the import (and, I could be wrong, but I thought jetbrains IDEs did exactly that?).
That said, I'm personally not a fan of immediate default exports anyway. Having a named const that later gets default-exported allows, for instance, attaching further properties to the exported object without needing to rearrange code.
Totally agree. Nice points here, thank you đ
Great overview article. I really liked you mentioned container components, might have been good to expand on that and mention custom hooks to handle logic and state.
Great suggestion, I should expand on this
Some great tips in there.
I'd argue point 1 is negligible though. I don't think mixing between how you define your components makes it harder to read. Messy maybe, but hard to read, no.
As @mickmister alluded to, different ways of defining them affect how you export and ultimately import your component so maybe allowing both patterns is advantageous in different scenarios?
wow! really thanks @lukeshiru đ
@lukeshiru thank you for introducing JSdocs! Great perspective.
Typescripts is the default type safety for most websites building for prop-types is good to know for those who are yet to adopt TS
The reason you shouldn't mutate props is that props are immutable in the user interface.
That's right @lukeshiru and Typescript makes things easy and smart.