どうしてWaltsを開発したのか - そして昨今のFlux - Qiita
まずFluxとはなんだろうか。Fluxの解説はすでに多数掲載されているが、ここでは「データフローを一方向としたアーキテクチャ」と定義したい。 そもそも、FluxというのはObserverパターンにちょっとした規則を設けて、かっこいい名前を与えたに過ぎないのだが、現代のフロントエンドはこのFluxを見事に受け容れた。なぜか。それは開発者が秩序を求めたからである。 これは、拡大し続けるフロントエンド・サイドの開発規模に対して、従来のMVC、正確には複数のViewと複数のControllerが相互にデータを受け渡し合うアーキテクチャがスケールしなくなったことに起因する。（ここではMVCを厳密に定義していない。GUIアーキテクチャについてなのかバックエンド・アーキテクチャについてなのか判然とさせないまま、俗語的に用いている） シングルトンという名でごまかした巨大なグローバル神オブジェクトを至る所で
React使い必見！ Immutable.jsでReactはもっと良くなる | Wantedly Engineer Blog
Reactを導入して半年近くが経ちましたWantedlyでは、今年の初めからReact(+Redux)の導入に取り組み始めたので、気付けば半年近く立っていることになります。今自分がこの記事を書いているエディタから、Wantedly Adminのチケット画面まで、ある程度大きなアプリケーションを開発してきました。 そこで今回は、チームで継続的に開発していく過程で遭遇した問題と、それを解決するために導入したImmutable.jsについて紹介します。 増え続けるCallbackとAction、肥大化するStoreReactとセットで語られることが多いFluxアーキテクチャ。ここでは詳しい説明は省略しますが、とてもシンプルな考え方なので、チュートリアルなどで簡単に学ぶことができます。しかし、実際にチームで開発していくと、たしかに動いてはいるけど、綺麗とは言い難いコードが増えてしまいました。 Ac
React / Flux を実案件で使ってみた (2015/02/16 講演資料) - Qiita
2015/02/16 歌舞伎座.tech#6「VirtualDOMとReact」 自己紹介 Name : Takuto Wada github : twada twitter : t_wada hatena : t-wada TDD とライオンの人 power-assert の人 React / Flux を知ったきっかけ mizchi さんのエントリ (あなたがReactを使うべき理由) だったと思う 日本語の情報はほとんど無かったが、エッジ系の人たちが騒ぎ出した & 海外で圧倒的に事例が増え出したので興味を持った Rendr をつくった AirBnb が React を使い始めたことを知り、これは決定的だと思った React をどう勉強したか 公式ドキュメントとチュートリアルが充実している まず Tutorial をそのまま写経 次に browserify + babelify で T
React on 現場 ~ あるいは Modern JavaScript on Rails ~ - Qiita
これは何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料。特に理由はないが公開するのを忘れていた。 スライドモードのリリースにあたって公開する 近況(2016/01/16) 昨年9月 Kobito for Windows => Qiita開発チーム モダンなJS(当社比)を導入しようとした モダンなJSとは(mizchi主観2016版) npm/browserifyで依存を解決 Babel/ES2015 React/Flux Testable No More jQuery plugins ※これらの基準について今回は割愛 現実(2015) CoffeeScript Sprockets / グローバル名前空間渡し Backbone JSのテストはjasmineで数件 (※request specは豊富) jQuery plugins
Riot.jsを快適に動かすgulpタスクの話とRiotControlを用いたFluxデザインを実現してみた話 - Qiita
はじめに 仮想DOMのフレームワークが乱立する殺伐としたJS界隈ですが、Riot.jsが神すぎたので少しでも人口が増えればなーと思い書きます。 Riot.js自体の素晴らしさは以下の記事で十二分に伝わると思いますのでこの記事では省略ということで。 Riot.js 2.0 を触ってみた — まだReactで消耗しているの? Riotjsのいいところ また、最後の方に出てくる今回作ったプロジェクトは以下にリポジトリを置いてますので適当にお持ち帰ってくださっても結構です。 gaogao-9/testriot - GitHub 環境説明 今回はタイトルの通り、環境構築の話をメインでしていきます。使用するバージョンは以下のとおりです。 Node.js 6.x npm 3.x gulp 4.x (※執筆時点でβ版です！) babel 6.x Riot 2.x rollup 0.36.x gulp 4.
jQuery + Flux という選択肢 - peroli Developer's Blog
2016 - 05 - 27 jQuery + Flux という選択肢 JavaScript Front-End こんにちは、 SKAhack です。普段はMERYのWebフロントエンドを主に書いています。 今回はMERYのフロントエンドで採用している jQuery + Flux という構成を紹介してみたいと思います。 なぜReactではなく jQuery か 普通はReact + Fluxで語られることが多いですが、MERYでは JavaScript の ソースコード の大半が jQuery に依存しており、簡単には jQuery を捨てられない状態です。 また、Viewの変更をする２つのライブラリを 共存 させるのも良くないですし、MERYのサービス特性上、現時点で1画面を頻繁に書き換えるような処理は少ないこと、ReactがサポートしていないIE8など古いブラウザもサポートしているとい
Almin.js | JavaScriptアーキテクチャ
autoscale: true Almin.js | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? How to work as a Team Read/Write Stack | JavaScriptアーキテクチャ 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔軟性、独立性 見た目が複雑ではないアーキテクチャ 書き方が特殊ではなく見て分かるもの 設計の目的 テストが自然に書ける パーツごとに無理なく
webdesign-dackel.com - このウェブサイトは販売用です！ - webdesign dackel リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita
想定しているシチュエーション 非SPA環境で個別にマウントされるコンポーネントがそれぞれで小さくFluxするような環境。 SPAガッツリ組むのでないなら、Fluxフレームワークは不要だと思っていて、とは言えオレオレ構成も行き過ぎると害になる。 その辺のバランスをとって、次のような構成がいいのではないか、と考えてみた。 考え方 コンテナがEventEmitterを1つ保持する コンテナはEventEmitterの各種イベントをListenする コンテナはpropsとstateを区別して扱い、stateを更新する コンテナはコンポーネントを一つだけ描画する コンポーネントはpropsとして渡されたEventEmitterを発火させる コンポーネントはEventEmitterをListenしない コンポーネントはpropsのみ扱う コード // src/components/header.js
Fluxで消耗するために自分でFluxフレームワークを作ってみた（Amamoriといいます） - タオルケット体操
場所 ギッハブにあります。 github.com 作った動機 Fluxフレームワーク、色々出てきては消えるしReduxとかが提唱されるしでもうわけわかめ。これからアタシ（のプロジェクト）、一体どーなっちゃうの〜〜？！ APIリファレンスみて色々と見比べてるだけの中途半端な知識だと、いざ自分が選んだフレームワークが死んだ時に潰しが利かない…… -> じゃあ一度自分で作ってみよう！ あと社内にFluxわかるマンがいなかったので、公開して広く世間の意見を求めたいという気持ちも強かった。なんかおかしいところあったら教えてくだされ〜〜〜 というわけで作った。 あとES6で書いたコードをnpmモジュールで公開する方法を知りたかったというのもある。 大変だったところ Fluxを実際に実装に落とし込める感じに理解するのが大変だった。 理解するために、Facebookの概念図をみたり、azu氏の実装（Git
Fluxフレームワーク戦争の現状確認（後編） - マルシテイア
この記事は仮想DOM/Flux Advent Calendar 2015の25日目……に入れようと思ってたけどもう埋まってた……。 オマケということで頼む！！！！！ 24日目は JavaScript - 実践：MagJS で TodoMVC - Qiita でした。 メリークリスマス！！！！！！！！！！ こんにちは id:amagitakayosi です。 みなさん今月も Flux 書いてますか？ 僕はオレオレ実装をIsomorphic対応したけど昨日Revertしたところです！！！！！ウオー！！！ 今日は↓12/2の記事↓の続きを書いていきます！ amagitakayosi.hatenablog.com もくじ 前回のあらすじ flux-utils Container vs View Cycle.js flux-challenge Rx系 thisless-react, Yolk DDO
The Evolution of Flux Frameworks
There has been no shortage of great Flux implementations, such as Flummox, Alt, or Fluxible. Most of them are focused on making Flux easier to use with the server rendering and reducing the boilerplate. They also often provide convenience utilities like higher-order components and asynchronous action helpers. Still, under the hood, many of them are built on top of the original Flux Dispatcher. Red
Vue.jsにreduxを載せた話｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
概要 先日とある案件でVue.jsを用いたアプリケーションを開発することとなりました。 一般に同種のフレームワークと比較してVue.jsは、学習コストが低く気軽にはじめやすいということがメリットとして語られています。 ただ、今回の案件のようにMVC系フレームワークを用いて開発する際にネックとなっていたのが、コンポーネント間のデータ共有についての最適解が見つけられていないと感じていたことでした。 もちろん、適切にモデルを設計すればコンポーネント間のやり取りに責任を持つ、親コンポーネントとでもいうべき層を実装することでこの問題は解決できると思います。 しかし実案件では往々にして親コンポーネント層の実装が個々人の裁量に陥りやすく、結果的にコンポーネント間データ共有の方式が統一出来ていないケースも出てきてしまいました。 コンポーネント間で共有したいデータ=アプリケーションの本質となるデータは、もっ
Reactを用いたアプリケーションアーキテクチャ：Fluxを再考する | POSTD
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
さらに多くのことが変化する – Fluxは新しい”WndProc”である | POSTD
たまたま今まで知らなかったという方のために言いますと、ReactはWebプログラミングにおける最先端の新技術です。そのアイデアはシンプルです。それは、Reactの各コンポーネントは、JavaScriptにおいて、ビューを冪等（べきとう）に描画します。ビューは、コンポーネントが内部に保持している少量のステートのみに基づいてレンダリングされます。同じステートにすれば、その状態におけるコンポーネントは常に同じようにレンダリングされます。これは、データが変われば、Reactは その変更のみを ブラウザのDOMに適用できるということでもあり、ページ全体の再レンダリングを省略できます。実際、何かを変更するかどうかという決定は 全て 、コンポーネントの内部状態に完全に左右されます。それが、なぜReactが非常に早いのかという根本的な理由です。 しかし実際のところ、React自体には、変更をどのように 伝
cybozu.com 稼働状況 を React/Redux で作り直した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。Sales Systemチームの金子です。Sales Systemチームでは、cybozu.com Store や、販売管理システム等の開発をしています。 このエントリでは、cybozu.com 稼働状況のフロントエンドをReact/Reduxで作り直した話を書いていきます。「React/ReduxでWebアプリケーションを作ってみようと考えている人」を対象としています。 TOC 「cybozu.com 稼働状況」とは? 作り直した背景 技術概要 React/Fluxについて React/Redux Routing Resources Async Multilingualization/Localization ES6 Utility Lint Testing 取り組んでみた感想 まとめ 「cybozu.com 稼働状況」とは? クラウドサービスはサービスの稼働状況をステータス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜReduxを使うのか
VanillaJSでIsomorphicなFluxアプリ作ってみた話
Electron, Flux + React
