Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
承認ではなくて、よさそう、と思って暮らしている - hitode909の日記
普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ
wikiでページのURLをIDにすると絶対にうまくいかない - 橋本商会
なのだが、WiKiページのURLがIDになっていて、IDで外部からリンクされていると脱線ができなくなってしまう
非対称な状態間の同期の実装メモ - Object.create(null)
状態間の同期は一般的な話題ではあるのですが, 例として React の制御コンポーネントの実装を題材にします. ここで非対称な状態とは, 各状態のとり得る値の集合の間に一対一の対応がないことを指しています. というか一対一に対応するのであればふつうは状態を分けなくてよろしい. まずはおさらいとして, 基本的な制御コンポーネントを見てみましょう (sandbox). const MyTextInput: React.VFC<{ text: string; onChange: (text: string) => void; }> = ({ text, onChange }) => ( <input type="text" value={text} onChange={(e) => { onChange(e.target.value); }} /> ); この場合はユーザーが入力するデータと,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
