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

[WIP] first draft of client directory and overall coding style docs #145

Open
wants to merge 1 commit into
base: development
Choose a base branch
from

Conversation

the-vampiire
Copy link
Contributor

have a look and lets develop this PR into a committable first draft

@ghost ghost assigned the-vampiire Nov 6, 2018
@ghost ghost added the REVIEW PR is complete and ready to review label Nov 6, 2018
- intuitive navigation of grouped components

# Guidelines
- always use absolute imports from `./src/path/to/import`
Copy link
Contributor

@thinktwice13 thinktwice13 Nov 7, 2018

Choose a reason for hiding this comment

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

Add jsconfig.json to root

{
    "compilerOptions": {
        "target": "ES6",
        "baseUrl": "."
    },
    "exclude": [
        "node_modules",
        "**/node_modules/*"
    ]
}

But I think target should be ./src. Nothing outside src/ should be imported.

- maximum column length of 100 characters
- new lines at the ends of each file

# Trailing Commas
Copy link
Contributor

Choose a reason for hiding this comment

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

JSX closing tags in new line
Same reasons as trailing commas in multi-line lists

- styles/
- App.jsx
- index.js

Copy link
Contributor

Choose a reason for hiding this comment

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

config/
  - keys
  - apollo
  - ...

@the-vampiire
Copy link
Contributor Author

the-vampiire commented Nov 16, 2018

.eslintrc.js

module.exports = {
    "plugins": ["jest"],
    "extends": "airbnb-base",
    "env": {
        "jest/globals": true
    },
    "rules": {
        "no-console": 0,
        "camelcase": 0,
+        "no-param-reassign": 0,
        "import/no-dynamic-require": 0,
        "import/no-unresolved": [
            2, 
            { caseSensitive: false }
         ]
    }
};

im conflicted over this one

cases:

  • express middleware req property injection (which is recommended from their docs)
  • mapping over one time use arrays while adding properties
  • .then() chains where the source is modified / formed along the chain before being returned at the end

downsides:

  • allows mutation of elements in original list if we are not careful
const arr = [{ one: 1 }];
const mapped = arr.map(el => { el.one = 2; return el; });
arr // [{ one: 2 }]
mapped // [{ one: 2}]

alternatives:

  • deep clone arguments using _.clone()
    • this will be taxing for large lists

@TheSabby @thinktwice13 @serpient (and your husband if he has an opinion on it!)

@the-vampiire
Copy link
Contributor Author

here is another example when using Sequelize hooks that would trigger by the eslint rule

ProjectMember.beforeBulkDestroy((options) => {
    options.individualHooks = true;
  });

@thinktwice13
Copy link
Contributor

thinktwice13 commented Nov 16, 2018

@the-vampiire This is AirBnB config

    'no-param-reassign': ['error', {
      props: true,
      ignorePropertyModificationsFor: [
        'acc', // for reduce accumulators
        'accumulator', // for reduce accumulators
        'e', // for e.returnvalue
        'ctx', // for Koa routing
        'req', // for Express requests
        'request', // for Express requests
        'res', // for Express responses
        'response', // for Express responses
        '$scope', // for Angular 1 scopes
      ]

It already ignores express req and res. We can add Sequelize hooks here, but I'd rather revert to ESLint default which ignores param properties alltogether and then decide later if we need to make it stricter.

@thinktwice13
Copy link
Contributor

thinktwice13 commented Nov 18, 2018

Rules to consider/discuss

  • Airbnb also prefers camelCase. We should all discuss that again
  • Should we consider operator linebreaks? Currently our ternaries are auto-fixed into inline because we only max enforce line length
  • This is a nasty one. We have a lot of click handlers on inappropriate elements
  • Max JSX inline props
  • ESLint is asking me to destructure params from const { voyageId } = this.props.match.params; Anybody knows the rule to adjust this?

@the-vampiire
Copy link
Contributor Author

casing

so sabby came up with this pattern because he didnt know js used camelcase lol. but i really like it and use it across all my projects:

  • snake_case: all local variables and properties
  • camelCase: methods and functions
  • PascalCase: classes / models

it makes it really easy to distinguish what you are working with at any given time. and its easier to avoid spelling mistakes due to capitalization for the most common declarations - variables.

the only place it isntt happy with it seems to be on props. but im fine with overriding that for consistency

linebreaks

  • ternaries > 80 (100?) chars
return methodName(some_argument, and_another, one_more)
  ? a_true_bit
  : a_false_bit
  • long && or ||
  if (
    this_long_thing &&
    one_more_long_part &&
    aThirdOne(called_here)
  ) {
    // do some things
  }
  • lengthy JSX (line length or 3+ props)
return (
  <SomeTag
    prop_one = {some_value}
    prop_two = {some_other}
    prop_three = {() => someMethod(stuff)}
  />
);

nasty one

completely agree. we need to write semantic html. at the very least going forward and refactor when you come across previous code

@thinktwice13
Copy link
Contributor

thinktwice13 commented Nov 24, 2018

prop_three in SomeTag ends up as a snake_case method :)

But I like the idea.
I'd also add CAPS for constants and enums.

@the-vampiire
Copy link
Contributor Author

Ah good point. Actually I like bringing the naming pattern to props as well. Variables snake, methods camel, classes (components) pascal. What do you think?

Sent with GitHawk

@the-vampiire
Copy link
Contributor Author

I can see a case for caps in enums. But not for consts.

On that note think const should be used for everything that won’t be reassigned. 90% of cases are suitable for const. Only use lets during switches or a conditional chain where reassignment is part of the flow.

Sent with GitHawk

@the-vampiire
Copy link
Contributor Author

Const over let is default in airbnb

Sent with GitHawk

@thinktwice13
Copy link
Contributor

thinktwice13 commented Nov 25, 2018 via email

@thinktwice13
Copy link
Contributor

thinktwice13 commented Nov 25, 2018

About bringing the casing patterns to JSX props, I'm good with that if we can enforce it with ESLint. Otherwise I'd rather just stick to one type. I don't care which one (but prefer camel).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
REVIEW PR is complete and ready to review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants