【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し
Redux は 概念的に Rx のサブセットであるという話 - mizchi's blog
この資料のアレ。 mizchi.hatenablog.com Reducer は単なる (State, Action) => State の関数で、redux.combineReducers は複数の reducer を名前空間でマップした新しい reducer にするもの。 Rx分かる人、Redux分かる人向けに、 redux.combineReducers を実装して、Rx.Observable.scan で reducer として実際に動くコードを書いた。 const Rx = require('rx') const combineReducers = reducerMap => { const initialState = Object.entries( reducerMap ).reduce((acc, [key, reducer]) => { return Object.ass
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
markerikson - Repositories
