無職です。はたらいてます。 旧ブログ: 1 Entry per Day

Google Assistantのルーティン機能が最高だった

もともと、帰宅して「ただいま」と言ったらエアコンやら証明やら一括で電源を入れるようにしたかったんですが、いつの間にか公式でサポートしていてやったぜ!という感じです。

しかし、Nature Remoで制御しているエアコンについてGoogle Assistantの設定画面では「OFFにする」という指定ができないようでした。 ですが、「エアコンを消して」といったボイスコマンドをそのまま指定できるので代替できます。

WEB+DB PRESSの仮想DOM記事を読んでの感想やらなんやら

WEB+DB PRESS Vol.106の「仮想DOM革命」という記事を読んでの感想やらなんやら

gihyo.jp


これまでほぼAngularしか触ってなかったんですが(jQueryとかモダンでない旧世代以前のあれやこれやは除く)、そろそろReact触ることになりそうなので勉強しようとしていたら、WEB+DB PRESS Vol.106に「仮想DOM革命」という記事が載っていたので、早速買って読みました。

以下、著者の意図とは違うだろうけど、自分的に良かった点について。

Reactのよくわからんかった部分がわかった

Reactはほとんど触ったことがなくて、去年のDroidKaigiのサイトがReactベースのGatsbyだったので、少々触ったくらいでした。

仮想DOMがどうやって何を実現してくれるのか、ReactにおいてProps/Stateの立ち位置・使い方は何なのかがわかったのが、この記事を読んでの俺的な一番の収穫でした。

Angularと比較してどう違うのかがわかった(気になった)

(Angularについてはv2の頃に調べた話が元なので今は違うかも)

Reactでは仮想DOMによって差分のみをDOMに適用する一方、Angularでは変更を検知したプロパティを使用しているテンプレート中の該当部のDOM操作を行います。

つまり、コンポーネントが複雑になってもDOMに適用するのはあくまでその差分だけなReactに対して、テンプレートに記述したロジックをDOMにそのまま反映していくAngularの違いがあります。 特にAngularではAOTコンパイルでテンプレートをTypeScriptのコードにすることもあり、テンプレート書くときもJavaScriptとしてのパフォーマンスを考慮しながら書いたりする必要があると思ってます。

Angularの方はコンポーネントCSSカプセル化を最初からやっているとかプロパティの双方向バインディングがあるとかいう違いもありますが、フロントエンドのフレームワークで一番パフォーマンスに影響が出るDOM操作周りの振る舞いの違いは重要です。

React-Redux勉強メモ

近くReact+Reduxを触るのでとりあえずざっとQiitaの記事あたりを読んでいったメモ。


概要

react-reduxはreactの各コンポーネントのprops/stateの変更をreduxにすべて委譲してしまう仕組み。 reactは個々のコンポーネントの描画とボタン押下時にどのactionを実行するか(dispatch)だけに注力する。 reduxはdispatchされたactionによってStateをどう変更するかをreducerで管理する。 Stateの変更によるコンポーネントへの反映はreact-reduxのconnect関数とProviderによって実現する。

connectとかProvider

react-reduxの場合、Reactのコンポーネントを直接使わずconnectでwrapしたconnected componentを使う。 connected componentはactionを経由して行われたStateの変更を引き受けて再描画される。 正確に言うとそれだけでは動かなくて、Providerというreact-reduxのコンポーネントが親になっていてそこでStoreと繋ぐ。

const store = createStore(reducer)
render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
)

Action

Actionは単純なJavaScriptのオブジェクトに過ぎない。 typeプロパティを持つという制約があるだけ。↓のpayloadというは任意の値を受け渡す場合の例であって別のプロパティ名などでも問題ない。

{ type: "アクションを一意に示す任意の文字列", payload: "アクションの引数" }

Action Creator

typeの値の定数とかコンポーネントから渡される引数をpayloadにマッピング薄い関数をAction Creatorと呼ぶ。

function actFoo(arg) {return {type: ACT_FOO, payload: arg}}

dispatch

dispatchとはAction Creatorを呼びつつRedux側にActionを実行させる部分。 個々のコンポーネント毎にどのActionをdispatchするかは指定しておく必要がある。 その記述は今は結構雑に書けるそうだ。 ↓の場合、HogeComponentのpropsにactFooとactBarをdispatchするだけの同名の関数が渡されるので、コンポーネント内のclickイベントなどでそれを実行するようにしておくだけでよい。

export default connect(
    // mapStateToProps
    state => ({ value: state.value }),
    // mapDispatchToProps 
   { actFoo, actBar } // connectの第2引数にAction Creatorを纏めたオブジェクトを渡す
)(HogeComponent)

Container

実際には個々のコンポーネントごとにconnectしておくのではなく、ネストの親コンポーネントでだけconnectしておいたりすることがある。 それをContainerと呼ぶ。

StoreとReducerの分割

ReduxではStateを管理するStoreは基本的に1つだけにする。 そのStoreでactionを処理するReducerも1つにすることになる。 しかし、大きなアプリケーションだと1つのReducerになんでもかんでも突っ込むのはヤバイので、実際にはStateのプロパティごとにReducerを作り、それを纏めたReducerを使う。 その際は、分割した個々のReducerを自前で書いてcombineReducersというヘルパ関数でガッチャンコする。

function fooReducer(state = initialState, action){
    /* Stateのfooプロパティを扱うReducer */
}
function barReducer(state = initialState, action){
    /* Stateのbarプロパティを扱うReducer */
}
export default combineReducers({
    foo: fooReducer,
    bar: barReducer,
})

combineReducersを使わずに自前で分割するのも出来るっちゃ出来るがcombineReducers使った方が無難そう。

export default reducer(state = {}, action) {
  return {
    foo: fooReducer(state.foo, action),
    bar: barReducer(state.bar, action),
  }
}

Reducerは分割出来るがStateはあくまでもアプリ全体で1つだけであることを忘れずに。 上記の例ではReducer側ではfooやbarという単位で扱っているが、コンポーネント側ではあくまでfooもbarも持つState全体が渡ってくるので、mapStateToPropsでは気をつける。

参考文献