フロントエンドGUIの状態の整理 - しゅみは人間の分析です
昨日の🍺のあとに考えていた雑感。フロントエンドから見たGUIの状態を個人の主観をもとに整理しています。 背景 複雑なJavaScriptアプリケーションを考えながら作る話 と id:Pasta-K がReact + Canvasで色々やっていた話 などなど。 Reactなどの現代フロントエンドはたいへんしんどいGUIであるという前提もあります。 GUIの状態の種類 人間 諸悪の根源。 だいたいこいつが状態を変更してくる。バリデーションが必要なのもこいつのせい。 わかりやすいUIを提供しないと人間が弱る。 View Viewの中の状態。UI上の選択状態とか。 Viewに状態を持ちたくない宗派としては、できれば非永続化層（メインのビジネスロジックと状態を持った層）か永続化層（DB）にすべての状態を持っていて欲しいが、パフォーマンス上の問題でthis.stateに状態を持つことはありえる。Re
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
橋本商会 » React+Fluxxor+socket.ioでfluxなチャットを作った
fluxxorとsocket.ioを使ってチャットを作った。大変ミニマムな感じの実装を心がけてて、今後何かWebアプリを作る時はこれを少し組み替えて作るぞというのを意識してる。ようするに低機能最低限でしょぼい。サーバー側はexpressとmongodb。 https://github.com/shokai/node-flux-boilerplate herokuでも動く https://node-flux-boilerplate.herokuapp.com/ クライアントはこんな実装 Fluxアーキテクチャ Reactはなんとなくわかってfluxをやるか、と思ったらflux npmの中がdispatcherしかなかった。 flux.DispatcherのwaitForの実装 まずこのへんを読んでフムフムなるほど（わかったようなわからないような）となる。 Flux | Application
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
