mindtech-package-test
v1.0.18
Published
npm scope test
Downloads
4
Readme
mindtech-package-test
Package install steps
- npm i mindtech-package-test --save
- Go to project/node_modules/mindtech-package-test/package.json
- copy the “install-mindtech-peer-dependencies” script into the project scripts (project/package.json)
- run script: npm run install-mindtech-peer-dependencies
- DONE
Linter FAQ / tips:
Common rules / mistakes:
- eslint(class-methods-use-this) : A függvénynek arrow functionnek kell lennie
- eslint(consistent-return) : A függvényeknek mindig kell valami return. Ha a függvénynek több feltétele is van ami miatt abortolna a függvény, azok legyenek elől és a végén ha nem abortolt a függvény akkor lesz a sikeres return
if (abortCondition1) return null;
if (abortCondition2) return null;
if (abortCondition3 && abortCondition4) return null;
return (
...successfullyRenderedComponent...
)
eslint(no-unused-expression) :
- legyen kiírva rendesen az "if" az olvashatóság és bővíthetőség miatt:
if(condition) do();
-JSX-re nem vonatkozik a rule és lehet használni, ettől függetlenül a hosszú és átláthatatlan ternary erősen elkerülendő
no-case-declarations VS switch-case/no-case-curly
- no-case-declarations: Logikát az actiönnek kéne csinálnia mert a reducer egy egyszerű PureFunction. Ha értékadás történik benne akkor valószínű nincs jól megírva az action mert logikát tartalmaz a reducer. Értékadáshoz legtöbbször nincs szükség a payload destructoringra.
- switch-case/no-case-curly: case ne legyen curly bracebe -> azért lenne curly brace mert értékadás van benne -> logika -> nem jó az action
Linter probléma megoldásának menete:
- ha nem egyértelmű miért van aláhúzva, mouse hover
- Quick fix...
- show documentation for rule
- elolvasod a részletes leírást, legtöbbször vannak példák, jó és rossz felhasználások és leírás hogy miért szükséges a rule
- Fixeled vagy ha nem világos megkérdezel valakit
HIT custom
- no_underscore_dongle ON -> OFF
- no githook