hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

Reactのドキュメント眺める

きのうチュートリアルやってみたので,ドキュメントなど眺めてみる.
自分用のメモなので読んでもメリットなさそう.

Why did we build React? | React

  • Reactは viewを作るもの reusable UI Component
  • canvasに書き込んだり,Backbone.Routerとくみあわせてペライチ作ったり,サーバー上でも動いたり
  • Reactと同じ考え方で,iOS用のViewなども作れる

A JavaScript library for building user interfaces | React

  • コード例書き換えて遊べる
  • タイマーの例,this.intervalとかしてるけどバッティングしないのか?
    • console.logすると,props, state,..に混ざって,tick, interval,とかいた
    • ふつうにメソッド作ってもバッティングするはずで,気をつかってよける?
<input onChange={this.onChange} value={this.state.text} />
  • getInitialStateはフレームワーク側で用意されているメソッド
  • valueの設定はブラウザがおこなったあと,onChangeでsetStateして,Reactがさらに設定している?? ↓ にしたら入力した文字が倍になった
   this.setState({text: e.target.value + e.target.value});

Why React? | React

  • シンプル宣言的,composable,まずは5分ください,もっと学びましょう
    • ほんとうに再利用できるのか??

Displaying Data | React

  • script type=text/babel
  • reactive update
    • 内部的なモックのDOMと比較して効率よくDOM操作してくれる
  • inputをpropsと呼ぶ.property.component内ではimmutableだから書き込んではいけない
    • なんか言語的な制約はないのか?
  • JSX
    • テンプレートとディスプレイロジックは入り組んでおり複雑になる
    • JSのコードから直接HTMLやコンポーネントのtreeを出力するのがベスト
    • (そのむかしE4Xとかあった気がする)
    • React.createElement('a', {href: 'https://facebook.github.io/react/'}, 'Hello!') = Hello!
    • JSXいらなければ使わなくてもよい

JSX in Depth | React

  • JSXはXMLのように見えるシンタックスの拡張
  • デザイナーのようなカジュアルなデベロッパに向いている
  • JavaScriptの意味は変えない
  • HTML Tags vs React Component
    • HTMLタグは小文字から,React Componentは大文字から
  • classとforは予約語なのでclassNameとhtmlFor
  • displayNameがundefinedなとき,代入される変数名からdisplayNameが自動的に決まる.var Nav = React.createClass({ }); で displayName='Nav'になる
  • コンポーネントにネームスペース使える
  • 式を書くには "" のかわりに {}
    • きのう "{ }"して文字列になってた
  • disabled で true disabled={false} でfalse
  • コメントは{/* */}

JSX Spread Attributes | React

  • プロパティのわたしかた
  • あとからprops代入してはいけない
  • props = {}; で全部渡せる 上書きするには

JSX Gotchas | React

  • JSXとHTMLとの違い
  • XSS対策されるので,{' '}の中に& middot; とかHTMLエンティティ書いてもそのまま出てくる.UTF8で直接書くか,\u で書くか,String.fromCharCode
    • まあわかりそう デザイナーの人が書くとき混乱しそう?
  • 仕様的に存在しないattributeを渡しても無視される.data- か, aria- は許可されている

Interactivity and Dynamic UIs | React

  • インタラクティブなUI
  • クリックでトグルする例.onClick={this.handleClick}.handleClickでsetState({liked: !this.state.liked}); renderでlikedかどうかで分岐
  • React.initializeTouchEvents(true)で電話やタブレット対応
    • 常にやっておけばよさそう??
  • それぞれのelementにイベントリスナをattachしているわけではなくて,トップレベルで単一のイベントリスナが監視している.速い.
  • setState(data, callback)はマージする.
    • state = {a, b} のとき setState({b}) しても,{a, b}のまま,ということ?あとで試す → そのとおりだった
  • ほとんどのcomponentは単にpropsを受け取って描画するべき.ユーザーの入力や,サーバーへのリクエスト,時間の経過などに反応するとき,stateを使う.
  • componentのうち可能である限りはstatelessにしましょう(try to...って書かれてる)
  • いくつかのstatelsssなcomponentと,ひとつのstatefulなcomponentを作り,statefulなcomponentがstateをstatelessな子供達にpropsで渡していく,というよくあるパターン
  • その状態を表す最小の表現を考えてstateに入れましょう.計算済みのデータをstateに入れることは,Reactが計算してくれるかわりに,自分でデータを同期することを意味している.render内で計算しましょう.
  • listItems.lengthをstateに入れるかわりに,renderで.lengthを呼びましょう
  • React componentsをstateに入れてはいけない.renderでbuildしましょう
    • 毎回作っていいの? ← keyをつけとけば大丈夫?
  • propsからコピーしたデータを入れてはいけない.ただし,propsの前回の値を知るためには,propsをstateに取っておいてもよい.

