React への依存を最小にするフロントエンド設計JSConf JP 2024 での発表資料です
React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
最近のフロントエンドフレームワークに対する認識とお気持ちの整理 - console.lealog();
久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。 この先、また技術選定する際なんかにも参考になるかと思ったので。 React 「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。 Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。 一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし） 原初の時代からReactな案件をそれ
ReactのコードをHooksにリファクタリングしていく話 - JX通信社エンジニアブログ
フロントエンジニアの渡辺(@pentla)です。 AI 緊急情報サービスの「FASTALERT」は、Reactをフロントエンドのスタックとして採用しており、3年ほどコードベースは大きく変えずに運用しています。その過程で、Flow → TypeScriptへのスタックの変更など、継続的にリファクタリングを進めています。 tech.jxpress.net 今回は、Classベースのコンポーネントを、Hooksを使って関数ベースのコンポーネントに書き直す話です。 今回の対象読者は、 Reactを書いたことがある方 Reactのパフォーマンスについて気になっている方 Hooksは知っているけれど、プロダクション環境に入れるか迷っている方 を対象にしています。 Hooksとは v16.8から追加された機能です。今までは、Stateやライフサイクルメソッド（表示時に一度だけ呼び出したいときなど）の機能
正真正銘のReactだけの不純物なしでReact入門
Reactのチュートリアル、たくさんありますよね。どれも質が高く、どこから手をつければいいかわからなくなっちゃいます。 ですがやはり巷のチュートリアルには面倒な問題もあります。今回は面倒ごとを全部すっ飛ばしてReactでのウェブアプリ作りに入門してみましょう。 Reactを始めるには、まずあれとこれとそれとどれと…… Reactやるには、まずNode.js入れてbabel入れてreact入れてreact-router入れて、ついでにredux入れてreact-redux入れて、redux-saga入れて…… Reactめんどくせえ！！！ってのが正直なところだと思います。はい、私もそう思います。ただ、まあ、色々必要なのも事実なので……。 それでもやっぱり「ReactやるならReactだけやりたい。他はどうでもいい」という気持ちは簡単に捨てられるものではありません。そこで今回はそういう面倒全部
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Reactの次期機能のSuspenseが凄くって、非同期処理がどんどん簡単になってた！ - Qiita
React17の次期新機能のSuspenseが凄い！ と思ったので少し学習していました！ Suspense自体の説明は下の動画がわかりやすいかも。 13:15ぐらいからプログラムのDemo 29:30ぐらいからSuspenseとはなんぞや、という説明をしてくれています。 Githubにdemoもあったので、実際に動かしてみたい方はこちらも是非是非 つまりSuspenseって何？ Suspenseっていう機能があるわけじゃないんです、すみません 概念というかなんといいますか 自分の意訳・解釈なので間違っていたら土下座しに行きます 外部APIからデータを取得・表示するような処理で使えるんですね。 読み込みを開始したらLoadingを出して、APIが戻ってきたらデータを表示してローディングを消して……っていう、reduxやsagaを使って今まで頑張ってきているものがあると思うんですね。 API実
React+Electronアプリを作ってみよう
こんにちは。前置きは抜きにすぐ作ります。 Create Application 01: create-react-app まずはcreate-react-appです。なかったらnpm install -g create-react-appしてください。 うまくいったらyarn startで起動しましょう。しましたか？うまくいってるのを確認したら即刻ジョブ止めましょう。もう二度とyarn startを実行することはありません。 02: install Some Package 以下のパッケージをインストールしてください。最新ので問題はないはずです。すべてインストール時に--dev-dependenciesを付けることを忘れないでください。まあ忘れてもいいです。 electron npm-run-all 03: setting up Electron こちらのgistを参照してください。 次に
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
Railsで構築しているWebサービスをjQueryベースからReactに移行する時の知見 | スペースマーケットブログ
こんにちは、エンジニアの小林です。 先日、スペースを貸し出すオーナー様向けのダッシュボード(管理画面)をリニューアルしました。 スペースマーケットはwebサーバもAPIサーバもRailsで構築しているのですが、JQueryをベースに構築していたリニューアル前の実装からReactをベースにした実装へ移行した際に得た知見を書きたいと思います。 サーバ構成 既存のサーバ構成では、webサイトはwebサーバから、アプリはAPIサーバからそれぞれデータベースを参照していました。 リニューアルに伴いwebサーバからもAPIサーバを参照する構成となります。 webサーバから別ドメインのAPIサーバにアクセスするためには CORSの設定 webサーバとAPIサーバはドメインが違うため、ReactのコードからAPIサーバにajaxリクエストが送れません。これを回避するためにCORS(Cross-Origin
俺のJSライブラリの世界観(2014末版) - Qiita
概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指しているのだけど、コアドメインをTypeScriptで書いて、それをUI層からCoffeeScri
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React のユーザーから見た今後のフロントエンドの予想