Repository: material-ui
Issue: [RFC] Avoid or "prefer not to use" default exports 
Labels: discussion,v6.x,RFC

## Introduction 

This discussion was initiated during the migration of eslint configs of `material-ui/pickers` and convention and code style consolidation. (https://github.com/mui-org/material-ui-pickers/pull/2004)

# The problem 

The core repository is using `export default` everywhere as a primary way to export React components.  This RFC is about why it is not the best approach – the main problem of the default exports is **implicit renames**. And this unexpected renames leads to the following problems: 

### Consistent naming between all files 

When `export default` is used it allows anonymous renames on the importing side:

```js
export default function Modal() {
... 
}

// importing file
import Dialog from '../..'
```

Here it appeared that the component that has `displayName="Modal"` and actually is a `Modal` in the code reads like `Dialog` which is weird because it has its own defined name. This can also lead to the discrepancy between the component name in the component and display name in the dev tools. 

### Problems with refactoring 

If we have an allowed implicit rename it could be tricky to find all the places when the component is used. And automated refactoring will also do nothing because rename is totally allowed

> Make sure that for named exports there is a strong AST link for the rename `import { Modal as Dialog }` which is simplifying refactoring and make any rename explicit

### Poor importing experience

Discoverability is very poor for default exports. You cannot explore a module with IntelliSense to see if it has a default export or not. With export default, you get nothing here (maybe it does export default / maybe it doesn't (¯\_(ツ)_/¯). And also it doesn't autocomplete by the component name, while for named exports – it does. 

```js
import /* here */ from 'something';
```
Without export default you get a nice intellisense here:

```js
import { /* here */ } from 'something';
```

### More solid imports section

When there are no `default` exports through the codebase 

```js
import * as React from 'react'; 
import Typography from './somewhere' 
import { util } from './somewhereElse'
import Default, { andSomething } from '../'
```

Without 
```js
import * as React from 'react'; 
import { Typography }  from './somewhere' 
import { util } from './somewhereElse'
import { Default, andSomething } from '../'
```

And as **huge bonus** for typescript users:  Props importing experience will be much clearer 

```jsx
import { Typography, TypographyProps } from '@material-ui/core'
```

For now, the only way to import props is:

```jsx
import Typography { TypographyProps } from '@material-ui/core'
```

## Normal flow of things

Originally the goal of export default (I am 99% sure) was intended to export something when we don't really know what we exporting. The best case of `default export` power is dynamic examples – when we don't really know which component we need to import and render. Or for example `next.js`'s page loader – when it also doesn't know which pages it needs to process exactly. 

When we have a specific object that we need to export – we should name it and use this name consistently through the codebase.

## Potential problems 

Default exports were loved by react community because of `HOC`. It was really useful to do 

```
export default withStyles(Component)
```

It is not possible with named exports, but we could have a convention about naming private components in the file

```js
function _Component() { 

}

export const Component = withStyles(_Component)
```