Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷 - エンジニアHub｜Webエンジニアのキャリアを考える！
こんにちは、小林（@koba04）です。 本記事では、シングルページアプリケーション（以下、SPA）における状態管理について解説します。 GmailやTwitterは、SPAとして構築されている代表的なWebアプリケーションであり、スムーズなページ遷移をSPAによって実現しています。またElectronやPWA（Progressive Web Apps）の登場により、複雑なアプリケーションをWebの技術を使って構築する場面も増えてきました。 これらの複雑なアプリケーションにおいては、既存のページ単位での状態管理の考え方では対応が難しくなります。 そこで今回は、具体的なフレームワークも取り上げながら、Webフロントエンドにおける状態管理のアプローチについて紹介します。 フロントエンドでの状態管理の複雑化 ページの単位を超えた状態の保持 モデルとビューによる処理の分割 イベントの管理が複雑にな
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
Reduxの正しい解釈の話
2016年の課題は状態遷移の管理だったと思う。 そのアンサーとして、 Fluxのような実装におけるStore相当にアプリケーションの状態をほぼすべて管理させるReactのようなVirtual DOMを搭載したビューの実装を透過的なユーザーインターフェースとして扱うこの2つの組み合わせにより、アプリケーションの状態と描画される画面が (ほぼ) 参照透過的になる。というのがFluxとReact以降のパラダイムだと思う (理論として) 。 このパラダイムなら、エラーの発生時にアプリケーションの状態を表現するJSONをエラー収集サービスに送るようにして、簡単にバグを再現したりできるし、状態の遷移をテストしていくことで、クラッシュするようなバグのうち大半を検出できる。 Fluxの問題そこで問題が出るのが、Action(Creator) とReducer (Store#reduce())の2要素間のル
How to work as a Team
autoscale: true How to work as a Team 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 目的 新規でそこそこ複雑なウェブページを作る(アプリに近い) ある程度柔軟に拡張でき、メンテできるような設計にしたい 無難にReact + 何かでちゃんと設計して作っていきたい この設計部分をどう決めていくのかという話 現状 チームにReact/Flux/Reduxを触ったことがない人が多い どれが(主にView以外の設計)ベストかは分からない Flux的な部分の話 ものごとは変わる。 混乱は変わらない 混乱の原因 情報過多 情報不足 適切でない情報 上記の組み合わせ！ via P21 今日からはじめる情報設計 情報の共有 情報不足 そもそもReactなどを知らない人には知ってもらう必
Fundamentals of Redux Course from Dan Abramov
In this comprehensive tutorial, Dan Abramov - the creator of Redux - will teach you how to manage state in your React application with Redux. State management is absolutely critical in providing users with a well-crafted experience with minimal bugs. It's also one of the hardest aspects of a modern front-end application to get right. Redux provides a solid, stable, and mature solution to managing
André Staltz - Unidirectional User Interface Architectures
This post is a non-exhaustive quick overview of the so-called “unidirectional data flow” architectures. Not meant to be taken as a beginner tutorial, but rather as an overview of their differences and peculiarities. At the end, I’ll introduce a new architecture which deviates significantly from the others. This post assumes client-side Web UI frameworks only. TERMINOLOGY It would be confusing to t
Reactを用いたアプリケーションアーキテクチャ：Fluxを再考する | POSTD
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
Relay チュートリアル【日本語翻訳】
先日、Facebookがデータ駆動型のReactアプリケーションの開発を行うためのJavaScriptフレームワーク「Relay」のTechnical Preview版を公開しました。さっそくですが、自分の理解を深めるためにRelayのチュートリアルを和訳しました。せっかくなのでブログにもアップしておきます。誤訳などもあるかと思いますが、Google翻訳よりはマシだと参考にしていただければと思います。原文もつけておいたので、翻訳がおかしなところもなんとなくニュアンスを掴んでいただければと思います。 Relayチュートリアルに行く前に、Relayの基礎知識RelayRelayは、「データ駆動型のReactアプリケーションを開発するためのJavaScriptのフレームワーク」です。RelayはReact同様、Facebook�が開発を進めています。Relayを使うと、サーバから取得したデータを
yahoo/fluxible による SPA + Server Rendering の概観
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
銀の弾丸は川から流れて来ない - saneyuki_s log
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月～半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り（というのは半年くらい前に書いたな……）。
フレームワーク対決！Angular VS React仮想パネルディスカッション
フレームワーク対決！Angular VS React仮想パネルディスカッション 吉川 徹 特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。 今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、di
10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
material-fluxというFluxライブラリをREADME駆動で開発した
material-fluxというFluxアーキテクチャの実装ライブラリを書きました。 Fluxって何?と思う人は以下などを見ると良さそうな気がします。 React: Flux Architecture - Video Tutorial Series @eggheadio Fluxとはなんだったのか + misc at 2014 - snyk_s log Fluxアーキテクチャの覚え書きを書いた - snyk_s log The Flux Quick Start Guide Getting To Know Flux, the React.js Architecture ♥ Scotch What the Flux? (On Flux, DDD, and CQRS) — Jack Hsu なぜ作ったか IDE readable(machine readable)なライブラリが欲しかったのがひと
React 雑感 - Qiita
3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄を解消する。また結果的にテスタビリティを高める あたりだろうか。 React というと最初に目につくのは VirtualDOM だけれども、VirtualDOM は 1 や 3 を達成するために障害となった技術的課題を解消するためのテクニックであってそれ以上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Isomorphic Flux