Style error information
https://eslint.org/docs/rules/no-throw-literal
Understanding:
`throw`:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statem...
`new Error`:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global...
Remark
Code Improve. Less hamful
How to Review
## 1. Apply Patch
## 2. Review Code Changes
## 3. Confirm no Code Standard Errors
yarn & yarn lint:core-js-passing
## 4.1 If `NO` errors, mark the issue as `Reviewed & tested by the community` (Don't be shy, we're all friendly)
## 4.2 If `HAS` errors, fix it and upload a new patch (Just do it and you can!!!)
Background
- #2912962: Step 1 JS codestyle: [meta] Fix JS coding standards in core
- We adapted the airbnb coding standard (#2815077: Adopt airbnb javascript style guide v14.1 as new baseline javascript coding standards for Drupal 8 core and contrib), but we are not fully compliant to it yet.
More Information
- Using ES6 in Core
https://www.drupal.org/node/2815083
- To find JS code standard errors stats
yarn & yarn lint:core-js-stats
Valuable Follow-up
- core/modules/quickedit/js/quickedit.js throws JS error. It's not in testcases. It might requred `t` function to translate the string.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2914713-9.patch | 2.68 KB | GrandmaGlassesRopeMan |
| eslint-no-throw-literal.patch | 2.7 KB | droplet |
Comments
Comment #2
droplet commentedComment #3
nod_The string was thrown because there is no need for a stack trace about this message. It might confuse the user that this is a js error when it's really a HTML issue. It's only about warning the user that an attribute is missing.
I'm not sure if we should change it. Might be enough to ignore this one specifically. In any case I don't really care either way.
Comment #4
nod_Comment #5
dawehnerCould we use
console.error()instead?Comment #6
droplet commentedHmm, we might throw a `ReferenceError` instead
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global...
It was introduced by me intentionally (https://www.drupal.org/node/2551373#comment-11927326). But removing by @drpal ( https://www.drupal.org/node/2551373#comment-12180188 ). He didn't explain why but I guess the same stack issue?
@drpal removed the `t` also but I think we should add it back. The CORE tests that faced to CORE developers. It seems okay to drop translations. But for other parties, developers cannot speak English is acceptable. (follow-ups)
`Throw` stopped the script, that's diff to `console`. And I don't quite like the non-ES standard `console` in production env. Developers often stripe it with https://www.npmjs.com/package/gulp-strip-debug or UglifyJS2 (drop_console=true)
Comment #7
GrandmaGlassesRopeMan@droplet
Yeah. I remember this. I don't actually remember why I dropped the
throw new Error(), maybe I intended to useconsole.error()?Comment #8
dawehnerSo what should do do? The documentation already talks about errors. For me at least there is something clearly wrong in your development when this happens, so you should see it as visible as possible.
In other words +1 for the approach.
Comment #9
GrandmaGlassesRopeMan- reroll.
I'm good with this approach.
Comment #10
dawehner@drpal
One question, what happens to other JS on the page if this error is thrown? Is just quickedit broken or is there potential other behaviour not longer applied?
Comment #11
nod_the quickedit behavior crashes and the other behaviors are executed. We have a guard in attachBehaviors to prevent one behavior from stopping everything.
It's only quickedit that might be in a broken state.
Comment #12
dawehnerThank you nod_! I think this is a totally acceptable behaviour then.
Comment #13
xjmSo in terms of
t()and exception messages, for PHP, we have a policy of not translating exception messages for cleaner debugging. There's not()in HEAD so I think that's out of scope here -- is there a followup issue I should comment on?Comment #15
xjmOn the point of what error objects to use (
console.error(),ReferenceError, etc.) adopting a best practice would change more than just this one line. The current patch is the smallest possible change to make core comply with this rule, and given @nod_'s clarification in #11, I think it's safe to go ahead and commit this small cleanup as-is and then explore other changes in followup issues that would apply to all of core.Before:
After:
Committed and pushed to 8.5.x. Thanks!