React Router v6 で登場した <Outlet /> を活用すると、良い感じに共通レイアウトを組み込めて、さらに <React.Suspense> や React.lazy() を組み合わせると体験が良くなるのを見つけました。おそらく React Router v6 を利用する上での頻出イディオムになると思うので、自分用のメモとして残しておきます。 最終的なサンプルコードはこちら。 使用したライブラリは次のとおりです。見た目がしょぼいとテンションが下がるので MUI で装飾していますが、本筋とは関係ないので今回は特に触れません。 react@18.0.0 react-dom@18.0.0 react-router-dom@6.3.0 @mui/material@5.9.3 @mui/icons-material@5.8.4 @emotion/react@11.10.0 @emo
As we shared in the release post, React 18 introduces features powered by our new concurrent renderer, with a gradual adoption strategy for existing applications. In this post, we will guide you through the steps for upgrading to React 18. Please report any issues you encounter while upgrading to React 18. For React Native users, React 18 will ship in a future version of React Native. This is beca
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type
先日 react-redux の v7.1 の stable release で hooks に対応したAPIが入り界隈で話題になりましたね。(追加されたAPIの詳しい解説はこちら https://react-redux.js.org/api/hooks) 結構コンポーネント内からお手軽に参照できる感動を伝えている情報が多いのですが(実際私も感動の嵐です)、ここで改めて「なんで Container コンポーネントって必要なんだっけ？」と「hooks APIではどうやって Container コンポーネントを書くのか」を考えていきます。 なぜ hooks API になった今でも Container コンポーネントが必要なのか 始めにここで言う "Container コンポーネント" は 「Redux の Store から値を注入するためのもの(あとdispatch 関数)」という狭義の意味で
This blog site has been archived. Go to react.dev/blog to see the recent posts. With React 16.8, React Hooks are available in a stable release! What Are Hooks? Hooks let you use state and other React features without writing a class. You can also build your own Hooks to share reusable stateful logic between components. If you’ve never heard of Hooks before, you might find these resources interesti
Enigmo Advent Calendar 2018の4日目の記事です。 この記事の目的 Enigmoが運営しているBUYMAでは古代から運用しているjQueryの他に、2016年頃から一部ページのフロントエンドをReact/Reduxで構築しています。 私自身もEnigmoに入社してからの約三年間でReact/Reduxアプリケーションの開発に多数携わってきましたので、そこで培った知見を共有したいと思います。 React/Reduxの利点 まずはじめに、ReactとReduxを使うメリットを再確認しておきたいと思います。 それぞれのメリットをしっかりと認識しておくことで、実装する際どう書くか迷ってしまった場合などにそのメリットを最大限活かす選択をすることができます。 Reactの利点 コンポーネント化が容易で再利用性が高い 状態をDOMから分離できる(Stateless) Reduxの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
