Closed27
記事にできそうなネタ帳
Next.js で WebWorker を含むビルドがうまくいかない問題。
原因は Code Splitting とおもわれ
react-hookz/web の便利 hooks について
Web Share Target API 試し打ち
ぼくのかんがえたさいきょうの React × CSS Modules 陣営
MRZ (Machine Readable Zone) のルールについて
&ツール紹介
プロジェクトを成功させるために気をつけていること ... 実装者編
プロジェクトを成功させるために気をつけていること ... 責任者編
JavaScript コメント使い分け
-
//
直下の処理を説明する -
/** */
宣言された変数や関数を説明したいとき、JSDocで書きたいときに使う -
/* */
コメントを複数行に跨がせたいときに使う
英語できないマンが翻訳なしで情報を探す技
- 英文の中のコードに注目する
- 英文の中のリンクに注目する
- GitHub Issue の場合、 fixed, solved みたいなコメントの直前のコメントを見てみる
- etc.
タイムゾーンとSSR
- SSR中に日付をフォーマットするとクライアントとは違うタイムゾーン(だいたいはUTC)が表示されることがある
- これはサーバーが動いているマシンのタイムゾーンがクライアントと同一ではないから起こるので気をつけないと普通に発生する
- サービス間での表現や処理の違いを見比べる
react-use vs @react-hookz/web
コードレビューのときに気をつけていること
- 相手が否定しやすい文体でコメントする(〜と思います、〜な気がします)
- ただし、可読性・保守性を低める書き方は明確に指摘する
- 省略可能な記述は省略させる
- 記述が減ることはコードリーディングを簡単にして保守性を上げること
- 不要な型指定を減らす
- 推論があるので不要な型指定を減らせば修正箇所を減らせる
- 推論可能な書き方は読みやすいコードになっていることが多い気がする
コードを書くときに気をつけていること
- 配列操作にはビルトインメソッドを適切に使う
- 配列の個数が変わるか、インターフェースが変わるかが書き出しでわかって脳の負荷が減る
- 型は可能な限り指定する
- ただし、推論される箇所には指定しない
- ライブラリ・フレームワークはスタンダードな使い方を目指す
- 独自性を出さない
- 自作ライブラリを減らす
- 調査不足な状態でライブラリを作る判断をしない
- 自分のエゴをコード・設計に出さない
- 自分はこう書いたほうが読みやすい、この書き方で実装したほうが作りやすいみたいなのはなるべく排除して、一般的な書き方を目指す
- コメントを書く・書かない
- Whyについてをコメントに残すことを意識する
- コメントを書きたくなったら一旦実装を見直してみる
- プロパティ名をなるべく変えない
- そのために分割代入を多用していることろある
HeadlessUI でシンプルにUIコンポーネントを開発する
Next.js の RuntimeConfig を型安全に管理する
このスクラップは2023/11/15にクローズされました