Multiple Components | React

  • composabilityについて.複数の部品を組み立てて使える.
  • facebookのプロフィール画像と名前を表示する例.AvatarがProfilePicとProfileLinkを使う
  • owner
    • Avatarがowner.他のcomponentのpropsを設定する役
    • owner, ownee
  • children
    • 親子の参照.this.props.children
  • ダイナミックなchildren
    • keyを使える.
    • Componentをrenderするまで分からないのはいけない.propsでkey=を渡すのが正しい.
  • ownerからowned componentに1方向でデータが流れる
  • パフォーマンスについて.DOM操作が遅いのであって,JSが遅いわけではない.本当になんとかしたいときはshouldComponentUpdateをオーバーライドする.

Reusable Components | React

  • prop Validation propTypesを使ってバリデーションできる
    • React.PropTypes.以下にいろいろ バリデーションの関数も書ける.return new Error('Validation failed!');.throwしてはいけない.
  • getDefaultPropsでデフォルトのprops返せる.一部のpropsが来てたときは,setStateしたときと同様にこれもマージされる??
  • {...this.props} でそのまま渡せる
  • mixinできる
  • ES6 Classes
    • class HelloMessage extends React.Component { でextend
    • getInitialStateのかわりにconstructorでthis.state = で指定
    • propTypes, defaultPropsもあとから代入
    • バインドしてくれないので,.bind(this) か =>
    • ES6にはmixinまだない
      • 助かった

Transferring Props | React

  • propsの転送のよくあるパターン
  • いろいろあってムズい var { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 };

Forms | React

  • input, textarea, option は入力取れるようになんかなってる
    • inputとtextareaはvalue,
    • input[type=checkbox]とradioはchecked
    • optionはselected
  • valueつきのinputはcontrolled component.input value="Hello!"するとユーザーが何を入力してもReactがrenderするさいに書き換えてしまう(ひどい).stateにvalue: Hello! とか入れておいて,onChange={this.handleChange}して,this.setState({value: event.target.value})とかする(めんどう).バリデーションもこれでできる(便利).
  • valueがないやつはuncontrolled component.ふつうに書ける.onChangeでlistenする.defaultValue="Hello!"でデフォルト値入れつつ自由に編集できる.
  • ほかには,inputはdefaultChecked, selectはdefaultValue
  • textareaもchildrenじゃなくてvalueを使おう
  • ↓こんなのもできる
<select multiple={true} value={['B', 'C']}>

Working With the Browser | React

  • the virtual dom
    • DOMを直接触らないので速い
    • イベントも実装してるので,IE8でもHTML5のイベント使える!!
    • jQueryプラグインなど,外界とやりとりしたいこともある.そういうときに脱出用のハッチを用意している.
  • React.findDOMNode(component)でDOMノード取れる
  • React.findDOMNode(this.refs.myTextInput).focus();
  • ライフサイクル
    • Mounting→Updating→Unmounting
    • willとdid
    • 呼べるメソッドいろいろ
  • polyfillは用意してないのでほしかったら適当に入れてね
  • IE8の話題あるけど無視

More About Refs | React

  • refsについて
  • ときにはfocusしたいこともある
  • renderの返すcomponentを保持しても意味ない
  • ref="myInput" で this.refs.myInputで参照できる.React.findDOMNode(this.refs.myInput)で実際のDOM
  • ref={(c) => this._input = c} みたいにコールバック書いて保持することもできる.mountされたあとに実行される. (ref=で名前書くほうが健全なかんじがする)
  • this.setStateのコールバックでfocusとか
  • publicなメソッドを用意しておいてrefsで拾ってきて呼ぶとか
  • render内でrefs呼んではいけない

Tooling Integration | React

  • CDNある
  • ブラウザで動くtransformerある.script type=text/babelをコンパイルしてくれる
  • npm使ってたらBabelで先にコンパイルできる
    • プロダクションではこっち.JSX形式でcomponentとか作ってるのがReadt.createElementに展開される.

Add-ons | React

アドオンいろいろ(ひとまず読み飛ばす アニメーションやテストなど)

Top-Level API | React

  • クラス作ったり,エレメント作ったり,renderしたり
  • initializeTouchEvents みたいなのが生えてるのが意外 もっと高尚な感じかと思ってた

Component API | React

  • this.state直接いじってはいけない.setStateしましょう

Component Specs and Lifecycle | React

  • render()関数は副作用があってはいけない.ブラウザとインタラクションしたかったらcomponentDidMountを使う
  • ↑で気になってたgetInitialStateはここで出てきた
  • mixinしてbehaviorを変えられる(すごいけどたいへんそう)
  • willとdidみたいな感じが英語っぽい
  • propsとstateの違いは? propsはimmutableで,stateはmutable? componentWillReceivePropsがあるということは,ライフサイクル中にpropsが変わることもあるのだとしたらstateとの違いは?

Tags and Attributes | React

  • SyntheticEvent,クロスブラウザの対応のためにwrapしてくれる
  • ここにあるtagやattributeが使える

Event System | React

  • dataTransferとかClipboardEventとかもここで用意されてる
  • ということは,今後新しいイベントがブラウザで使えるようになって,実際に使えるまでは,Reactでサポートされるまで待つ必要がある?

DOM Differences | React

  • attributeはcamelCaseだけど,data-はlower-case only.
  • styleはJavaScript Objectがよい(XSS対策)
  • onChangeは,一般的なブラウザ(blurすると発行)とちがって,リアルタイムに送られる(詳しくはformのページ見てね)

Special Non-DOM Attributes | React

  • ふつうのDOMには存在しないattributeをいくつか追加してる
  • key: unique identifier
  • ref: more-about-refsを見ましょう
  • dangerouslySetInnerHTML: TIPSみましょう

Reconciliation | React

  • diffをとるアルゴリズムについて レーベンシュタイン距離O(n^2),keyをつけてO(n)

React (Virtual) DOM Terminology | React

  • ReactElement
    • type, props, key, ref
    • ReactElementは軽く,statelessで,virtualなエレメン
    • JSXなら< >で作れる
  • Factory
    • React.createElement.bind(null, type).divとか作りやすい.JSX書いれば使う必要ない
  • ReactNode
    • ReactElement, string, number, Array のいずれか
  • ReactComponent / ReactComponent Class
    • 単なるJavaScriptのクラス.少なくともrenderメソッドを持っている.
    • 自分でnewして呼ぶことはないでしょう.React.createElement(MyComponent) もしくは

Advanced Performance | React

  • パフォーマンスについて
  • shouldComponentUpdate オブジェクトの中身も比較するとたいへん
  • オブジェクト同士の比較だと,オブジェクトは同じで,中身だけ変わってることがあってよくない
  • immutable.jsについて y = x.set('foo', 'baz') とか イミュータブル!!
  • deep compareしないので速い
  • immutable-jsとFluxについて Fluxにするならまずimmutable-jsでstoreしよう APIはこちら
  • this.messages = Immutable.List(); して this.messages = this.messages.push(new Message({timestamp: payload.timestamp...})); immutableなので変数で受ける

感想

  • だいたい分かってきた気がする(合ってるかどうかは知らない)
  • renderでvirtual DOM作って返すだけで考えるの少なくて手軽
  • querySelectorとかで取ってきたり,イベントハンドラセットしなおしたり,とかいらないので楽そう
  • Reactはたんなるviewなので,シングルページアプリケーションとか作りたかったら,ほかに状態を管理するやつがほしそう Backboneのなんかと組み合わせるとか書いてあった
  • 裏側のモデルはこれまで通りていねいに作る必要がありそう viewが分離できるのはスッキリしそう
  • デザイナーの人といっしょに作ってるとき,素のHTMLとは似てるけど微妙にちがうのでむずかしそう *.jsを触るのは抵抗があるかもしれない
  • ↓の本注文して明日くらいに届くはずなので読む

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

  • 作者: Frankie Bagnardi,Jonathan Beebe,Richard Feldman,Tom Hallett,Simon HØjberg,Karl Mikkelsen,宮崎空
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2015/04/03
  • メディア: 大型本
  • この商品を含むブログ (2件) を見る

Reactチュートリアルやった

最近Reactというのが流行ってるらしいのでチュートリアルやってみた.

facebook.github.io


最初は順調だったけど,まちがってauthor="{comment.author}"って書いてて,しばらくこの状態だった.

f:id:hitode909:20150928204326p:plain

上の書き方は間違いで,author={comment.author}が正しい.


完成して,コメント書けるようになった.手抜きでサーバー側は実装してない.

f:id:hitode909:20150928205601g:plain


なんとなく最近できたものというイメージだったけど,もう2年以上もあった.

facebook.github.io


同じ日に僕はパソコンにシール貼るとべたべたして嫌とか書いてた.差を感じる.

hitode909.hatenablog.com


サンプルコードそのまま真似して書いてみると,手軽な雰囲気だった.
エラーメッセージもていねいで,ここがおかしいぞ^^^って教えてくれたり,ソースマップが有効になってるのか,.jsxのファイルをそのまま見てデバッグとかできた.
例では,コメントボックスをこのようにコンポーネント分けてるけど,やってみようとすると,きれいに切り分けるのは難しそう.誰が書いても同じになるのか,人によってモデリングの仕方がちがうのか,とか気になる.これまではフレームワークあまり使ったことがなくて,こんなもんでしょって手で分けてた.
予想では,人によってモデリングの仕方はちがいそうだけど,原則やプラクティスはありそう.
stateの中身がそれぞれ独立したものならコンポーネントを分けるべきなのか(オブジェクト思考的には,それぞれ関係のないデータをインスンスに持ってたら,クラスごと分けてコンパクトにすることが多いと思う),render対象のDOMに対応した構造を取るのがよいのか,とか.
次に読むべき情報知りたいので教えてください.あとこの本どうだったか教えてください.

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

  • 作者: Frankie Bagnardi,Jonathan Beebe,Richard Feldman,Tom Hallett,Simon HØjberg,Karl Mikkelsen,宮崎空
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2015/04/03
  • メディア: 大型本
  • この商品を含むブログ (2件) を見る

追記

上の本良いって刺身さんに教えていただいたので買いました.

Reactチュートリアルやった - hitode909の日記

買っても読んでもない本でアフィ貼る勇気。

2015/09/29 11:39
b.hatena.ne.jp

ひどいソフトウェア作りたくなくて考えること

ソフトウェア作ってるとどうしようもないひどい状況になったり、知らないプロダクトを読んだらひどい状況になってたりすることがあって、どんなときにそういうことになるのか、必ずそうなるのか、そうなることを予見できないか、完成したソフトウェアを見てひどいかどうか判定できるか、とか気になってる。

  • 作ってる途中に気付けないものか 
  • 作る前に気づけることはあるか
  • ひどいのは分かってるけどやるしかないときにだけひどいものができるのか
  • 時間はあるけどやる気がないとそうなるのか
  • プライベートでなんかあるとそうなるのか
  • 書いてから時間が経つと大体のものはそうなるのか
  • コードは正しくて読者が使われてるパターンに理解がないだけなのか
  • パターンの使い方が変だと読めなくなるのか
  • 当時と環境、社会情勢や実行環境、データ量、などが変わってひどくなるのか
  • いい技術が発明される前なのでしかたないのか
  • いい技術が発明されたときにキャッチアップすべきかどうかの見極め
  • 作りかけで置いてあって負債とは認識されてたけど引き継がれていないとひどくなるのか
  • ドキュメントがあればよくなるのか
  • ユビキタス言語を話すチームが解散すると後から来たユビキタス言語知らない人が独学で理解するのは不可能なのか
  • 合わせ技でひどくなるのか
  • 程度の問題なのか
  • 程度は定量的に決められるのか
  • ひどさの定義について
  • 適切なソフトウェアのメトリクス測っていれば気づけるものなのか
  • そのメトリクスは既知のものなのか、まだ発見されてないけど実は何かあるのか、誰も気にしてないのか、研究中なのか
  • 客観的にひどいのか主観的に好みに合わないだけなのか
  • これまで動いてくれたソフトウェアに対する感謝の心を忘れてはならないのか
  • コードがピヨピヨしてるね
  • プロジェクトの初期は理想的な状態だったのか
  • プロジェクトの初期が理想的な状態ならそこまで戻して書き直せばよいのか
  • 設計からそもそも間違っているのか
  • どのレイヤがおかしいのか知る術はあるのか
  • 一部の機能だけがひどいのか全体的にひどいのか
  • コアドメインがひどいとき助かる余地はあるのか
  • コアドメイン以外なら柵で囲って触らないで、で済むのか
  • フルスクラッチしたほうが早いことはあるのか
  • 何やってるか理解できないものをフルスクラッチできるのか
  • ある程度の制約を設ければ決してひどいことにはならない、みたいな制約はないのか
  • 知られたフレームワークの最新を追いかけていればどれだけ改善されるのか
  • フレームワーク入れることで状況が悪化することはあるか
  • 良いフレームワークの見極め方
  • フレームワークから脱出した事例、手作業なのか、マイグレーションできるのか
  • プロジェクトを続ける期間によって差はあるか
  • プロジェクトの成長の規模を予想して最初から適切な複雑度で作ることはできるか
  • 期間によって差があるとしたら、サービス終了までの期間を予測できるか
  • 過去のデータから、コードが退役するまでの期間を予測するモデルを作れるか
  • 住宅のCMとか見てると100年安心とか言ってるけど自信はどこから来るのか
  • n年後も動かし続けるために必要なことは何か
とか気になってる。いくつかはさっと答えられそうだけど、答えられないこともありそう。