React Context を用いた簡易 Store
課題 redux を引っ張り出すと大仰になる。Context 下に共有ステートを持ってそこに setState できるだけでよい。 なので、次の 2 つを用意する 現在の state を参照する const appState = useAppState() 現在の state を更新する関数を返す const setAppState = useSetAppState() React.useState() と違って分割している理由は、主にパフォーマンス上の理由 大域な参照なので、可能な限りステートを参照したくない setState() の API は (prevState: State) => State も取れるので、状態更新用途に限ってはそもそも useAppState() せずに済むことが多い でも毎回書いてるけどボイラープレート感強い上に忘れるのでここにメモする 毎回書いてるボイラー
瀕死のシステムが強くなって復活する話
弊社が展開しているタクシー配車サービスにおける乗務員様向けのシステムは今、大きな転換期を迎えています。 約半年に渡って進めてきた、大規模リファクタと開発対象デバイス刷新のプロジェクトがいよいよ陽の目を見るためです。 そんな新システム開発の裏で最低限のメンテしかされず、死にゆく運命にいる現行のシステムがあります。 とあることがきっかけで、今まで想定されていなかった多種多様なユースケースへの対応が必要となり、 現行のシステムにも新たに生まれ変わるチャンスが巡ってきました。 ただし、現在の実装の成熟具合から、現行のシステムを拡張する形での対応は難しく また大規模に改築するにしても、 平行開発している新システムとのコード的な共存(マルチモジュール)を意識して対応しなければならない状況です。 本セッションでは、上記対応を行った中で学んだ ・多種多様なタクシー乗務のユースケースへ対応するための状態変化
【SSRも】Fleur − 新しいFluxフレームワーク【イケる】 - pixiv inside
みなさんこんにちは！ VRoid Hubでフロントエンドエンジニアをしている花倉ミツカ (a.k.a. ラグ)です 🙌 今回のpixiv insideはちょっとだけお仕事から離れて(ガチ)アイスブレイクです。私が1年ほど開発しているFluxフレームワーク、Fleur (フルール, @fleur/fleur)について、その設計や使い方についてご紹介させていただきます！ 目次 どういうフレームワーク？ 実際の使い方 質問 まとめ どういうフレームワーク？ pixiv Sketchで採用されている Fluxible というFluxフレームワークを参考に、「書きやすさ」と「現代的な機能の採用」の二点を重視してTypeScriptでフルスクラッチしました。（Fluxibleは私が知ってる中で一番"整っている"フレームワークだと思っています♨） Fleurの大規模なプロダクションでの採用実績はまだあ
React+Fluxアプリケーションにpropsバケツリレーは必要か
React+Fluxアプリケーションのメンテをしている中で「propsのバケツリレーを減らすためにContainerを増やしてもよいか？」というディスカッションになったので、考察をまとめてみます。 いまの設計の確認 FluxUtilsフレームワークを利用している 複数のStoreを持つ ComponentTreeのRootをContainerとし、StoreのStateを受け取る Tree状に配置された各Componentにはprops経由で状態を受け渡す 各Componentはローカルステートを持つことができる ちなみに、ここで言うFluxの定義については「React+Fluxで正しく設計するためのFlux見直しガイド」にてまとめています。 propsのバケツリレーと単一Containerとは？ Reactアプリケーションでしばしばある「ComponentTreeのRootでアプリケーシ
ドメイン駆動Vuexで複雑さに立ち向かう
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex（さらにその他Flux状態管理も）を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
Flux層の責務について考える
The Efficiency Paradox and How to Save Yourself and the World
Reactで開発するチームが共通認識しておきたい重要な概念 - KitchHike Tech Blog
SFC, Redux, HOCなどコンポーネント指向とReact開発のキーワード CTOの Shoken です。キッチハイクでは2年前にRailsへのReact導入、1年半前に0ベースからReact Nativeでアプリ開発を始めました。この記事では、React, React Nativeで開発しているチームが共通認識したいReactの重要な概念について紹介します。 2018/11/07 追記（はてブコメントより） Reactリポジトリで名称の変更が行われ、変数名やクラス名が変更されました。いままでの Functional Component が Function Component となり、 Stateless は使わなくなって Function に統一されるようです。 Terminology: Functional -> Function Component #13775 Before
Discordはどのようにして40人のエンジニアで1億3000万人以上にサービスを提供しているのか？
「Discord」は、主にゲーマーを対象とした音声通話・チャットアプリです。ブラウザ上で動作するほか、WindowsやiOS、AndroidなどほとんどのOSにアプリを配信していることを始め、Slackのようなテキストチャンネルと低レイテンシのボイスチャンネルを合わせ持っていたり、ビデオ通話や画面共有が簡単に行えたりするなどの特徴が人気を呼び、2015年に登場してから3年間で1億3000万人以上が使用するアプリに成長しました。そのDiscordはたった40人で開発されているのですが、どのようにして少人数でありながらさまざまなプラットフォームでアプリを展開できているのかについて公式ブログで解説されています。 Why Discord is Sticking with React Native - Discord Blog https://blog.discordapp.com/why-disc
Mozillaがメリトクラシーを捨てるとき - Mozilla Flux
Mozillaはガバナンスのあり方を自ら定義しているのだが、最近、その定義を見直す動きがある。mozilla.governanceフォーラムの"Proposal: Addressing the term “meritocracy” in the governance statement"スレッドで議論が行われている。 まずはMozillaのガバナンスのあり方について、現在の定義を見てみよう。 Mozilla is an open source project governed as a meritocracy. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they
クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し
FluxのStoreがViewModelかって話からのMVWとかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
StoreがViewModel相当かどうかってことそれ自体はたぶんあんま本質じゃないんだけど。 blog.nkzn.info これについてです。 わかる。StoreがViewModelってのはちょっとだけ違和感あって、ぼくは ViewModelが読むためのクエリ用モデルくらいに思ってるけど、どちらにせよクリーンアーキテクチャ的な考えで言う「外側」のものだよねという点ではたぶん認識一致してると思う https://t.co/IMQADHGwUb— 猫型🐱蓄音機 (@shinpei0213) 2018年5月15日 べつにStoreが ViewModel相当なのかクエリモデル相当なのかってのはじつはどうでもよくて、あのクリーンアーキテクチャの同心円の外側に位置するものだってことがたぶんこの記事の本質。で、クリーンアーキテクチャは同心円の層の数を定義してなくて、— 猫型🐱蓄音機 (@shinp
FluxにはModelがないのではないかと思った覚書 - ナカザンドットネット
Fluxを使い始めると「おっ、MV＊に比べて頭が悪くても状態が壊れないぞ？」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。 ModelやViewModelについてはコンテキストが違う人から「それ違くない？」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。 1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している これは全くポジティブな要因。 2. FluxはMV＊のModel相当の要素が図に含まれていないので考えることが減った MV＊は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった（その責務分割が適切だったかは別として）と思う。 でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない？って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか？」という話をします。 結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。 まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。 その上でReduxの特殊性は Stateがピュアなオブジェクトで表されている Stateの更新はイベントを契機に常に同期的に行われる 以上2点により いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
FluxとDDDの統合方法 - かとじゅんの技術日誌
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i
Reduxの正しい解釈の話
2016年の課題は状態遷移の管理だったと思う。 そのアンサーとして、 Fluxのような実装におけるStore相当にアプリケーションの状態をほぼすべて管理させるReactのようなVirtual DOMを搭載したビューの実装を透過的なユーザーインターフェースとして扱うこの2つの組み合わせにより、アプリケーションの状態と描画される画面が (ほぼ) 参照透過的になる。というのがFluxとReact以降のパラダイムだと思う (理論として) 。 このパラダイムなら、エラーの発生時にアプリケーションの状態を表現するJSONをエラー収集サービスに送るようにして、簡単にバグを再現したりできるし、状態の遷移をテストしていくことで、クラッシュするようなバグのうち大半を検出できる。 Fluxの問題そこで問題が出るのが、Action(Creator) とReducer (Store#reduce())の2要素間のル
Firebase, React, FluxでWebアプリ作って思ったこと - Qiita
ここで書いてること タイトルの構成でWebアプリ作った際に思ったこと 作り方ではないのでコードは一切書いてない 作り方的なのも書きたいけど多分無理 きっかけ 2016年は結構ダラダラしてた 仕事以外ではほとんど何も書いてない 夏以降は筋トレのことばっか考えてた おかげで筋肉はついたよ そろそろ何か始めようかと思った 何を作ったか 何をはさほど重要ではなかった 今回重視したのは何を触るか Redux(Flux) React Webpack Firebase postcss 結局作ったのはメモ帳でした Redux ReduxというかFluxでちゃんと作ってみたかった Reduxのチュートリアルはやった 公式ドキュメントは読んだ Fluxを調べる内に@azu_reさんの10分で実装するFluxに辿り着いた これで良いじゃない Fluxの実装面をちゃんと理解して書ける 別にReduxを使わなくても
イベント用の名札シート印刷アプリ「参加者の名は。」を作った - エンジニアをリングする
こんなものを作ってみました。 yoshiko-pg.github.io ConnpassのイベントURLを入力してCreateボタンを押すと、名刺サイズの参加者の名札を印刷プレビューできるようになっています。 （主催するイベントがないけど動きを見てみたい場合、入力欄右下の「demo」を押すと雰囲気がわかるかと。） 右下の印刷ボタンで印刷できます。 管理者や補欠者もお好みで含めることができます。 背景 カンファレンスや勉強会って、普段ネット上でしか知らない人と直接話せる機会でもあると思うのですが、いざその場で顔や名刺を見ても誰が誰かわからないんですよね。。 SNSではよく見るけど顔がわからなくて、でも話したいことがあるときとか、頭の上にアイコンとIDが表示されるメガネがほしい・・・ってたびたび思ったりします。 そんな思いから、自分がスタッフとして関わっているイベントではアイコンとIDの入った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flux の失敗は Store に Store という名前をつけたこと - fsubal
コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する
