タグ

Fluxとreactに関するko-ya-maのブックマーク (5)

  • クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog

    この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し

    クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
  • 10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。 - 日々、とんは語る。

    2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact

    10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。 - 日々、とんは語る。
  • redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita

    名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー

    redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
  • Ardaの設計指針と設計思想 - Qiita

    @armorik83 さんの記事を受けて Fluxフレームワーク Arda が気になる10の理由 - Qiita 設計思想とか指針とか残しておきます。 mizchi/arda Arda - MetaFluxなフレームワークを作った - Qiita Ardaは実践的なものを目指した 他のフレームワークは思想から入って実装されたものかもしれませんが、ArdaはFluxを意識しつつも実際のアプリで使われている画面遷移の機構を抽象化する点から開発がスタートしています。 またKobitoという比較的寿命が長い(ことを予定している)アプリの基盤にすることで長くメンテされる予定です。なのでKobitoはちゃんと使ってもらえるようなものにしたい、と思って開発しています。(この記事が宣伝兼ねてないとは言いませんが。) (自分の開発したものにしては)ドキュメントが充実していることについて 開発者の今回の様子に

    Ardaの設計指針と設計思想 - Qiita
  • Flux react現状確認会

    2. 前提となる適用先 • 管理画面的なWebアプリケーションのリニューアル …だったもの(仮) • REST APIを前提としたSingle Page Applicationもどき (※すべてが1ページではないけど) • 機能・画面が多い • 複雑化することがほぼ確実 3. Viewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること(含セキュリティリスク回避) (生DOM・jQueryはあり得ない) • 業界におけるパラダイムが過渡期のため、 巨大フレームワークに乗っかりたくは無い (交換可能な部品の組み合わせでプレーンに) • 困ってもなんとか出来るための緊急ハッチも必要

    Flux react現状確認会
    ko-ya-ma
    ko-ya-ma 2014/12/26
    ああ、これは良い資料。使いたいけど、まだ枯れてない&JQueryを併用したい勢力に納得できる解を提示できる算段が……
  • 1