Eslint-plugin-import: no-named-as-default with React, Redux

[qmmr]

Hi, I've got an error when linting my App.js file.

error  Using exported name 'AreasSection' as identifier for default export           import/no-named-as-default

App.js

import AreasSection from './AreasSection';
/* code */

AreasSection.js

import React, { Component, PropTypes } from 'react';
import { connect } from 'react-redux';

class AreasSection extends Component {
    /* code */
}

export { AreasSection };
export default connect(mapStateToProps)(AreasSection);

I use default for real usage and named exports for testing. Is this because the component is wrapped with connect?

[benmosher]

This is a precedented confusion with no-named-as-default (see #468).

TL;DR: this common pattern and no-named-as-default cannot coexist. It's just a warning to identify a _possible_ error, and in this case, it can't do its job, unless you rename the named, undecorated export to something else, like

export { AreasSection as Pure }

which, again, is a diversion from this common (and totally fine) Redux component pattern, and thus may be worse than just disabling this rule.

[qmmr]

Unfortunately, React + Redux is the most common scenario. However, there are lots of other cases where HOCs will force developers to shut down this rule.

[skychx]

your code：

/* code */
export { AreasSection };
export default connect(mapStateToProps)(AreasSection);

Delete this line： export { AreasSection }

[mehmetnyarar]

I developed a strategy like naming my component as 'Component' and exported it via export default connect(mapStateToProps, mapDispatchToProps)(Component);. Simple, yet it works and there's no confusion.

[mariustop]

@mehmetnyarar and what do you do if you want to export the Component for testing without connect() ?

[ljharb]

@mariustop you don't want that. If it's never used in production without connect, there's no value in testing it without connect. Use .dive() instead.

[antondomratchev]

@ljharb It is terrible to suggest that your components should be tested with your stores attached. Anytime your store changes the component test will break even in non related changes. I think there is a use case for this rule but in no way should it determine your testing strategy.

[ljharb]

I highly disagree; I think it's terrible to test your store-connected components in conditions that they'll never exist in in production, namely, without the store.

[antondomratchev]

I find value in testing components as they will be rendered by the browser using snapshots. That being said, testing the state machine to fetch, process and deliver props to the component in their expected structure is just as important. However, coupling the two inside of a single test, from my experience, only leads to a more complex and fragile test.