タグ

ブックマーク / blog.ojisan.io (7)

  • custom hookの返り値は配列であるべきか

  • 脱Reduxを試みて失敗した話、その原因と対策について

    さて、年末が近づいてきましたが今年も 「Redux 使うべき使わないべきか」という話で盛り上がりましたね。 僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。 自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。 自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです

    脱Reduxを試みて失敗した話、その原因と対策について
  • Firebaseの存在をフロントエンドから隠蔽するために

    「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして (特性やスキルセット的に)RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase

    Firebaseの存在をフロントエンドから隠蔽するために
  • ESLint と Prettier の共存設定とその根拠について

    注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので

    ESLint と Prettier の共存設定とその根拠について
  • Reactのパフォーマンスチューニングの歴史をまとめてみた

    最近 React のパフォーマンスチューニング、特に再レンダリング抑制について調べたのでそのまとめです。 特に昔からおまじないとして書いていたことを、「なんであの書き方していたんだっけ」というのを調べてまとめました。 古いものを調べたのは、今あるチューニング方法とその当時の解決方法を比較したかったからです。 再レンダリングとはなにか 公式に説明があったのでそのまま引用します。(https://ja.reactjs.org/docs/optimizing-performance.html#avoid-reconciliation) React では、コンポーネントの props や state が変更された場合、React は新しく返された要素と以前にレンダーされたものとを比較することで、実際の DOM の更新が必要かを判断します。それらが等しくない場合、React は DOM を更新します

    Reactのパフォーマンスチューニングの歴史をまとめてみた
  • JavaScriptライブラリを読むときのコツ

    少し前からライブラリを読むトレーニングを始めたのですが、最近ようやく読み方がわかってきたので、やり始めた頃に知っておきたかったことをまとめます。 これから JavaScript/TypeScript で書かれたライブラリを読んでみようと思っている方の助けになれば嬉しいです。 「私はこういう道具を使ったり、こういう工夫をしています」みたいな感じの内容ですので、もし「もっといい読み方があるよ」みたいなのがありましたらIssueなどで教えていただきたいです。 (※ライブラリを読むにあたって、ブラウザの話と NodeJS の話があるのですが、似てる点がほとんどなのでごった煮します。) エントリポイントを探す ライブラリを読むにあたって そのライブラリが持つ module がどう協調して全体が作られるのか その関数は正確にはどういう挙動をするのか などを考えると、ユーザーから渡された入力や呼び出しが

    JavaScriptライブラリを読むときのコツ
  • Reactのコンポーネント周りの用語を整理する

    React のコンポーネント周りの用語ってごっちゃごちゃになった経験はありませんか? 友人と話すときなどはなんとなくのニュアンスで伝わるので気にしていなかったのですが、型注釈つけるときやコードリーディングするときに言葉の定義がわからなくなって何回も調べるといったことをよくやるのでこれを機に整理しようと思います。 記事では JSX 以外にも createElement 記法の知識も要するので、自信がない方は公式やどうして JSX を使ってもエラーにならないのか?をご覧ください。 ここでは React のドキュメント JSX Elements Components TypeScript の型定義 JSX.Element ReactElement DetailedReactHTMLElement DOMElement FunctionComponent Component ReactNode

    Reactのコンポーネント周りの用語を整理する
  • 1