Note: this is a follow-up to my first post on destructuring. Import syntax uses destructuring pretty liberally, and it can be really confusing for...
For further actions, you may consider blocking this person and/or reporting abuse
Well not actually if I understand correctly. The correct way to do it will be
What you wrote works because of bundlers exporting Module as object. But it's not really an object. I don't know the full details.
Consider this code.
If your import is
import React from 'react'
and you usedReact.useState
, what would you expect to be logged in the console? This is the best example I can think of.That's a perfect example, and a great explanation. I think a more thorough explanation is probably due in my post.
Curiosity got the best of me, and I set up a minimal example of what I mentioned in the post... and it turns out it works!
π€ To be honest, the more I think about it, the more confused I am. If you dig into react's source, you can see
useState
is exported just like your example above, withuseState
a child of the object that is exported by default. I wonder if there's not also a separate export foruseState
, too?Ah! I did not look at React's source. So my argument is wrong as well.
My general point is that you should not use non-default exports from the default export. This may mislead your readers.
import * from React from 'react'
would be correct way to do it. But react does not individual exports so it does not apply.One reason why React may be using default export object is because babel transpiles JSX to
React.createElement('div', ...)
calls. If the default export is not an object, then we would have writeReact team may have felt it's better to write
import React from 'react'
instead.Really nice post
Thank you, Ben!
Can someone explain what the @ in '@material-ui' is please?
Hi Johan - the
@
denotes an npm organization.Nice post, thanks!