Zenn の記事に清書しました：ReactNode型のpropを正しく扱う 〜もう謎の「0」や空要素を見せないために〜 背景 React コンポーネントを作っていると、しばしばオプショナル （任意）な ReactNode 型を受け取る prop を書くことがある 例1：Button に iconを渡したときだけスペースをちょっと開けてアイコンを表示し、渡さなかったら非表示にする <Button icon={<PlusIcon />}>Add</Button> → <button><span style={{marginRight: "0.5rem"}}><PlusIcon /></span>Add</button> <Button>Add</Button> → <button>Add</button> 例2：Checkbox に children を渡したときだけ全体を label でラッ

Zodとの比較 公式サイトで、Valibot は、Zod と比較して、バンドルサイズが最大98%削減できると記述されています。今回作成した問い合わせフォームでも、92.2%の削減を確認できました。 VSCode 上で Zod で作成した Schema ファイルのサイズは gzipped 圧縮で12.8kです（Zod を利用した Schema はこちらを参照ください）。 ZodのSchema実装 import { z } from "zod"; const email: z.ZodString = z .string({ required_error: "入力が必須の項目です" }) .min(1, { message: "入力が必須の項目です" }) .max(255, { message: "255文字以内で入力してください" }) .email({ message: "メールアドレスの

VTeacher所属のSatokoです。 QAエンジニアとフロントエンドエンジニアを兼任しています。 2006年、まだホリエモン率いるライブドア(現LINE)のモバイルチーム(現LINE出澤社長がリーダー)に配属も、同年1月にライブドアショックがあって出社0日で失職。その後、サイバーエージェントやGREEなどを転々としてきたITバブルの残党(ナイスミドル系エンジニア)です😅 1.久しぶりにReactのプロジェクトに参加 リズミカルにキーボードを　タタンッ！　として、

はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう？」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました！ 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー！ なぜこんな疑問を抱いたのか？ まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう！」 →

はじめに Reduxは遠い昔に誕生したものなので、いまReduxを使っていない人も多いかもしれません。 Reduxは、出現当時はそれほど大きなソフトウェアではなかったのですが、ときが経つにつれて、いろいろな便利関数たちが現れてきて、そのせいで今からReduxを調べる人は、何が本質なのかを調べるのが難しくなっていると思います。 そこで3分でReduxもどきを実装しました。こちらです。20行！！ じゃーん！ JavaScriptでうごきます！！ // 実装 const createStore = (reducer) => { let state = 0; const listeners = []; const dispatch = (action) => { const newState = reducer(state, action); state = newState; listeners

自分ではあまり使ったことがないのですが、最近他所のデザインシステムの実装なんかを眺めていて <Stack.Item> のようにあるコンポーネントのプロパティとして他のコンポーネントを定義するパターンを何度か見かけて、どんな時に有効なのかを考えてみたくなった次第です。 具体例 Shopify のデザインシステムの中にある Stack と Stack.Item が当てはまります。 これらのコンポーネントは次のようにセットで使われます。 <Stack> <Stack.Item fill> <Heading>Order #1136</Heading> </Stack.Item> <Stack.Item> <Badge>Paid</Badge> </Stack.Item> <Stack.Item> <Badge>Fulfilled</Badge> </Stack.Item> </Stack> //

#React やってて、props のバケツリレーを何か嫌がる人たまにいるんだけど、自分は props のバケツリレーそのものをそんなに悪いと思ったことがない。 「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている。 たとえば、次のようなバケツリレーはつらいかもしれない。ここでいう Body はサイドバーとしてフォロワーの一覧を表示し、メインコンテンツとしてフィード一覧を表示するみたいなものを想像して欲しい。フォロワー一覧の中で使う props とフィード一覧で使う props を混ぜて1つの親に渡している状況だ。

弁護士ドットコムライブラリーのフロントエンドのアーキテクチャを紹介します この記事は弁護士ドットコム Advent Calendar 2020、2日目の記事です。2020年12月に執筆された記事です。 私は弁護士ドットコムライブラリーというサービスを開発しています。これは法律書籍をネットで読める弁護士向けのサブスクリプションサービスです。 フロントエンドの採用技術はNext.js + TypeScriptで、要件定義から設計、実装は私が担当し、現在も運用しています。 この記事では、2020年5月にリリースしてから半年間、Next.jsで上記サービスを運用した知見の中から、フロントエンドでのアーキテクチャについてご紹介します。 弁護士ドットコムライブラリーの特徴は以下の通りです。 画面数は10画面ほどの中規模アプリケーション（OOUIの考え方を取り入れたら画面数が減りました） 基本的にバック

【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/

import React from "react"; import { useForm } from "react-hook-form"; const Example = () => { const { handleSubmit, register, formState: { errors } } = useForm(); const onSubmit = values => console.log(values); return ( <form onSubmit={handleSubmit(onSubmit)}> <input type="email" {...register("email", { required: "Required", pattern: { value: /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$/i, message: "i

Reactでのシングルページアプリケーションを作成していると、必ず意識しなくてはいけないのが状態管理です。Hooks APIの登場により、アプリケーションの状態管理方法にも選択肢が増えてきました。2023年のReactアプリケーションの状態管理方法はどのような選択肢が考えられるでしょうか？ 状態管理の選択肢 Reactの状態管理として本記事でには紹介している手法は下記の4通りになります。 ローカルステート（useState、useReducer）での管理 Hooks APIのuseReducer、useContextを使った管理 Reduxによる管理 Recoilによる管理 状態管理フレームワークは他にも選択肢がありますが、Reduxを紹介します。理由は、候補として挙がるライブラリの中でもっともシェア数が多く、知名度が高いためです。 下図は、主要なReact状態管理フレームワークのダウンロ

先日JavaScriptに慣れていない人のコードをレビューする機会があり、constで宣言されたオブジェクト内部に副作用を与えている記述がありました。 その時に「今の動作に問題ないけど、今風のJSならイミュータブルの方が良いかも」と指摘したものの、JSに疎い人からすれば背景が分からないはずで、理由を自分なりに説明したものの案外言語化が難しかったことがありました。 難しい理由として、イミュータブルであることは実利面と同時に、Facebook発祥のトレンドという側面も多分に含んでおり、JavaScript自体の潮流も踏まえておく必要があるからです。 今回は実利面に加えてトレンド面も交えて、なぜイミュータブル性がJavaScriptで重宝されるのかを見ていきましょう。 フロントエンドの世界では状態を持ち、時間やインタラクションと共に変化するから サーバーサイドの世界から見た場合、HTTPはステー

この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと（技術的負債の抑制）ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論（ここでは「現代的な設計論」とよぶもの）です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む（ビジネスロジックの変更や追加に対

Container Componentが提唱されてから随分と長い時間が経ちました。 Redux Hooks APIもリリースされ設計を見直すよいタイミングなので、初心に立ち返って、Container Componentが必要なタイミングを考えてみました。