玉石混合状態にあったFluxのフレームワークも、ここ最近ではReduxが首一つ抜け出したような感じとなっています。自分はFacebook/Flux派ではありましたが、先月発売された『WEB+DB PRESS vol.92』に掲載されていた伊藤直也さんのReduxの記事を読んで、Reduxを覚えてみようという気になりました。Redux自体はとてもシンプルで、とっつきやすいと思いました。ただReactとの連携はFacebook/Fluxと比べるとややこしい部分が多いかなといった印象です。ちょっとしたサンプルを作ってみたので、Reduxの実装方法とReactとの連携について紹介したいと思います。 ReduxとはReduxは、Facebookの提唱するFluxアーキテクチャに基づいて（影響を受けて）設計されたJavaScriptフレームワークです。作者は@dan_abramov氏。 reactjs

最近Railsで掲示板つくってて、サボって後回しにしていたJavaScriptの最適化をやりました。 掲示板の構成 Webpackを使っている Reactを使っている Server-Side Renderingをやっている Railsを使っている Sprocketsを使っていない 作業内容 webpack-bundle-size-analyzerで容量の大きいpackageを調査 HTTPクライアントに利用していたjQueryを撤廃 HTTPクライアントにaxiosを採用 lodashを一部しか読み込まないように変更 moment.jsの不要なlocaleを読み込まないように設定 変更結果 これでminify後の容量が770KB→476KBに。gzip圧縮状態では202KB→125KB。 $(npm bin)/webpack --profile --json | webpack-bundl

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? なぜ仮想DOMという概念が俺達の魂を震えさせるのか から一年、みなさまどのようなフロントエンドをお過ごしでしょうか。 僕はひたすら過去資産をリファクタしています。 需要の雰囲気 色んな所に書きましたが、去年僕が仮想DOM AdventCalendar をやったのは、「僕自身がproductionで使いたい」ので、「Reactまあいいよね」的な雰囲気を作って外堀埋めるのが目的でした。そして、その目的はおおよそ果たされたと言ってもいいでしょう。ご協力ありがとうございました。 僕自身はKobito for Windows でReactを使って

はじめに こんにちは。皆さんはReact使われてますでしょうか？ 今回はReactとFluxについて書きます。 MVCの問題点 詳しくはこちらに書いていますが、MVCでアプリを作った場合は、ModelとViewの間で双方向のデーターフローが作られる可能性があるので理解したりデバックするのが難しくなります。 React単体で使った場合の問題点 子のViewでなにかアクションを起こした結果、親のViewにも変更を伝えてなににかをする場合、子のViewに親のViewのコールバック関数を渡す必要があります。 子のViewの下にさらに、子のViewがあって、アクションが起こった時に親のViewに伝えようとするとコールバックが深くなって複雑になってしまいます。 Flux それを解決できる方法としてFluxです。 Fluxを使うとデーターフローが一方向になります。 やってることはObserverパターン

A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team

Sendagaya.rb #114に来たので、目標のブログ記事を書いてた。 今日はsendagaya.rbへ行ってブログ記事を一本仕上げるのが目標。— Koshikawa Naoto (@ppworks) August 10, 2015 今日は、React.jsの会なので、RailsからReact.jsをざっくり使って見る準備をしてみます。 目指すもの sprocketsのままとりあえず進む jsのライブラリをnpmで管理したい React.jsをES6で書きたいし、JSX書きたい herokuで動かすぞ！ react-railsは使いたくない 方針 sprocketsと共存するために、browserify-railsを利用し、ES6はBabelを利用します。ライブラリはそのまま、npmで管理します。 npmを入れます もし入っていなければnpmを入れましょうね。 brew install

Edit · May 15, 2015 · 16 minutes read · Follow @mgechev Flux JavaScript AngularJS React MVC MVW This is the first blog post of the series “Flux in Depth”. Is this “yet the another flux tutorial”? What I have seen so far, while researching flux, were mostly “how-to” tutorials (usually with todo applications), which describe the main components of given flux application and the data flow between the

コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること（切っても良さそうなんだけど...） 既製品・スクラッチは問わないが極端なリスクは踏めない（納期がシビア） あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10

私のように、Reactを使ってより進んだことがしたいと考えたなら、おそらく Flux に注目した経験があると思います。ざっと目を通してタブを閉じ、JavaScript開発者としての自分の人生を見直したことでしょう。 もしReactになじみがなければ、私の記事 「React入門」 を読んでみてください。 Fluxとは？ Fluxは、遠目には始めるために複雑な手順を踏まなければいけないように映ります。しかし、 GitHubにあるexample を見てみれば、これがどのように機能するのかが実に明確になってきます。 簡単に言うと、Fluxは美化された 出版-購読型モデル のアーキテクチャです。データはシステム内を一方向に流れ、そこから様々な利用者が必要に応じてデータを取得します。これについて考えるには、私たちの体に例えてみると簡単です。 イベント – 血液 血液は私たちの体内を一方向に流れています

詳しくはこちらへ → https://www.facebook.com/groups/toretatech/

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄

I've spent a good deal of the past year working with React. I've written, refactored, and re-written many components in that time, and I've seen some best practices and anti-patterns emerge. I'm not going to get into what React is or why you should use it — there are plenty of articles about React floating around the internet. I'm also going to assume you know the basics of working with React and

僕はIncrements(このQiitaの会社)に入社して以来、KobitoのWindows版を作っていて、その中枢の画面遷移と状態管理をライブラリとして抜き出した。それがArda。 基本的には昨日発表した https://speakerdeck.com/mizchi/real-world-virtual-dom というスライドに書いたとおり。 mizchi/arda Ardaの概要 Ardaの目的はFluxの概念をベースに、画面遷移と状態とシーンをベースにしたヒストリ管理、その際のDispatcherのコンテキスト切り替えを行うことを主な目的としている。 CoffeeScriptでの最小構成だと次のようなコードになる Arda = require 'arda' # Arda.Component extends React.Component class HelloComponent ex

“Open company, no bullshit” isn’t just one of our values. It’s a way of life at Atlassian. Here’s what we’re sharing with our investors and stakeholders each quarter.

はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン

The web frontend scene is witness to many new frameworks and ways of working. It can be quite annoying when software becomes legacy quicker than ever. But actually, it's just good old innovation happening as it should, because the opportunities for improvement are there. Frameworks come and go, but what remains are the good ideas that they brought to the world. We're going to talk about the good i

この記事は VirtualDOM Advent Calendar 2014 - Qiita の2日目です。 mizchi くんから誘われて軽い気持ちで参加したら、初日からえらくエモいエントリー(VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita) でブルってます。 Virutal DOMとは、と言う話はしません。初日を見てください。いろいろ良いことあるみたいだけど、Virtual DOMってどんだけ早いの？知りたいですよね。 Elmの中の人が作ったTodoMVCのパフォーマンステストがあります。 いつものTodoMVCのデモで、100要素追加して、全て完了して、削除するというテストです。 「Run All」ボタンをクリックすると動きます。 http://evancz.github.io/todomvc-perf-comparison/ Virtua

この記事は VirtualDOM Advent Calendar 2014 - Qiita のネタが切れた時にどこからか指定されるやつです。中の人なんであんまり行儀悪いことすると怒られるんだけどな！ やりたいこと UXとSEOのためにイニシャルビューはサーバーサイドで生成し、再描画時にクライアントで同じテンプレートから生成するも、一旦画面を捨てて再構築するのを避けたい。 具体的には、サーバーサイドで何かしらの方法(nodeやreact-railsを想定)で実行して生成されたReactのId付きのDOM React.renderToString(Component({})) して生成したreactId付きHTMLに対して、再描画せずにReactを適用できるようにする(イベント注入含む) 手法 reactのid付きDOMはこんなもの。