2

What is the point of importing React and then importing the Component as well if you can simply access the Component directly from React anyway?

This is what I mean.

You can do:

import React, {Component} from 'react'

and then write

class SomeComponent extends Component

but you can also do:

import React from 'react'

and then write

class SomeComponent extends React.Component

What is the difference here? What pain does the first approach really relieves? It seems to me that the second option is much more concise and that the first option is pretty redundant because you have access to Component whether or not you import it explicitly.

A much clear analogy would be:

import Animals from 'the-world';

This would get all animals in the world. Now why would one want to write:

import Animals, { Goat } from 'the-world';

If Animals get all animals in the world, then why import Goat separately. I mean it exists already in the Animals object.

Siya Mzam
  • 4,655
  • 1
  • 26
  • 44
  • https://stackoverflow.com/questions/41768205/difference-between-import-react-and-import-component-syntax – Bergi May 05 '18 at 21:01
  • @Bergi, The question there asks about the syntax difference not about redundancy. That question is more about default exports and normal member exports. I am asking about the use of importing everything and then in the same line try being specific about what is being imported. So this is not a duplicate. – Siya Mzam May 06 '18 at 04:48
  • For instance, the poster there asks why do `import {Component} from 'react' and not do `import Component from 'react' `. That is not what I am trying to find out. I am trying to find out that if importing React gives you access to its members; Component for example then why the need to write import React, { Component } from react? I mean one could just import React and right there has access to Component without having to explicilty import Component. – Siya Mzam May 06 '18 at 04:59
  • I mentioned the question in the comment just because I thought it might be helpful. For the answer to your question, see the duplicate: In general, named imports are preferred and more concise, it's just that `react` specifically also exports everything on an object redundantly (mostly for backcompat). – Bergi May 06 '18 at 10:09
  • Oh well, but you marked my question as a duplicate even though it is not. – Siya Mzam May 06 '18 at 11:25

2 Answers2

2

When you import React from 'react' you import an Object with some properties. You import everything.

When you do import {Component} from 'react' you will only import that only one module. By doing this you import far less code to your application (because you only require this part of the library).

However, in real case scenario, your app will require everything anyway so it's up to you how you decide to use it - by destructuring required module or by accessing it on default exported object.

Tomasz Mularczyk
  • 34,501
  • 19
  • 112
  • 166
  • I get that, but you never import just Component, you have to import React too. So if importing React gets the whole thing, then what is the point of being specific about the next module that you would like to import? For instance importing just Component would cause the program to break because React is out of scope or not imported rather. So one HAS to import React all the time. – Siya Mzam May 05 '18 at 06:02
  • 1
    Nothing. In this case it's only a matter of what "looks" better to you. – Tomasz Mularczyk May 05 '18 at 06:04
  • If `import animals from 'the-world'` gets all the animals in the world, then why the hack would one want to `import animals, { goat } from 'the-world'`?!?! I mean, goat is within animals. Why the specificity? – Siya Mzam May 05 '18 at 06:07
  • 1
    You are right, there is no point, I believe. It's just common that people do that. – Tomasz Mularczyk May 05 '18 at 06:09
  • I see, I see. In my opinion, it seems like it's bad practice because it is useless. – Siya Mzam May 05 '18 at 06:22
  • I would say it's useless not a bad practice. In react documentation, they are always using `React.Component` though. However I can see that `import { Component } from 'react'` may benefit some libraries that need just that. – Tomasz Mularczyk May 05 '18 at 06:24
  • Hmm, yeah you're right. I was not thinking about that. But wait, is there any library that you know of that completely relies on you having to import just Component? If they want Component, isn't it their job to make sure they import it in their library? – Siya Mzam May 05 '18 at 06:29
  • Yes, it's their job. I was justifying one use case for library authors that would import `Component` alone. – Tomasz Mularczyk May 05 '18 at 06:34
  • I hear you. Thanks so much. I like both answers. I prefer the other one though, so will mark it as the accepted. – Siya Mzam May 06 '18 at 05:03
2

In case when individual exports like Component are imported, React is usually unnecessary. It's a matter of style, for the most part.

Component takes less characters to type (also can make use of IDE auto-import), while React.Component namespace makes framework imports easier to recognize. They have roughly same footprint in minified output due to how ES modules are transpiled.

React.Component style is compatible with cases when React is loaded globally.

React namespace also makes it easier to refactor the project to use another React-like framework (Inferno, Preact) and vice versa, because some import names may be different or require additional attention. They can be easier matched with a namespace.

It's always preferable to use

import * as React from 'react';

instead of 

import React from 'react';

because default import results in entire package being imported, unused properties don't have a chance to be tree-shaken. It's not possible to import both Component and * on same line because of syntax limitations - but usually there is no need for that.

Estus Flask
  • 206,104
  • 70
  • 425
  • 565