Add new JS linter rules

[silverwind]

Adds a few useful rules from eslint-plugin-github. Notable changes:

• Forbid dataset usage, its camel-casing behaviour makes it hard to grep for attributes.
• Forbid .then() and .catch(), we should generally prefer await for new code. For rare cases where they are useful, a eslint-disable-line directive can be set.
• Forbid array#forEach, for-of is superior because it allows flow-control statements.
• Add docs js to linting

[wxiaoguang]

About "Forbid dataset usage", what's the recommended way to bind a variable to a DOM node?

For example, in the legacy code, we bind a SimpleMDE object to the textarea DOM node's dataset.

[silverwind]

what's the recommended way to bind a variable to a DOM node?

I would recommend against such techiques but I think either jQuery's .data() (which is not really dataset when writing data iirc), or just plainly modifying the DOM node, e.g. el.mydata = {} may work.

[wxiaoguang]

what's the recommended way to bind a variable to a DOM node?

I would recommend against such techiques but I think either jQuery's .data() (which is not really dataset when writing data iirc), or just plainly modifying the DOM node, e.g. el.mydata = {} may work.

I think we had better make an agreement and write it into the guideline.

1. For jQuery, $.data() is fine.
2. For plainly modifying the DOM node, I don't think it is a good idea. It will make potential conflicts and more mis-usages than dataset. Maybe we can introduce something like getNodeData()/setNodeData() in our framework, get/setNodeData can use dataset internally and skip eslint.

[silverwind]

getNodeData()/setNodeData()

Sorry, but this seems overkill to me. dataset is just a wrapper around data-* attributes which have the big drawback that they can only store strings, so I would generally only use them to communicate data from server to client like we currently do. For data-* access use getAttribute, setAttribute, hasAttribute. I would consider disallowing .data() in favor of .attr() too.

Any other cases should aim to not attach non-string data directly to DOM elements to re-use later, this is a big anti-pattern. Stuff like that is not even possible with React/Vue for example, the canonical way is to use state variables because those outlive the lifetime of DOM nodes.

[wxiaoguang]

So the conclusion can be:

1. For legacy code, $.data() can be used to bind some non-string data to elements, string data should use $.attr() or get/set/hasAttribute.
2. For new code, we should never bind any data to DOM node, using node.dataset is also forbidden.

Right?

[silverwind]

Yes, sounds right. I would also consider removing/refactoring the existing .data() cases in a future PR.

[wxiaoguang]

Would you like to write the conclusion into the frontend guideline in this PR, or would we update the guideline in other PRs?

[silverwind]

I think we can handle it during review and/or via linter. I guess it shouldn't actually be hard to create a custom eslint rule that forbids .data() for example.

[wxiaoguang]

Some conflicts with main branch

[zeripath]

conflicts resolved.

[lunny]

make L-G-T-M work