モチベーション golangci-lintを利用されている方も多いと思います。 後述のようなコードを書くと指摘してくれるgo-err113というルールがなぜあるのかということをきっかけに書いた記事になります。 func F() error { err := something() if err != nil { return errors.New("failed call something fn") } } ネタバラシすると、go-err113のREADMEにルールがある理由は親切に書かれているのですが、Goを始めたばかりの私にはすべての疑問は解消することができず、より深く調べました。 Starting from Go 1.13 the standard error type behaviour was changed: one error could be derived from a

はじめに 最近携わっているプロジェクトでCustom Hooksを試行錯誤し活用していくなか、私の中でこんなモチベーションで使うと概ね間違いがないのでは？ という軸が見えてきたので、いくつかの実装例を添えて今後の自分のために整理し記事にしました。 前提 Custom Hooksは仕様がとても柔軟かつ自由なため個々で解釈が異なると考えています。 私の中でコアとして持っている考え方を一つだけ定義させていただきます。 それは原則Presentationalな部分をCustom Hooksに持ち込まないです。 こういった考えの人間が書いているんだな程度で読んでいただけると助かります。 結論 私の中では主に次の2つの動機によってCustom Hooksを作成しています。 特定のコンポーネントを意識しない抽象度の高い一連の処理をまとめたい 特定のライブラリへの依存などをコアドメイン[1]から隠蔽したい

動機 業務でstyled-componentsを触る機会がありました。 styled-componentsは自分の周りではあまり良い噂を聞いていなかったため、少し調べたところこんな記事がHitしました。 記事の内容としては 様々な基礎概念を隠蔽しすぎている 使うことのメリットデメリットや、隠蔽されている部分の理解をしたチームでないと使わないほうが良い という内容です。 なので、しっかりと順を追って復習しました。 環境 viteで作成したReact18のTypeScriptプロジェクトで実施。 Reactの利用は関数型コンポーネントを前提としています。 Refを軽くおさらい 公式Docを見ていただくのが一番正確です。 公式では 一般的な React のデータフローでは、props が、親コンポーネントがその子要素とやりとりする唯一の方法です。子要素を変更するには、新しい props でそれを