新たなWebブラウザ「Verso」など: Cybozu Frontend Weekly (2024-08-20号)
こんにちは！サイボウズ株式会社フロントエンドエンジニアのdaiki（@k1tikurisu）です。 はじめに サイボウズ社内では毎週火曜日にFrontend Weeklyと題し「一週間の間にあったフロントエンドニュースを共有する会」を開催しています。 今回は、2024/08/20のFrontend Weeklyで取り上げた記事や話題を紹介します。 取り上げた記事・話題 feat(next): next.config.ts by devjiwonchoi · Pull Request #63051 · vercel/next.js Next.jsの設定ファイルをTypeScriptで書けるようになりました。next.config.tsに設定ファイルを記述することができます。 Using pnpm on Heroku HerokuのNode.js buildpackが、パッケージマネージャの1
useEffectの中でsetStateを使うときはアンチパターンを疑おう
結論 useEffectの中でsetStateを使いたくなったときは、まずは他の方法がないかを確認しよう！ 概要 React で開発を行う際、（useState の）setStateと、useEffectはほぼ必ず使います。 しかし、これらを適切に組み合わせないと、コードの複雑さが増し、予期しないバグが発生する可能性があります。 特に、useEffectの中でsetStateを使用することはアンチパターンに繋がる目印になりやすいです。今回の記事では、コード例を紹介しながら図や動画を交えて解説していきます。 useEffectの中でsetStateを使うアンチパターン 1.無限ループの発生 useEffectの依存配列にsetStateで管理する状態を指定すると、その状態が更新されるたびにuseEffectが再度実行され、再度setStateが更新されるという無限ループに陥る可能性があります
ノーコードプロダクトのReact化の工夫
はじめに こんにちは！サイボウズ株式会社でkintone開発を行っている かげ です。 弊社が開発しているkintoneは、プログラミングの知識がなくても、ノーコードで業務のシステム化や効率化を実現するアプリがつくれるクラウドサービスです。 kintoneは初回リリースから10年以上経ちましたが、そのフロントエンドに使用されるClosure Libraryが今月(2024/08)EOLを迎えます。EOLを迎えたフレームワークを使用し続けることは、リスクにもつながりますし、今後より良くに、お客様への安定的なサービスの提供を維持するため、Reactへの刷新活動を行っています。 現在開発段階ではありますが、そこで工夫した点をご紹介したいと思います。この記事では、kintoneをご利用されるお客様がよく使用されるレコード一覧、レコード詳細画面を取り上げていきます。他にも画面はありますが、今回はご紹
【React】リッチテキストエディタ（Quill、Tiptap、Slate...）の考え方や前提知識
概要 4年ほどProductionで使っていたリッチテキストエディタ（Quill on Nuxt.js v2）をTiptap on Next.jsに移行しました。 既存のQuillエディタの使い勝手をTiptapで再現しつつ、改善できるところは改善しつつ、既存の4年分のリッチテキストデータが正しく編集できるようにしなければいけませんでした。 本記事では移行の具体的なプロセスを解説しようと思っていたのですが、リッチテキストエディタは前提知識があまりに多いため、前提となる知識や考え方を解説しているだけでそこそこのボリュームになりました。そこで、一旦考え方や前提知識をまとめた、という体で公開します。 本記事を読んでから各ライブラリのDocsを読んだりカスタマイズを始めたら、少しハードルが下がっていることかと思います。 対象読者の例 リッチテキストエディタに興味がある リッチテキストエディタの開発
王道か邪道か？ タイムスタンプによるステート管理
Reactによるステート管理では、ある状態が変化したら付随して他の状態も変化してほしい場合があります。例えば、次のような場合を考えます。 チェックボックスが1つある。 チェックボックスの初期状態は、HTTP APIから取得したデータによって決まる。 ユーザーはチェックボックスを操作できる。 APIからデータを再取得する場合があり、その場合はチェックボックスの状態が再取得されたデータに従ってリセットされる。 皆さんは、このような要件をどのように実装するでしょうか。 やりがちな実装 まず、やりがちな実装を見てみましょう。 const apiData = useApiData(); const [isChecked, setIsChecked] = useState(false); useEffect(() => { setIsChecked(apiData.isChecked); }, [ap
過激派が教える！ useEffectの正しい使い方
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
そのuseRef+useEffect、refコールバックのほうが良いかも？ - Qiita
Reactにおいて、useEffectのユースケースとして知られているのが、DOMノードに直接アクセスしなければいけない場合です。useRefでDOMノードをrefオブジェクトに取得し、エフェクト内からDOMノードにアクセスするというのがその場合の基本的なやり方です。 このようなuseRef + useEffect の使い方は、問題ない場合もありますが、実は別の手段を使った方がいい場合もあります。その場合に別の手段として適しているのがrefコールバックという機能です。 そこで、この記事ではどのような場合にuseRef + useEffectよりもrefコールバックが適しているのか、そしてrefコールバックを使う場合の注意点について解説します。 復習: refコールバックとは React DOMでは、組み込み要素（divなどHTMLの要素）に対してrefという特殊なpropを与えることができ
React Internals Explorer | Deeper Dive Into React
This snippet is authored by others. Fork first to edit.
React 19の新機能まるわかり
2024年4月にリリースされたReact 19 Betaの新機能について、細かい点やポイントを解説します。
React でゼロからフローチャートUIを実装する
最近、AIのワークフローを簡単に組める OSS「Dify」が注目を集めています。 Difyではブラウザ上でフローチャートを構築してLLMのワークフローを設計できます。 今回はこのUIの実装を理解するためにReactでフローチャートUIを実装してみようと思います。DifyではフローチャートUIの構築に「React Flow」を使用しています。React Flow は React で使えるフローチャートUIライブラリです。本記事の実装でも React Flow を参考にしてきます。 本記事はフローチャートUIの仕組みを理解することを目的にしています。 フローチャートUIの要素 フローチャートは主に、ノードとエッジから構成されます。ノード同士はエッジで繋ぐことができます。 この記事ではエッジ接続部分をコネクターと呼びます。 つくるもの シンプルなフローチャートUIを実装します。 今回作るフローチ
拡張性に優れた React Aria のコンポーネント設計
React Aria Components は Adobe によって提供されている Headless UI コンポーネントライブラリです。振る舞いや国際化に, アクセシビリティに関する機能を備えており、Button や Input, TextField, Label などのシンプルな要素から、DatePicker や ComboBox などの様々なコンポーネントが提供されています。 今回は React Aria Components の設計について紹介します。 React Aria Components のコンポーネントの設計 React Aria Components の API はコンポジションを中心に設計されています。これにより、パターン間で共通のコンポーネントを共有することも、個別に使用することも可能です。なお、コンポジションについては React Component Compos
そのエフェクトは不要かも – React
エフェクトは React のパラダイムからの避難ハッチです。React の外に「踏み出して」、非 React ウィジェット、ネットワーク、またはブラウザ DOM などの外部システムと同期させることができるものです。外部システムが関与していない場合（例えば、props や state の変更に合わせてコンポーネントの state を更新したい場合）、エフェクトは必要ありません。不要なエフェクトを削除することで、コードが読みやすくなり、実行速度が向上し、エラーが発生しにくくなります。 このページで学ぶこと コンポーネントから不要なエフェクトを削除する理由と方法 エフェクトを使わずに高価な計算をキャッシュする方法 エフェクトを使わずにコンポーネントの state をリセットおよび調整する方法 イベントハンドラ間でロジックを共有する方法 イベントハンドラに移動すべきロジック 親コンポーネントに変更
一休レストランの XState 導入記 - 一休.com Developers Blog
このエントリーは 一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。 レストランプロダクトUI開発チームの鍛治です。 一休レストランのフロントエンドを担当しています。 一休レストランでは Next.js App Router Remix を採用しています。 user-first.ikyu.co.jp 昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。 例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一
「React Journey」から学ぶ React のレンダリングの仕組み
はじめに 「React Journey」 と呼ばれる React においてコンポーネントがブラウザに表示されるまでどのようなプロセスを踏むのか？を示した図 が非常にわかりやすかったので、説明を加えながらみなさんに紹介したいと思います。 レンダリングの流れについて理解が曖昧な人は、ぜひ最後までご覧ください。 対象読者 ある程度 React を触っているが、もっとレンダリングについて理解したい人 公式ドキュメントの「レンダーとコミット」や「state はスナップショットである」などを読んだことがない人 React における「レンダリング」について 本題に入る前に、React を学習していると混乱しやすい「レンダリング」と呼ばれる概念をまず整理しておきましょう。 以下の記事にも書いてありますが、「レンダリング」という言葉はしばしば次の２種類の意味で使用されます。 ブラウザへ画面を表示させること
フロントエンドのディレクトリ設計思想
はじめに フロントエンドのディレクトリ構成、世の中に色んな「推し」が有って悩みますよね。 例えば、、、 さらに最近は、App Directoryの登場や、それに合わせたNext.js公式の「推し」構成がドキュメント化されたりと、さらに色々なパターンが出てきています。 本記事の趣旨 本記事では、具体的な構成そのものではなく、 様々ある構成を横串で見通して整理できる設計思想を紹介します。 新しい推し構成の紹介ではなく、構成を考えたり決めたりするときに役立つ抽象的・汎用的な指針を提供できればと考えています。 基本となる考え 分割の方向 一般的に、アーキテクチャにおける分割には2つの方向が有ります。 (出典も良書なのでリンクを貼っておきます： https://www.amazon.co.jp/dp/4873119820) これはディレクトリにおいても同じだと思っていて、筆者は分かりやすさのために
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 はじめに 10 月 26 日に Next.js Conf が開催されましたが、それと前後して Kent C. Dodds (以下 kentcdodds と呼びます) と Lee Robinson (以下 leerob と呼びます) がそれぞれ という記事を公開しました。前者はタイトルの通り、Testing Library の作者であり、Remix の共同創業者の一人でもある開発者兼教育者 kentcdodds が、Next.js を使わない理由について述べたものです。そして後者は、Vercel の VP of Developer Experience である leerob が、主に前者に対する反論を述べたものです。筆者は両方の記事を公開後すぐに面白く読み、そしてどちらにも頷けるところ
ブラウザバックで壊れないstate管理を実現する`location-state`
この記事は最近リリースしたlocation-stateというライブラリの紹介記事です。 モチベーション Reactのstate管理は、様々な分類が可能です。筆者が過去に書いた記事「スコープとライフタイムで考えるReact State再考」では、stateの分類は大きく以下2つの観点で分類ができると述べました。 スコープによる分類 ライフタイム（=stateの生存期間）による分類 詳しく知りたい方はこの記事を読んでいただきたいのですが、今でもstate管理というと多くの場合スコープによる分類の話が多く、ライフタイムによる分類の話はあまり聞かない気がします。 なぜライフタイム観点が重要か ライフタイムを意識せずに実装した場合に発生するのが、遷移時に状態が破棄され復元されない、つまりブラウザバックでstateが壊れるという問題です。この問題については以下の記事で、Vercelの社長が2014年に
Reactで再レンダリングを抑えるシンプルな方法
はじめに 「React で再レンダリングを抑えたい...」となった場合、多くの人が React.memo や useMemo、useCallback などのいわゆる 「メモ化」 を思い浮かべることでしょう。 しかし、そういった「メモ化」を用いなくても再レンダリングを抑える方法が実は存在しています。 今回はその代表的な例を２つ紹介していきたいと思います。 よくある例 まず例として、以下のような 「パフォーマンスに問題を抱えたコンポーネント」 を考えてみましょう。 import { useState } from "react"; export default function App() { let [color, setColor] = useState("red"); return ( <div> <input value={color} onChange={(e) => setColo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lukasbach/react-complex-tree: Unopinionated Accessible Tree Component with Multi-Select and Drag-And-Drop
GitHub - BetaSu/big-react: 跟着我，从0实现React18