[WIP] Update order-in-* rules to handle native class syntax

[tylerturdenpants]

This is the very beginning. I'm looking for feedback on a few things:

• Actions: in classic classes actions were in a hash, but in native classes they aren't. Should they be ordered by line count as well?

-Computeds: same thing as the actions.

-tracked?

Fixes #417. Related to #560.

[bmish]

These changes are looking pretty good so far. Excited to get this in. But I'm a bit unclear on what your questions are asking.

[bmish]

Can you also delete the "Help Wanted" section from the docs for these rules (which I added recently in #669)?

[tylerturdenpants]

Finally getting some time to get back to this. let me see if I can clear up my questions

When using classic classes, actions were in a hash and with default ordering:

const ORDER = [
  'service',
  'property',
  'empty-method',
  'single-line-function',
  'multi-line-function',
  'observer',
  'init',
  'didReceiveAttrs',
  'willRender',
  'willInsertElement',
  'didInsertElement',
  'didRender',
  'didUpdateAttrs',
  'willUpdate',
  'didUpdate',
  'willDestroyElement',
  'willClearRender',
  'didDestroyElement',
  'actions',
  'method',
];

this hash was the thing being ordered, not the contents inside. I don't think (at least I don't remember) that the actions in that hash got ordered by line number.

With native classes, actions are not in a hash and could be considered to be ordered like method property because there can be any number of them.

So my question is, do we sort actions like we do properties (for example) and/or do we also order them on all of their traits - ie single / multiline plus the actions:

@action
foo(){

}

@action
bar(){}

where bar and foo would be not only ordered because they where actions, but that bar could be configured to come before foo?

This extends into computed properties as well:

@computed('a', 'b', 'c')
get foo(){

}

@computed('e, 'f', 'g')
get bar(){}

So in my code I have added 2 new sorting groups action-single-line-function and action-multi-line-function, to try and capture the other traits.

const ORDER = [
  ...
  'willClearRender',
  'didDestroyElement',
  'action-single-line-function',
  'action-multi-line-function',
  'actions',
  'method',
];

Does this make a little more sense? If not you can find me on discord under the same name.

[cdtinney]

The new sorting groups sound reasonable to me, although there is slight additional overhead for consumers.

PR looks good but the order-in-* docs should be updated to reflect these new groups.

[cdtinney]

Why's this commented out?

[tylerturdenpants]

This is temporary to know the valids were still passing while I was working on something else. I wanted to get direction before I moved forward.

[cdtinney]

Can we document this somewhere?

[tylerturdenpants]

Of course! I find this incredibly useful. If you think it's a good addition, I will add it to the README

[tylerturdenpants]

@cdtinney Sorry for the half baked PR. Before I went any further I wanted to get at least some consensus on a direction since native classes kinda changed the reasoning behind the ordering. I will clean up my PR. I have added WIP, something I should have done earlier

[bmish]

Can you move this hasDecorator function to utils/utils.js? types.js is only supposed to be for basic type checks.

[Alonski]

@tylerturdenpants Just want to show my support for you doing this 😜

[TSenter]

I would also like to show support for this 🙂 has there been any progress, or is there anything that can be done to support this? @tylerturdenpants