React Hook Form でも再描画に気を付ける
React Hook Form を使うと、useStateを使う制御フォームにありがちな「頻繁な再描画」を手短かに防ぐことができます。しかし、使い方によっては、その利点を崩してしまうことがあります。それが、useFormの戻り値に含まれるwatchの使用です。 watch は頻繁な再描画の原因になる 次のコンポーネントは、よくあるサインアップフォームです。emailに入力された文字数をカウントし、インタラクティブに「何文字入力されているか」を表示します。watchは、このような値の購読に利用できる API です。しかしコメントにあるとおり、emailに文字が入力されるたび、このフォーム全体が再描画されてしまします。これは、多くの要素を含むコンポーネントで避けたい実装例です。 const defaultValues: Form = { email: "", password: "", };
React のカスタムフックで作る debounce 機能
始め 最近案件で debounce 機能を実装する機会がありました。色々調べてたら、カスタムフックで実装できる方法があったので紹介したいと思います。 まだカスタムフックに馴染んでない方は「React 初心者の難問、カスタムフック（Custom Hook）を解説します」を是非お読みください。 1. debounceとは 私が実装してたのは検索欄に文字を打つたびにサジェストを表示する機能でした。普通は検索するとき単語をぱぱっと連続で入力しますので、インプットが発生するたびに API コールするよりは入力が終わった後に API コールしたほうが効率的です。ここで欲しくなるのが debounce です。 debounceとは連続で実装された関数たちの中で一番最後の関数だけ(もしくは一番最初の関数だけ)実装させることです。 簡単なデモを準備しました。インプット欄になにか入力してみてください。 原理は
ReactHookForm setErrorでsubmitを止めたい
環境 React Hook Form v17 useForm の setError エラーを手動で設定できる。 setError('registerInput', { type: 'custom', message: 'custom message' }) 何がしたかったのか emailの入力値がすでにDBに登録されている場合に、他のバリデーションと同様にエラー表示し、submitさせないようにしたい。 入力フォーム(input要素)にonBlurを設定 入力値をwatchで取得して存在確認用のAPIを呼ぶ APIの結果によってエラーを設定する(ここでsetErrorを用いる) 躓いた点 setErrorを設定するだけではsubmitが走ってしまう。 似たようなことで困っているgithubのissue。 そもそもバリデーションを設定するものではない。本来の使いどころは以下のような場合の時。
Recoil
Minimal and ReactishRecoil works and thinks like React. Add some to your app and get fast and flexible shared state. Data-Flow GraphDerived data and asynchronous queries are tamed with pure functions and efficient subscriptions. Cross-App ObservationImplement persistence, routing, time-travel debugging, or undo by observing all state changes across your app, without impairing code-splitting.
Reactのベストプラクティスとコード削減パターン - パート3
本記事は React best practices and patterns to reduce code - Part3 を提供元の事前許可を得たうえで翻訳したものです。 元の記事に従いタイトルに「ベストプラクティス」と含んでいますが、実際にはベストプラクティスは規模や状況によって大きく異なります。 チームの状況にあわせて参考にしていただければと思います。 ===== これは全3パート中の最後である第3パートとなる記事です。前2つの記事を読んでいなければ是非以下のリンクからお読みください。 パート1パート2パート3（この記事） それではいきましょう。 トークンはlocalStorageよりもCookieに保存するよくないコード： const token = localStorage.getItem("token"); if (token) { axios.defaults.headers
Reactのkey propに配列のindexを使うことが良くない理由
始め Reactのmapを使う時、keyエラーをなくすためindexを使ったことがあります。しかし最近それがanti-patternだということを知りましたので、その理由をまとめました。 1. keyの存在意義 1-1. keyってなんだっけ そういえばそもそもkeyって何で必要だったけ…？と、ふいと思ってしまいました。何となくは知ってますが、明確にしたいのでこの部分から始めましょう。 まずはこのサンプルコードをご覧ください。 export default function App() { let fruits = [{ name: "apple" }, { name: "banana" }, { name: "pear" }]; return ( <div className="App"> {fruits.map((fruit) => ( <p>{fruit.name}</p> ))}
React Hook Formの基本を理解してフォームを作成してみよう | アールエフェクト
React Hook FormはReat用のフォームバリデーションライブラリです。input要素に入力した値を取得するだけではなくバリデーション機能なども備えており簡単にフォームを実装することができます。入力フォームの作成が嫌いな人もライブラリの力を借りることでフォーム作成の手間を軽減することができます。バリデーションについてはReact Hook Form自身も機能を備えていますがバリデーションライブラリのZod, Yupを利用することも可能でそれらのライブラリを利用した場合の設定方法についても説明しています。 本文書ではすぐに実践で活用できるようにバリデーションやエラーメッセージの表示などフォームを作成する上で必要な機能を中心にシンプルなコードを利用して説明しています。 利用する React Hook Form ライブラリのバージョンは 7 です。React のバージョンは 18.2.
React Hook Formを1年以上運用してきたちょっと良く使うためのTips in ログラス（と現状の課題）
はじめに 早いものでこちらの記事が公開して約1年、ログラスでReactを書き始めて1年以上が経ちました。 今回はフロントエンドのアプリの中でも特段重要なフォーム、特にReact Hook Formについての解説をしていきます。 今回のTipsは公式がベストプラクティスとして発表しているものではなく、あくまで個人が1年間の経験の上で良いとしているものであしからず。 なるべく何故良いかの説明もしていきます。 目次 useFormをラップしてタイプセーフにする React Hook Formへの依存するコンポーネントを分ける yupを使って見通しの良いバリデーションを実装する 1. useFormをラップしてタイプセーフにする ログラスでは useForm をそのまま使うことはせずラップしています。理由は一部の型づけがゆるく実行時例外が起きる可能性があるためです。 問題なのは defaultVa
React Hook Formハマりどころとベストプラクティス
初めに React Hook Form（以後、RHF）はとても便利なバリデーションライブラリですが、非制御コンポーネント前提なのでRHFのAPIを通して全ての操作を行うことになります。 そのうえで、自分なりにつまづいたところやわかりづらかったところをまとめました。 個人的に結構このライブラリを扱うのに苦労しているので、皆さんもコメントで自分なりのハマりどころを書いたり、新しく記事にしたりしてネット上に知見が溜まればなと思っています。 ハマりどころ useFormのdefaultValuesは動的に変更しない これしっかりドキュメントに書いてあるんですが、defaultValuesを変更したい場合はresetAPIを使いましょう。 悪い例 このようにAPIからデータが返ってくるまで適当な初期値を渡しちゃうような設計だと、APIからデータが返ってきてもフォームの値が変わらないということがありま
React Hook Form: A guide with examples - LogRocket Blog
Vijit Ail Software Engineer at toothsi. I work with React and NodeJS to build customer-centric products. Reach out to me on LinkedIn or Instagram. Editor’s note: This article was last updated by Jude Miracle on 23 July 2024 to cover how to use the useFormContext Hook in React Hook Form, handle complex data structures like nested fields and arrays within forms, and update code blocks where necessar
React Hook Formの勉強
ネストされたフォーム ここを見ても、いまいち理解できなかった。 こっちの方がわかりやすい。 結局の所、 親コンポーネントで useForm しておく。 親コンポーネントでは、 FormProvider で囲んでおき、 useForm の戻り値を渡しておく。 子コンポーネントの方では、 useFormContext を使うことで、親が管理している useForm にアクセスできる。（ register を呼び出したりできる） つまりは、親で管理している useForm の結果を、子コンポーネントでかんたんに使える、ということと理解した。 ちなみに、 FormProvider で囲まれていない子コンポーネントで useFormContext を実行しても、 null が返却される。
react-hook-form と zod でバリデーションのその先へ
どうも、 uzimaru です。 最近、react-hook-form と zod を使っていい感じにやっているのでそれについてまとめようと思います。 react-hook-form で zod を使う 公式から利用する方法が提供されています。 https://www.npmjs.com/package/@hookform/resolvers これを useForm の resolver で利用することで zod が使えるようになります。 zod 以外にも Yup, Superstruct, Joi, io-ts などが利用できます import { useForm } from "react-hook-form"; import { zodResolver } from "@hookform/resolvers/zod"; import * as z from "zod"; const
React Hooksを最大限利用したFormの実装🔥
2021.10.01追記 記事執筆時点からこの記事の実装についての筆者のスタンスが変わってきたので補足します。伝えたいのは以下です。 プロダクトでフォーム実装を考える際は、React Hook FormやReact Final Formの導入も検討ください。この記事はReactとTSの実装を理解するのには役立ちますが、プロダクト実装に耐えうるかはわからないです。 以下、お気持ちです。 執筆当時、筆者はReactでのフォームの実装は公式にあるようなコントローラブルな本記事の実装一択だ、これが一番拡張性があり、可読性も高い実装だと思っていました(正直視野狭かったですね…) 実際にプロダクトで運用してみると、入力内容の監視を行うとパフォーマンスがめちゃくちゃ悪くなったり、項目を追加させるようなフォームでは秘伝のタレみたいな実装をせざるおえなかったり、結局先に挙げたようなデファクトスタンダードなラ
【備忘録】React Hook Form(v7)を使って、ネストされたフォームを実装する
記事の概要 react-hook-form を使ってネストされたフォームを実装する際に使用する useFieldArray に関して、実装時に少し詰まったのと、公式が用意していた example が TS で書かれていなかったので、備忘録としてこちらに残します。 公式が出している example に関してはこちらから参照していただければと思います。 前提として、記事内部で使用する使用ライブラリのバージョンは以下の通りです。 React v17.0.2 React Hook Form v7.15.4 TypeScript v4.1.2 React Hook From について React Hook Form は hooks ベースのフォームライブラリです。 フォームの値を取得・変更したり、バリデーションの設定などを行うことができます。 また、React 側で状態を管理しない非制御コンポーネン
ref のフォワーディング – React
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 以下の新しいドキュメントで最新の React の使い方がライブサンプル付きで学べます。 ref で DOM を操作する forwardRef ref のフォワーディングはあるコンポーネントを通じてその子コンポーネントのひとつに ref を自動的に渡すテクニックです。これは基本的にはアプリケーション内のほとんどのコンポーネントで必要ありません。しかし、コンポーネントの種類によっては、特に再利用可能なコンポーネントライブラリにおいては、便利なものとなるかもしれません。一般的なシナリオについて以下で述べます。 DOM コンポーネントに ref をフォワーディングする ネイティブの button DOM 要素をレンダーする FancyButton というコンポー
結局 React のコンポーネントにはどうやって型をつければ良いのさ - kk-web
React TypeScript Cheatsheet の Useful Patterns by Use Case の Wrapping/Mirroring に答えが書かれていました。 自分は function でなく const で作成することが多い(どっちが良いんですかね？)ので、以下のように書くのが良さそうです。 import React, { ComponentPropsWithoutRef, FC } from "react"; export type ButtonProps = ComponentPropsWithoutRef<"button"> & { specialProp?: string; }; const Button: FC<ButtonProps> = ({ specialProp, ...props }: ButtonProps) => { console.lo
CSSレスポンシブデザインをSPAで使うと破滅する - 橋本商会
レスポンシブデザインは あくまで見た目の調整、表示・非表示のコントロールなので 下手に使うと、デバイス毎にインタラクションが違うUIのstateが無茶苦茶複雑になっていく コンポーネントという概念が無かった時代の設計を、SPAに持ってくるのはおかしい 画面サイズ毎にCSSで手軽にを切り替える、というのなら良い しかし、画面サイズ毎にインタラクションが違う部品が出てくると設計が破綻する 画面サイズ毎のがごちゃ混ぜになる コードが追えなくなり、バグの温床になる では、どうするか？ 素直に画面サイズ毎、デバイス毎、あるいはインタラクション毎のReactコンポーネントを書けばいい 使いまわせる部品は、コンポーネントとして切り出して再利用する 歴史を紐解く 2011年頃、レスポンシブデザインが生まれた 当時のwebにはコンポーネントが存在しなかった 単体で複雑な状態遷移をするインタラクティブなパーツ
Rails5.2+Webpacker3+React+TypeScript
centos7に ruby, node, yarnが入ってる環境に対して やったこと覚書 ①土台となるRails5.2をDB＝MySQL、Front=React、turbolinks、coffeescript、sprocketsは除外して作成 $ mkdir myapp $ cd myapp $ bundle init Gemfileを編集してrailsを入れるようにする $ vi Gemfile # frozen_string_literal: true source "https://rubygems.org" git_source(:github) {|repo_name| "https://github.com/#{repo_name}" } - # gem "rails" + gem "rails" $ bundle install --path=vendor/bundle $
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
usehooks-ts
react-hook-formでregisterとControllerのどちらを使うか - mrsekut-p
