You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
2010年代に入ってから、フロントエンドのJavascriptライブラリの群雄割拠でキャッチアップが大変ですが、どれも概念と設計が工夫されていて使っていて楽しいです。 jQueryのDOM操作はなんでもできるけど、やっているうちにDOMをちょこちょこ変更したり、何かの値を無理やりDOMのdata属性にもたせたり、コールバックをあちこちに書いたりして訳が分からなくなってきたりしますからね。 Backbone.jsが出てきてMVCを実現させてみて世間をあっと言わせたかと思えば、Angular.jsがこれだけで大抵のことはなんでもできるフルスタックなフレームワークとして登場してさらに便利になったり。 他にもKnockout.jsとかvue.jsとかいろいろありました。 Reactが登場してから、流れがReactに傾いている（使用する案件が増えている）気がします。 ReactはUIのためのフレーム
さて、今回はアプリを書くほうのエンジニアにとっては一番大事なスキーマ設計について学んだことをまとめていこう。ここはユーザが増えるにつれて全てのエンジニアが直面する部分なので、予めそれらを予見してスキーマを設計できるようになる必要がある。 正規化と非正規化 ここがMongoDBにおいて最も悩む部分だ。どれをEmbed Document にして、どれをReference にするか、だ。これはそのアプリケーションの特性によってどちらかにするかをアプリエンジニア自身が決定しなければならない。腕の見せ所だ。 ただ、それがしっかりと理解していれば割と簡単に決められる基準はある。 Embed Document References 小さなサブドキュメント 大きなサブドキュメント 頻繁なデータ更新が無い 変わりやすいデータ データ更新に時間がかかってもいい 一瞬のデータ反映が必要 データの増え方が小さい
（どちらの例もnormalizrから拝借しています。） normalizrとは？って話はすでに良き記事が出てるのでそっちとか本家のReadmeとかReduxのDocとか読んで頂ければと Normalizrを使用したReduxの実装パターン 正規化されたデータはネスト構造が浅くなり、正規化以前にネストされてたデータへの参照(id)を持っています。 RDBの設計に似てると思います。 正規化されたデータの方が、書き換えが容易で、変更が多いデータに向いています。 CQRS的には redux stateはCQRSで言うところのコマンドモデル(writeモデル)となります。 コマンドモデルを書き換えるとsubが反応してクエリモデルを書き換えます。 クエリモデルどこいった？ 「reselectにメモ化されたキャッシュ」がreduxにおけるクエリモデルに当たるかと思います。 reselectは本家でも紹介
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
