Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

React: More templates/progress components converted to ES6 #18525

Merged
merged 6 commits into from Oct 23, 2017

Conversation

islemaster
Copy link
Contributor

More of these... we queue a long time for OSX containers on Travis 馃榿.

Copy link
Member

@davidsbailey davidsbailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice progress Brad!

@@ -58,12 +58,12 @@ const styles = {
/**
* A set of one or more levels that are part of the same progression
*/
const ProgressLevelSet = React.createClass({
propTypes: {
export default Radium(class ProgressLevelSet extends React.Component {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this kind of inlining a new best practice? I thought the export default Radium(ProgressLevelSet); you removed was somewhat more standard in our codebase, but I see now there are a few instances of this new pattern cropping up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I picked this up after I noticed Paul doing it. I like it for a couple of reasons:

  1. I prefer the inline export for the component when it's convenient to do so - I just find it more scannable.
  2. A component designed with Radium features in mind should probably never be used without Radium.

On the other hand, @Bjvanminnen pointed out that this isn't a great pattern for react-redux's connect because it's fairly common for us to export both a connected and unconnected version of a component - and it's much harder to read. I'd be interested to hear his thoughts here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love the readability of this. There's a lot going on here:

export default Radium(class ProgressLevelSet extends React.Component {

It gets marginally better if we import Component from React instead, though still not great

import { Component } from 'react';
export default Radium(class ProgressLevelSet extends Component {

I think the thing I like least is that the class name gets buried in the middle. Even something like this I would prefer

const ProgressLevelSet = Radium(class extends Component {

but that doesnt help us because we can't then do export default on that same line

If we were using ES7 decorators (something I've been somewhat resistant to thus far), this would be improved as well I think

@Radium
export default class ProgressLevelSet extends Component {

In general, I think my choice would be to stick the Radium at the end of the file, but I don't think I care as much here as I do for connect, just because the call to Radium is much simpler than everything we pass to connect

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is not a pattern we've already accepted, then my vote would be to keep the export default Radium(ProgressLevelSet) on a separate line. This prioritizes clarity above other concerns, whereas the export default Radium(class ... seems like too many different things crammed into one line.

I do like export default Radium(class ... From a "pit of success" perspective, because you can't forget to use Radium when you export e.g. an Unconnected component. The const ProgressLevelSet = Radium(class extends Component { syntax also accomplishes this. However, I don't think this will be a super frequent problem.

In case anyone's curious, here are the only places we use connect, Radium, and export and Unconnected component all within the same file:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I sent that last comment a moment early. Disclaimers: I don't think the syntax shown in this PR is particularly heinous, so I'm fine with doing it this way or generally allowing both if those seem easier than trying to have a standard for this.

Thanks for doing all this ES6ifying, Brad!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like Radium(class only happens in 24 places right now. I see the argument for less on a line. If you both prefer that I'll update this PR and do some followup cleanup of other places we've done this.

</div>
);
});
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

馃憦 馃憦 馃憦 nice tests!

@islemaster islemaster merged commit 28b4776 into staging Oct 23, 2017
@islemaster islemaster deleted the react-es6-progress-third branch October 23, 2017 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants