Container Componentに書いていたlogicをCustom Hooksに書いてみる
はじめに みなさんは、Reactを使用して開発する時、Componentで使用するlogicをどこに実装していますか？ 私はComponentをContainer ComponentとPresentational Componentの二つに分けて、Container Componentにlogicを書いてました。 しかし、Custom Hooksを使用することでわざわざComponentを分けなくても良い、ということを最近知りました。 本記事は、それを実践してみよう、というものです。 まず用語を簡単に確認してから、サンプルコードを用いてCustom Hooksを実装していきたいと思います。 Container Componentとは Dan Abramov氏のブログから引用します。 You’ll find your components much easier to reuse and r
React コンポーネントの「制御・非制御」を意識しない方法
React でフォームを作るとき「制御・非制御」コンポーネントに関する知識は必須です。デザインシステムを作成するにあたり、どちらを採用するか検討されたこともあるかと思います。 「制御・非制御」コンポーネントの差分を一言でまとめると、次のとおりです。 制御コンポーネントはライブラリ（React）が「入力要素の状態」を管理 非制御コンポーネントは「入力要素の状態」を DOM 自身が保持 「制御・非制御」コンポーネントと Form ライブラリ React Hook Form は、非制御コンポーネントを使うことで、少ないコード量で高パフォーマンスの Form 実装が実現できる人気のライブラリです。「非制御コンポーネント」として作成された<Checkbox>コンポーネントの例を見てみましょう。次の方法で<input type="checkbox" name="test" />がレンダリングされ、Fo
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
JWT認証の仕組み・脆弱性について軽くまとめ | deecode blog
JWT認証、便利だしDBに状態持たないのでRESTfulだしめちゃ便利です。 今回はトークン生成、検証と脆弱性についてまとめました。 ざっくりまとめてるので網羅してないし説明不足な部分もあります。 JWTトークン生成の仕組み まずはトークン生成から。 フロントエンド側はユーザー・パスワードを送信バックエンド側はユーザー・パスワードが正しいかを検証しユーザー情報取得DBにユーザー情報が保存されてる前提で進めますパスワードはハッシュ化などしてくださいユーザー情報からpayloadを作成ユーザーIDなどが一般的payloadはデコードが容易なのでパスワードなどの機密情報は入れないハッシュ化するアルゴリズムなどの設定値を指定したヘッダーを作成ヘッダー・payloadをBase64エンコードするデコード可能5の値をバックエンド側が保持している秘密鍵でハッシュ化・署名5の値(ヘッダー、payload)
AtomicDesign 境界線のひき方
AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 1.影響範囲が特定しにくい 2.依存関係が特定しにくい 3.汎用性が低くなりがち 4.汎用性の高低が判別できない 多くの場合「粒度」だけを基準にしてしまい、横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 「関心範囲の広さ」区分 アプリケーションを構成するモジュールは「関心範囲の広さ」で区分を行うことが鉄則です。次の２つのhelper.tsを見てください。全く同じ関数が定義されていたとしても、どこで利用される想定のものなのか、すぐに判別できますね。utilsは、プロジェクト内で横断的に再利用される可能性が高い（関心範囲が広い）ものが集約されます。 AtomicDesign
「3種類」で管理するReactのState戦略
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
React+TSプロジェクトで便利だったLint/Format設定紹介
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「linter/formatter」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいて便利だったLint/Format関連の設定についてご紹介していきます。 使っているのは、TSのlintのためにESLint, CSSのlintのためにStylelint, 主なファイルのformatのためにPrettierです。 ESLint pluginsとextendsだけどんなもの入れてるか載せておきます。 "plugins": [ "strict-dependencies", // 後述 "unused-imports", // 後述 ], "extends": [ "a
メルカリShops のフロントエンド | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
スコープとライフタイムで考えるReact State再考
ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム（生存期間）が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、本稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類
Mirai TranslatorのReactリプレイスでMUI(Material-UI)を採用した理由 - Mirai Translate TECH BLOG
Mirai Translatorのフロントエンド刷新プロジェクト テキスト翻訳やファイル翻訳機能を提供する、みらい翻訳のプロダクト「Mirai Translator®」は、2017年にリリースされ、今日まで機能追加・改善が行われてきました。 リリースから数年が経ち、当時の技術スタックで構成されたMirai Translatorのフロントエンドでは、引き続き優れたセキュリティ性や、UI/UXを持つサービスを提供することが困難であると判断し、モダンな技術によるリプレイスプロジェクトが進行中です。 採用した技術スタック 今回リプレイスにあたって採用した代表的な技術を紹介します。 TypeScript: JavaScript With Syntax For Types React – ユーザインターフェース構築のための JavaScript ライブラリ Vite Jest · 🃏 Delight
【検証】React.FC と React.VFC はべつに使わなくていい説
こんにちは、クレイの正岡です。 コロナ禍が始まってから小学生時代以来のゲーム生活を送っています。ゲームボーイと呼んでください。 さて、今回は React × Typescript でコードを書いている人／書こうとしている人に向けて、Reactコンポーネントの型定義について頭の片隅に置いておいて欲しい情報を共有したいと思います。 寝ながら使えてしまうReactコンポーネントの3つの型 () => JSX.Element 型 interface Props { text: string } const Hoge = ({ text }: Props) => { return ( <p>{ text }</p> ) } 上記のように返り値の型を特に指定していない場合、 このコンポーネントは JSX.Element型 を返す関数（ () => JSX.Element ）として返ります。 React
TypeScriptでコードを書く時に意識していること
なんだかんだでTypeScriptを業務でも個人開発でも使うようになって3年くらいが経過しました。 TypeScriptは便利ですよね☕️ 世の中的にも、もはやTypeScript以外でフロントエンドの開発を行うことが珍しいくらいの雰囲気になってきたのではないかという感じがします。 最近というかTypeScriptを書き始めてしばらくした今、書き始めた当初とは意識することが変わってきたように感じています。 そういうわけで、今、どんなことを意識しているのかを自分の整理をこめて記載しておこうと思います。 🔥🔥🔥 型を先に定義する ここがかなり気持ちの上で変わった部分です。 TypeScriptで型を書くということは、つまるところ自分が今から記述するコードの設計図を書くということだという意識が強くなりました。 TypeScriptの型推論は非常に強力で、自分でほとんど型を定義しなくても、多
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
フロントエンドエンジニアが最低限知っておきたい gRPC のこと - Qiita
はじめに 受託開発企業でフロントエンドエンジニアを1年ほどやっているものです。直近2ヶ月間 gRPC を使用する案件にアサインされたのですが、「フロントエンドエンジニア視点からみた gRPC 」 に関する記事が少なく、キャッチアップするのにかなり苦労しました。この記事では「フロントエンドエンジニア」 が gRPC について最低限知っておかないといけない概念や技術などをざっくり解説したいと思います。 この記事の対象者 フロントエンドエンジニアで gRPC 案件に突然アサインされた人 フロントエンドエンジニアで gRPC について知りたい人 フロント側から見た gRPC について知りたい人 この記事で触れないこと メリット / デメリットとか マイクロサービスがどうこうとか REST との比較とか その他の深い内容 おさらい この記事に辿り着く前に色々調べて既にご存知の方もいらっしゃるかと思い
日経の新媒体における、既存資産を活かすフロントエンド技術選定 — HACK The Nikkei
こんにちは、Web チームの井手です。 この度 NIKKEI Professional Media（通称 Promedia） という新媒体をリリースしました。各トピックに特化したメディアで、現在は 日経モビリティ、日経GX、日経テックフォーサイトが展開されています。 これまで日経 Web チームでは特定のFWを利用せず、長年JSXをテンプレートエンジンとした独自FWを開発して、モノレポとして運用していました。これはチューニングの余地を自分で確保することや、自分たちのチームにあった規約を作りやすくするための選択です。しかし Promedia の開発は電子版本体のリリースサイクルと外れるためにモノレポの中に入れたくないことや、長年の開発の負債を引き継ぎたくないこと、なによりNextJSエコシステムの発達によって僕たちの要求をカバーできつつあることから、試験的にNextJSを採用して開発してみま
データベースの文字数制限が191文字になっている理由とは？
世の中のデータベースを見ていると、格納するデータの文字数に「191文字以内」という制限が課されている場合があります。一体なぜ191文字という中途半端な数字で制限が行われるのかについて、オープンソースのデータ同期ツールを展開するGrouparooのCTOを務めるエヴァン・ターラーさんが解説しています。 Grouparoo Blog: Why do database columns have a character length of 191? https://www.grouparoo.com/blog/varchar-191 ターラーさんはまず、現代のデータベースシステムでは無制限に文字を格納する設定も可能だとした上で、文字数の制限で検索速度が向上すると説明しています。例えば、メールアドレスの行が「[email protected]」となっているユーザーを見つけたい場合、なんの工夫も無い状
React TypeScript Cheatsheets | React TypeScript Cheatsheets
React TypeScript CheatsheetsCheatsheets for experienced React developers getting started with TypeScript
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SPAセキュリティ入門～PHP Conference Japan 2021 | ドクセル
System of Record と System of Engagement
Remove React.FC from Typescript template by Retsam · Pull Request #8177 · facebook/create-react-app
