React Context を用いた簡易 Store
課題 redux を引っ張り出すと大仰になる。Context 下に共有ステートを持ってそこに setState できるだけでよい。 なので、次の 2 つを用意する 現在の state を参照する const appState = useAppState() 現在の state を更新する関数を返す const setAppState = useSetAppState() React.useState() と違って分割している理由は、主にパフォーマンス上の理由 大域な参照なので、可能な限りステートを参照したくない setState() の API は (prevState: State) => State も取れるので、状態更新用途に限ってはそもそも useAppState() せずに済むことが多い でも毎回書いてるけどボイラープレート感強い上に忘れるのでここにメモする 毎回書いてるボイラー
Next.jsにSentryを導入した際の課題と解決策について｜食べログ フロントエンドエンジニアブログ
はじめまして、2021年11月に食べログFE(フロントエンド)チームにジョインした遠藤です。 Next.jsを採用した新規プロジェクトに参画し、Sentryの導入を行いました。本記事ではSentryを導入した際の課題と解決策について記載していきます。 1. はじめに「Sentryとは何か？」、「食べログでSentryを選定した理由」などにご興味がある方はまず下記の記事を読んでみてください。 Sentryは便利ですが以前はアプリケーションに導入するにはいくつかのファイルを作成して、エラーやパフォーマンスをトラッキングするのに様々な設定を行う必要がありました。 そこでSentryが簡単にセットアップができるように@sentry/nextjsでwizardを提供してくれています。 wizardはコマンドを実行するだけでSentryに必要なファイルを自動で生成し、設定までしてくれる便利な代物です。
私の推しフロントエンドディレクトリ構成と気をつけたいポイント
どうも、sakitoです。 今回は私の推しフロントエンドディレクトリ構成と気をつけたいポイントを紹介します。ちぇけら！ 2023年5月29日 追記 この記事を読みにきていただきありがとうございます。 私が記事を書いた時期はまだNext.jsのApp Routerが発表されたばかりで、App Routerを使用したディレクトリ構成の考慮はされていません。 先日、App Routerがリリースされ、Next.jsのドキュメントにApp Routerのディレクトリ構成について記事が出ているので、Next.jsを使用されている場合は、まず参照することをオススメします。 はじめに 今回、私の紹介する推し構成は、機能単位で設計するパターンです。 Reactのディレクトリ構成のベストプラクティスを集めたBulletproof Reactで紹介されているパターンにかなり似ています。さらに詳細なプロダクト構
「3種類」で管理するReactのState戦略
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
Create React AppからNext.jsへの移行事例紹介
はじめに この記事は、筆者がOOPartsというプロダクトにおいて、Reactのアプリを 「Create React App」 から 「Next.js」 に置き換えた事例を記す内容となっています。 これまで 「0からのNext.jsアプリケーションの作成」 文脈における記事は多くありましたが、「Create React App」から「Next.js」という、 同じReact環境における移行記事 はそこまで多くなかったと認識しています。 ある程度育ちきっているプロダクトであれば、フレームワークごと移行することは中々困難になると思っていますし、それを成し遂げることはとてもチャレンジングなことです。その結果、事例としての大規模移行事例は中々存在しませんし、稀有なことだと思っています。 本記事におけるOOPartsのNext.js移行に関する知見は、今後大きな移行する人たちの参考になれば良いと思っ
フロントエンドとオブジェクト指向
フロントエンドの実装にオブジェクト指向をどのように取り入れるかを考えます。 動機 近年のフロントエンドは、Reactなどのフレームワークを使ったコンポーネントベースの設計が主流だと思います。コンポーネントは、HTMLによるマークアップ、CSSによるスタイリング、JavaScriptによる振る舞いがひとまとめにされた、再利用可能な部品です。 コンポーネントの設計を考えていると、次のような疑問が生じます。 何を基準にコンポーネントで分割すればよいか。 コンポーネントの粒度はどれくらいが適切なのか。 どのタイミングで抽象化すれば開発コストが無駄にならないか。 分業した際にコンポーネントの分割や粒度の基準をどのように統一するべきか。 そこで、いろいろ調べたり試したりしたところ、フロントエンドの設計にオブジェクト指向を取り入れることが、これらの答えの一つになるのではないかと考えました。 この記事では
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
React17におけるJSXの新しい変換を理解する
今日発表された公式ブログの記事によれば、React17では新しいJSXの変換がサポートされます。これはどういうことなのか、我々にどういう影響があるのかをまとめました。 JSXの変換とは ほとんどの人は、Reactを使う際に以下のようなJSX記法を使っているはずです。具体的には次のようなもので、<div>のようなHTMLに近い記法がJSXです。 const Foo = () => { return <div> <p id="a">I am foo</p> <p key="b">I am foo2</p>> </div>; } これらは純粋なJavaScriptではないため、そのままでは実行できません。そのため、何らかの方法でただのJavaScriptに変換する必要があります。現代では、それを担うのはBabelやTypeScriptです。これらによって、上記のJSXを含むコードは次のように変換
Firebase, React, FluxでWebアプリ作って思ったこと - Qiita
ここで書いてること タイトルの構成でWebアプリ作った際に思ったこと 作り方ではないのでコードは一切書いてない 作り方的なのも書きたいけど多分無理 きっかけ 2016年は結構ダラダラしてた 仕事以外ではほとんど何も書いてない 夏以降は筋トレのことばっか考えてた おかげで筋肉はついたよ そろそろ何か始めようかと思った 何を作ったか 何をはさほど重要ではなかった 今回重視したのは何を触るか Redux(Flux) React Webpack Firebase postcss 結局作ったのはメモ帳でした Redux ReduxというかFluxでちゃんと作ってみたかった Reduxのチュートリアルはやった 公式ドキュメントは読んだ Fluxを調べる内に@azu_reさんの10分で実装するFluxに辿り着いた これで良いじゃない Fluxの実装面をちゃんと理解して書ける 別にReduxを使わなくても
Reactを使ったプロダクトのパフォーマンスを改善した話 | GMOメディア エンジニアブログ
技術推進室の色川です。 ここ一年くらいランキングシェアというキュレーションメディアのフロントエンドを担当しています。その記事作成画面をReactで実装しており、先日アイテムの移動をDrag&Dropで行えるようにしたのですが、動きはガクガク、ブラウザは途中で固まる、という有様で、パフォーマンスチューニングを余儀なくされたのでその内容を紹介します。 ［ランキングシェアの記事作成画面］ ※画面は開発中のものです。（動画にしたら？との意見があったのですが、Windowsで画面を録画する方法が分からず…） Reactのパフォーマンス改善の基本Reactはコンポーネントをツリーとして管理していて、あるコンポーネントの更新が必要になるとそのコンポーネントをルートとするサブツリー全体を更新します。 引用元：Reactive, Component-based UIs with React | Consta
[WIP] react-reduxについてドキュメントを読んだメモ - fukajun - DeepValley -
reduxの思想 統一されたデータストア アプリケーションの状態は1つのstoreオブジェクトが管理する stateはリードオンリー sateを変化させる唯一の方法はactionを発行すること 状態の遷移はただの関数によって行う stateを変更するための処理はreducersに定義します fluxの登場人物 actionCreator 最終的にactionを作るための処理 ajaxリクエストなどの処理を行い、その結果をのせたactionを作成する 例) 例えば、ajaxでコメント一覧を取得して { actionType: UPDATE_COMMENTS, comments: response.body.comments } のようなactionを作る action アプリケーションで何が起きたのかとそれに付随するデータ actionTypeと任意のデータを持つ単なるObject acit
React に対する感情とかコンポーネント管理ライブラリの選定とか
コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること（切っても良さそうなんだけど...） 既製品・スクラッチは問わないが極端なリスクは踏めない（納期がシビア） あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10
SLOBSERVER - L'actualité de Second Life
There are several aspects to consider when releasing a product or service into the market. With so much competition in all sectors, it might be hard for your product to stand out if you don't start by marketing it properly. Marketing, as well as how a user reacts to your product, is something that you should think of from the inception of your product to its launch. The Time to Market plays a sign
React 雑感 - Qiita
3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄を解消する。また結果的にテスタビリティを高める あたりだろうか。 React というと最初に目につくのは VirtualDOM だけれども、VirtualDOM は 1 や 3 を達成するために障害となった技術的課題を解消するためのテクニックであってそれ以上
React / Flux を実案件で使ってみた
自己紹介 Name : Takuto Wada github : twada twitter : t_wada hatena : t-wada TDD とライオンの人 power-assert の人 React / Flux を知ったきっかけ mizchi さんのエントリ (あなたがReactを使うべき理由) だったと思う 日本語の情報はほとんど無かったが、エッジ系の人たちが騒ぎ出した & 海外で圧倒的に事例が増え出したので興味を持った Rendr の AirBnb が React を使い始めたことを知り、これは決定的だと思った React をどう勉強したか 公式ドキュメントとチュートリアルが充実している まず Tutorial をそのまま写経 次に browserify + reactify で Tutorial をもう一周やってみる (showdownはbrowserify 対応してい
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React Native for Webのこれまでから読み解くReact GUIのこれから
Hooks時代の設計の話 #agrinoteinside
革命と秩序とSPA
フロントエンドの技術を刷新した話し。
