Frontend JavaScript Anti-pattern
Number of word 1654
TL;DR
- 自分のエゴで書いてる手癖や無駄な努力をコードレビューするのは非生産的
- 積極的にlinterを採用
test
import assert from "assert";
describe("test", () => {
const { func } = require("./module");
it("func", () => {
assert(func("a") === "a");
});
});
- 1ファイル、single
describe
- 親を1つ
describe.skip
describe.only
できれば一旦闇を保留にできることが多い - 1ファイルの持っている役割が大きすぎない、特に困っていない
- 親を1つ
- テスト対象は
describe
の中でrequireするdescribe.only
実行をした際に不要なsrcを読み込まなくて良い- 読み込まれただけで実行される関数はcoverageに含まれてしまう
coverage report
が読みやすい
this
を使わない- unused変数をlintで発見しやすい
- 長い
src
function mapStateToProps({ todos }: State) {
return {
tasks: { todos },
onUpdate: (id) => todos[id].done(),
}
}
arrow function
vsfunction
- IE11を意識した場合、変換したら結局
function
となる - 読みやすさと生成された後のコードを妄想しつつ相談
- つい書きやすさと
return
の省略したさでarrow function
を使うことも多い - 読みやすければそれでいい気持ちになってきている
- IE11を意識した場合、変換したら結局
class
syntaxを避ける- ライブラリを開発しているときには使うけれどプロダクトを書く時には意識する
- 結局
this
に状態を持たせる意味がそのclassにあるかが大事 - ファイルサイズがデカくなる
var touch = "touch";
$("#id").on(`${touch}start ${touch}end`, (e) => {
console.log(e);
});
function a(element) {
// var element と書く3文字を省略して1文字にできる
element = document.getElementById("foo");
element.addEventListener("click", (e) => console.log(e));
}
- 長い文字列は変数で受けて結合する
- 小さいことを売りにしているライブラリで見る
- 計算量も大事だが地道なファイルサイズ対策
- 無駄な引数を定義する
- 変数定義分の文字列を節約させる
- htmlのタグなどを書く際に利用されている場合がある
- linterで積極的に使うなと怒られる(怒られる方が平和)
まとめ
圧倒的老害感。