ＯＳＳユーザーのための勉強会＜ＯＳＳ Ｘ Ｕｓｅr Meeting＞＃１３ React.js
について昨日（２月１７日）きいてきたので、内容をメモメモ
■React.jsがなぜ素晴らしいのか
・自己紹介 IT芸人
・BackboneやAngularはどうもなじめず
prototype.js→JQuery→フレームワーク（Angular:2.0がもうすぐ、Backbone）
・前からきいたことはあったReactを年末に開始
Viewの上にさらに載せるのは・・・２階建てのＭＶＣ
シンプルな方法
・公式チュートリアルを一通り→すばらしい
・ＤＯＭ操作はなぜ難しいのか
ＤＯＭはどこからでも変更可能
ＤＯＭが状態を持っている
ＤＯＭとコードがなはれ杉
・もっと簡単にやろう
ＤＯＭを描き変えないで常にＨＴＭＬ全体を生成
EventListenerをやめてonXXXプロパティを使おう
ＨＴＭＬとJavascriptを１つにまとめる
→２０００年前半は普通だった
・サーバーサイド生成
クライアント
ブラウザ
サーバ
ＨＴＭＬ生成部（テンプレート）
画面を表示するための状態（テンプレート変数）
ロジック(コントローラー）
・React
クライアント
ブラウザ
ＨＴＭＬ生成部（テンプレート）
画面を表示するための状態（テンプレート変数）
クライアントロジック
サーバー
サーバーロジック
・１つ使えるのに画面全体変える
・Example
こーどぺんというサイトにある
Javascriptの中にＨＴＭＬが入っている
JSX
Reactは、Domから読むのでなく、状態変数から判断
・機能追加が簡単
・人間が状態の差分を管理していた
→ＨＴＭＬを常に再構成することで変数から生成
ロジックは変数の書き換え、
ビューは変数を見る
・でも
ＨＴＭＬ全体を描き変えると遅くない
ＣＳＳアニメーション使えないよね
実は日本語入力できないよね
→Virtual DOM
→差分を取ったところだけ書きかえる
・もっと技術的には
key
compornent
property
・さらに
componentで再利用可能な部品化
サーバーサイドレンダリング
もっと大きなアプリではFlux
ＡｎｄｒｏｉｄアプリはReactNative
・問題点
コードを書く人がＨＴＭＬも書く
既存のＪＳ部品が使えない（こともない）
特にTwitterWidgetとか外部JSは苦手
・Flux（ふらっくす：ぐらふＱＬとかもある）
考え方の名前（ＭＶCとかと一緒）
ReactではDataさえ変更すれば画面に反映される
・同じ考え方とツール（差分を取って画面書き換え）
・Yet another React.js
・React Native
（angular JS 2.0でも差分書き換えの思想？）
・まとめ
・サーバーサイドのようなシンプルな流れでAjaxを
・画面を描き変える時は常に前面書き換え
・Ｗｅｂはコンポーネントベースと相性がいい
・既存のjs.uiライブラリと同居は難しそう
→業務アプリでパラメーターをいじるものと、相性いい
Ｑ＆Ａ
・ＤａｔｅＰｉｃｋｅｒだめ？
→だめだけど、かわりにつかえるものがある
・Angular.jsをReact書きなおし
→Reactコンポーネントで
・ＨＴＭＬいっぱいかくよね
→コンポーネント
フォームのＨＴＭＬ→コンポーネント
リストのＨＴＭＬ→コンポーネント
のようにコンポーネントを組み合わせる
・画面の状態爆発は賛同、で、はやってない理由
→しりたいところ
Angularも１から２で、互換性？
■改善React道
・今日MaterialUIとかつかって、つくってきた
・自己紹介
・本日のテーマ
１年超のReact開発におけるわ私めの手法思想と改善の歴史をさらす
・そういえば、Reactって良いの？
いいと思う。ちゃんと動く。他のが好きなら、それもいい
あつい思いはない
・アーキテクチャの要点、かわるよね。そこで状況を共有
作ってるの「管理画面」
システム構成「ＪＳがアプリケーションすべて。全部ＪＳに入っている」
・ざっくりした特徴：とくちょうがある
・要件複雑化、生産性を落とさずに作る→メンテナンス性、拡張性
・チームの状況：
はじめ２人 やること多い。土台を築いていけば
今 ４人 アクロバティック→どう考えを共有するか
今後 ２～３人増える
アプリケーション複雑
gulpよりnpmスクリプトをたたくように
webパック buildははやい
Webサーバー ライブリロードＡＪＡXのクロスオリジン制限に引っ掛からないように
エディターwebストーム atom
ライブラリ IMMUTABLE.JS constわなのため
Lodash
時間処理系moment.js
Ａｐｐフレームワーク
React,ReactRouter,ReactBootstrap
・どう考えて作っていくか
サンプル
私的映画鑑賞履歴Ａｐｐ Movie Logger：映画１に対して監督１～０、俳優３人まで
TypeScript,MatrialUIつかってやりました
・Reactの話
同じポリシーの共有：Prop/PropTypesはちゃんと定義する
isrequiredをつける（ワーニング）
Stateの管理しかるべき場所で集中管理
巨大なState→分散する誘惑→改修するとき責任範囲わからなくなる
・コンポーネント共通化をやりすぎるな
メリットと同じくらい、リスクもある
・Reactがんばらせない
Viewに関することいろいろできる→頑張らせすぎると、コードも複雑になる
・Fluxまわり
Fluxをどうとらえるか
責務とスコープ
ReduxとかのFluxフレームワークは使っていない
Ｍｏｄｅｌの役割についてドメインオブジェクト１個に関するＡＰＩ提供
セッターメソッド、バリデーションメソッド
そもそものモデル導入の理由１
Viewの中でバリデーションを扱う：たいへん
→ステートに聞けばバリデーション完結にするように
型の解決（だれが変換かける）
集合を返すのか、１つの値を返すのかの分担
Ｍｏｄｅｌのライフサイクル
だれがさわってもいいよ
immutable.jsのrecord：propsと関係なく
スコープアクセス権
Ｑ＆Ａ
ＡＪＡＸは
スーパーエージェント、ライブラリ
Ｖｉｅｗのテスト
テストＵｔｉｌがＲｅａｃｔあり
について昨日（２月１７日）きいてきたので、内容をメモメモ
■React.jsがなぜ素晴らしいのか
・自己紹介 IT芸人
・BackboneやAngularはどうもなじめず
prototype.js→JQuery→フレームワーク（Angular:2.0がもうすぐ、Backbone）
・前からきいたことはあったReactを年末に開始
Viewの上にさらに載せるのは・・・２階建てのＭＶＣ
シンプルな方法
・公式チュートリアルを一通り→すばらしい
・ＤＯＭ操作はなぜ難しいのか
ＤＯＭはどこからでも変更可能
ＤＯＭが状態を持っている
ＤＯＭとコードがなはれ杉
・もっと簡単にやろう
ＤＯＭを描き変えないで常にＨＴＭＬ全体を生成
EventListenerをやめてonXXXプロパティを使おう
ＨＴＭＬとJavascriptを１つにまとめる
→２０００年前半は普通だった
・サーバーサイド生成
クライアント
ブラウザ
サーバ
ＨＴＭＬ生成部（テンプレート）
画面を表示するための状態（テンプレート変数）
ロジック(コントローラー）
・React
クライアント
ブラウザ
ＨＴＭＬ生成部（テンプレート）
画面を表示するための状態（テンプレート変数）
クライアントロジック
サーバー
サーバーロジック
・１つ使えるのに画面全体変える
・Example
こーどぺんというサイトにある
Javascriptの中にＨＴＭＬが入っている
JSX
Reactは、Domから読むのでなく、状態変数から判断
・機能追加が簡単
・人間が状態の差分を管理していた
→ＨＴＭＬを常に再構成することで変数から生成
ロジックは変数の書き換え、
ビューは変数を見る
・でも
ＨＴＭＬ全体を描き変えると遅くない
ＣＳＳアニメーション使えないよね
実は日本語入力できないよね
→Virtual DOM
→差分を取ったところだけ書きかえる
・もっと技術的には
key
compornent
property
・さらに
componentで再利用可能な部品化
サーバーサイドレンダリング
もっと大きなアプリではFlux
ＡｎｄｒｏｉｄアプリはReactNative
・問題点
コードを書く人がＨＴＭＬも書く
既存のＪＳ部品が使えない（こともない）
特にTwitterWidgetとか外部JSは苦手
・Flux（ふらっくす：ぐらふＱＬとかもある）
考え方の名前（ＭＶCとかと一緒）
ReactではDataさえ変更すれば画面に反映される
・同じ考え方とツール（差分を取って画面書き換え）
・Yet another React.js
・React Native
（angular JS 2.0でも差分書き換えの思想？）
・まとめ
・サーバーサイドのようなシンプルな流れでAjaxを
・画面を描き変える時は常に前面書き換え
・Ｗｅｂはコンポーネントベースと相性がいい
・既存のjs.uiライブラリと同居は難しそう
→業務アプリでパラメーターをいじるものと、相性いい
Ｑ＆Ａ
・ＤａｔｅＰｉｃｋｅｒだめ？
→だめだけど、かわりにつかえるものがある
・Angular.jsをReact書きなおし
→Reactコンポーネントで
・ＨＴＭＬいっぱいかくよね
→コンポーネント
フォームのＨＴＭＬ→コンポーネント
リストのＨＴＭＬ→コンポーネント
のようにコンポーネントを組み合わせる
・画面の状態爆発は賛同、で、はやってない理由
→しりたいところ
Angularも１から２で、互換性？
■改善React道
・今日MaterialUIとかつかって、つくってきた
・自己紹介
・本日のテーマ
１年超のReact開発におけるわ私めの手法思想と改善の歴史をさらす
・そういえば、Reactって良いの？
いいと思う。ちゃんと動く。他のが好きなら、それもいい
あつい思いはない
・アーキテクチャの要点、かわるよね。そこで状況を共有
作ってるの「管理画面」
システム構成「ＪＳがアプリケーションすべて。全部ＪＳに入っている」
・ざっくりした特徴：とくちょうがある
・要件複雑化、生産性を落とさずに作る→メンテナンス性、拡張性
・チームの状況：
はじめ２人 やること多い。土台を築いていけば
今 ４人 アクロバティック→どう考えを共有するか
今後 ２～３人増える
アプリケーション複雑
gulpよりnpmスクリプトをたたくように
webパック buildははやい
Webサーバー ライブリロードＡＪＡXのクロスオリジン制限に引っ掛からないように
エディターwebストーム atom
ライブラリ IMMUTABLE.JS constわなのため
Lodash
時間処理系moment.js
Ａｐｐフレームワーク
React,ReactRouter,ReactBootstrap
・どう考えて作っていくか
サンプル
私的映画鑑賞履歴Ａｐｐ Movie Logger：映画１に対して監督１～０、俳優３人まで
TypeScript,MatrialUIつかってやりました
・Reactの話
同じポリシーの共有：Prop/PropTypesはちゃんと定義する
isrequiredをつける（ワーニング）
Stateの管理しかるべき場所で集中管理
巨大なState→分散する誘惑→改修するとき責任範囲わからなくなる
・コンポーネント共通化をやりすぎるな
メリットと同じくらい、リスクもある
・Reactがんばらせない
Viewに関することいろいろできる→頑張らせすぎると、コードも複雑になる
・Fluxまわり
Fluxをどうとらえるか
責務とスコープ
ReduxとかのFluxフレームワークは使っていない
Ｍｏｄｅｌの役割についてドメインオブジェクト１個に関するＡＰＩ提供
セッターメソッド、バリデーションメソッド
そもそものモデル導入の理由１
Viewの中でバリデーションを扱う：たいへん
→ステートに聞けばバリデーション完結にするように
型の解決（だれが変換かける）
集合を返すのか、１つの値を返すのかの分担
Ｍｏｄｅｌのライフサイクル
だれがさわってもいいよ
immutable.jsのrecord：propsと関係なく
スコープアクセス権
Ｑ＆Ａ
ＡＪＡＸは
スーパーエージェント、ライブラリ
Ｖｉｅｗのテスト
テストＵｔｉｌがＲｅａｃｔあり
アクセス
トータル
ランキング
