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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 Conventions #146

Closed
jimmynotjim opened this issue Oct 3, 2017 · 5 comments
Closed

ES6 Conventions #146

jimmynotjim opened this issue Oct 3, 2017 · 5 comments

Comments

@jimmynotjim
Copy link
Contributor

We need to update the Javascript doc with a consensus around ES6 conventions.

Current behavior

We haven't documented how and where we're using ES6

Expected behavior

ES6 usage is documented.

@jimmynotjim
Copy link
Contributor Author

jimmynotjim commented Oct 3, 2017

This is a pretty good read on arrow functions and I can get behind the How Much Use Is There for Arrow Functions? section (it also happens to match with how we've used them so far).

https://www.sitepoint.com/es6-arrow-functions-new-fat-concise-syntax-javascript/

@mistergone
Copy link
Member

Arrow Functions

It'd be cool if we could use them everywhere they outline in @jimmynotjim 's link above, but I think it makes sense that we consider this a transition period, since we're still writing ES5 in most places (right?), which means "I think we can encourage it without making it a must-do for now."

I'm more interested in pushing for us to use class for functions which are class objects, which I think actually makes code clearer. I'm torn on whether => makes code clearer or not (when applied in the "use it everywhere else" way described in the article). I do think they make code cleaner when used in callbacks of other functions, however.

But...

As mentioned in the original post, I'm not sure where and when we're using ES6.

@anselmbradford
Copy link
Member

We chatted about constants in mattermost 11/8 and I added:

I would generally view the ALL_CAPS as being for simple concrete values that get passed around in a program and wouldn't make sense to replace with var, like const NUM_OF_PLANETS = 8.
I would avoid caps for complex objects or at least consider that carefully, since those can be changed. So for imported modules I would const gulp = require( 'gulp' ); or creating instances, const notification = new Notification(). Also, a local variable within a method, where it would work fine as a var too, I would probably leave it without caps:

function thisDoesGreatStuff() {
  const msg = 'it worked';
  return msg;
}

In the above msg could easily be marked as var, it's just an efficiency thing (I presume) internally that it's const, but it's not a concrete value that's passed around, it's just used in that single method.
Anyway, that's loosy goosy guidance not really backed up but much more than my coding preferences.

I realize I'm violating that in const COMMON_UGLIFY_CONFIG = new UglifyWebpackPlugin(…) too

But the intention there is the UglifyWebpackPlugin instance is not to be modified or have its methods accessed after it is created

@cfarm
Copy link
Contributor

cfarm commented Nov 14, 2017

what @mistergone said

As mentioned in the original post, I'm not sure where and when we're using ES6.

would be cool if folks who've written es6 can post links to the code here so we can see what we're working with. for example i know cfgov-refresh uses es6 in gulp tasks:

https://github.com/cfpb/cfgov-refresh/tree/master/gulp/tasks

@jimmynotjim
Copy link
Contributor Author

Completed in #177

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants