王道か邪道か？ タイムスタンプによるステート管理
Reactによるステート管理では、ある状態が変化したら付随して他の状態も変化してほしい場合があります。例えば、次のような場合を考えます。 チェックボックスが1つある。 チェックボックスの初期状態は、HTTP APIから取得したデータによって決まる。 ユーザーはチェックボックスを操作できる。 APIからデータを再取得する場合があり、その場合はチェックボックスの状態が再取得されたデータに従ってリセットされる。 皆さんは、このような要件をどのように実装するでしょうか。 やりがちな実装 まず、やりがちな実装を見てみましょう。 const apiData = useApiData(); const [isChecked, setIsChecked] = useState(false); useEffect(() => { setIsChecked(apiData.isChecked); }, [ap
あなたはReduxを必要としないかもしれない – You Might Not Need Redux by Dan Abramov | mae's blog
今回は、エンジニア向け読み物サービス「Mybridge」のMybridge AIがランク付けした2016年9月のReactに関する記事の1位だった記事を翻訳して紹介します。Reduxの作者Dan Abramov氏の記事です。内容は、簡単に言うと、「無理してReduxを使わなくてもいいよ」という話です。ただ、使わなくてもいい理由をReduxの特徴を挙げながら述べてくれているので、Reduxについての理解も深まる内容になっています。原文がだいぶフランクな感じで書かれているので、日本語に訳すのが少々難しく、わかりにくい部分もあるかと思いますが、是非読んでみてください。 当記事は、You Might Not Need Redux – Medium (Sep 20, 2016) by Dan Abramovを日本語に翻訳したものです。 人々はReduxを必要とする前からReduxを使おうとします。「
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
redux-thunkなのかredux-promiseなのかredux-sagaなのか、それともredux#bindActionCreatorsをやめるのか - Qiita
前提 ここで書くのはあくまで個人的な意見です。 react, reduxはどちらも使い方次第でフレームワークっぽくも使えるし、ただのツールとしても使える。だからreact, reduxを使ったフロントアーキテクチャはいくらでもあっていいと思う。 これはそのうちの一つを提案するものです。 とはいえ特別な実装方式を編み出したわけでは全然なくて、むしろ１周して出戻りしたかんじ。 結論 非同期処理をコンテナ(またはそこで使うモジュール)に書くだけ。 今は、非同期処理をするためのredux middlewareを使ってないです。 過去記事(react, redux周りのパッケージ選定とKPT[2016-05-27現在])にて、この辺についてもなんやかんやと言っているけど、今はthunkもpromiseもsagaも使っていない。その実装が凄くシンプルで気に入ってるので紹介します。 どうやるのか red
ReactComponentのコンストラクタを追いかけて
Document for ReactMeetup#2 at 20150908
Facebookのエンジニアも登壇！「React.js meetup #2」イベントレポート | Goodpatch Blog
こんにちは。グッドパッチのフロントエンドエンジニア/グロースデザイナーの右寺です。 今回は、9/8(火)にイベント＆コミュニティスペース dots.で行われたイベント「React.js meetup #2」のレポートをお届けします！ React.jsとは？ React.jsはFacebook謹製のJavaScriptライブラリです。一昨年のリリースから急激に人気が上昇しています。 その特徴は、同じJavaScriptライブラリであるAngularJSがMVCフレームワークとして全般的な機能を提供するのに対し、React.jsではMVCのViewにあたる部分をComponentとして提供することに特化している、と言えます。 現在、React.jsはFacebook社内だけではなくYahoo!やTwitter、Airbnbなどでも採用されているようです。 主催のお二人 今回のイベントは、昨年末
ES7 Decoratorでresizeイベントをいい感じに処理してくれるパッケージ作ったよ - Qiita
class Example extends React.Component { constructor (props) { super(props); this._onWindowResize = this.onWindowResize.bind(this) this.setState({ height: 0, width: 0 }) } render () { let {width, height} = this.state; return <div {...this.props} style={{ width, height }} />; } onWindowResize () { this.setState({ height: window.innerHeight, width: window.innerWidth }); } componentDidMount () { windo
Aerotwist - React + Performance = ?
3 July 2015 React is very popular at the moment, and I can see why: its developer ergonomics are very attractive. JSX and vDOM are really nice to work with, and it certainly enables composability. But, being the performance-minded person that I am, I wanted to test the claims that it's default-fast. 15 min Read Time #react #performance Share Update 7/3/15: I failed to use the minified version of R
俺の最近のRailsのJS開発環境を教えてやる - Qiita
こうやってるだけでも出力されたhtmlにはscriptタグが30個ぐらいならんでて、ページの読み込みに10sec以上かかる。 だけど、単にapp/assets/javascriptsをgulp watchとかはしたくない。 なぜならビルドはブラウザのリロード時に変更がある場合だけして欲しかった。 あとwindow.AppNamespace以下にモジュール追加していくのも辛い。 モジュール同士の依存関係もよくわかんないし、何よりwindow.AppNamespace.Modules.UserList.ItemViewとか長すぎ！ browserify-railsってやつ使ってみた browserifyがrailsの仕組みの中で動くようになる。 browserify-rails/browserify-rails https://github.com/browserify-rails/brows
react/fluxでpropsのバケツリレーを避ける - Qiita
reactにfluxを採用してアプリケーションを設計していると、親->子->孫コンポーネントへpropsのバケツリレーになってしまう事がありました。 そもそもイケてない設計が悪いのですが、reactバケツリレーつらいという声を聞くことも多かったし、自分も辛いと思っていたところ助言をいただいて解決法が見えてきたのでまとめてみます。 propsバケツリレー まず、バケツリレーを再現してみます。 DOM構造 おおまかにdiv[class="app"](親), div[class="group"](子）, div[class="item"](孫)というツリー構造になってます。 <div class="app"><!--親--> <div class="group"><!--子--> <h2>1番目のグループ</h2> <p class="count">13</p> <div class="item
コンポーネント指向による、Reactのベストプラクティスとバッドプラクティス
2015/05/27にLINE社で行われた、Data Binding JS Nightでの発表内容です。
Private Presentation
Private content!This content has been marked as private by the uploader.
React 雑感 - Qiita
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 を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄
React.js 実戦投入への道 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近話題のReact.jsですが、実戦投入に当たっては結構重たい選択を迫られることになります。 ざっくり言えば、テンプレートエンジンを捨ててReactしますか?それともReactあきらめますか?という選択です。 本記事ではReactの基本思想とこうした選択肢が生まれてしまう背景を述べるとともに、後半では「どちらもあきらめない」という(若干シミュレーションRPGあるある感のある)第三の方策について案を提示します。 Reactの基本 最初に、Reactの基本的な仕組みについてまとめておきます。 Reactは公式ドキュメントが非常に充実してい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - enzymejs/enzyme: JavaScript Testing utilities for React
The state of React.js 2016
React for Designers
FluxでCUIアプリ
Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 - Ginza.rb #26
mercury/mithril.js
