宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita
この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと（技術的負債の抑制）ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論（ここでは「現代的な設計論」とよぶもの）です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む（ビジネスロジックの変更や追加に対
React使い必見！ Immutable.jsでReactはもっと良くなる | Wantedly Engineer Blog
Reactを導入して半年近くが経ちましたWantedlyでは、今年の初めからReact(+Redux)の導入に取り組み始めたので、気付けば半年近く立っていることになります。今自分がこの記事を書いているエディタから、Wantedly Adminのチケット画面まで、ある程度大きなアプリケーションを開発してきました。 そこで今回は、チームで継続的に開発していく過程で遭遇した問題と、それを解決するために導入したImmutable.jsについて紹介します。 増え続けるCallbackとAction、肥大化するStoreReactとセットで語られることが多いFluxアーキテクチャ。ここでは詳しい説明は省略しますが、とてもシンプルな考え方なので、チュートリアルなどで簡単に学ぶことができます。しかし、実際にチームで開発していくと、たしかに動いてはいるけど、綺麗とは言い難いコードが増えてしまいました。 Ac
React / Flux を実案件で使ってみた (2015/02/16 講演資料) - Qiita
2015/02/16 歌舞伎座.tech#6「VirtualDOMとReact」 自己紹介 Name : Takuto Wada github : twada twitter : t_wada hatena : t-wada TDD とライオンの人 power-assert の人 React / Flux を知ったきっかけ mizchi さんのエントリ (あなたがReactを使うべき理由) だったと思う 日本語の情報はほとんど無かったが、エッジ系の人たちが騒ぎ出した & 海外で圧倒的に事例が増え出したので興味を持った Rendr をつくった AirBnb が React を使い始めたことを知り、これは決定的だと思った React をどう勉強したか 公式ドキュメントとチュートリアルが充実している まず Tutorial をそのまま写経 次に browserify + babelify で T
The SoundCloud Client in React + Redux
Follow on FacebookIn the beginning of 2016 it was time for me to deep dive into the ReactJs world. I read tons of articles about React and its environment, especially Redux, so far. Several of my colleagues used it in side projects and on a theoretical level I could participate in the discussions. In my company we relied heavily on Angular 1 at this point. Since we are using it in a quite large co
Reactを使ったモジュラーCSS : CSS-in-JSとCSS Module | POSTD
Buffer のメンバーはReactが大好きで、フロントエンドの多くのコードベースを徐々にReactに移行させています。ReactにFluxを加えると、モジュラー形式の小さなアプリでできた複雑なプロダクトを構築するための、とても健全な方法になると思います。そこで、１つ１つの新しい小さなアプリと機能を、大規模な構造体に追加される、Reactの新しいブロックと考えます。 私は最近、このような新機能の１つに取り組んでいますが、React＋Fluxのアプリケーションを作るのがいかに簡単であるかと、その理由について、さらに夢中になってしまいました。Reactを使うと有意味なコンポーネントを集めてUIを宣言的に構築するのが楽になり、Fluxはその混成体に妥当なデータフローをもたらします。 複雑なアプリケーションを作るときに発生する課題について多くの考察がなされましたが、React＋Fluxの組み合わせ
webdesign-dackel.com - このウェブサイトは販売用です！ - webdesign dackel リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita
想定しているシチュエーション 非SPA環境で個別にマウントされるコンポーネントがそれぞれで小さくFluxするような環境。 SPAガッツリ組むのでないなら、Fluxフレームワークは不要だと思っていて、とは言えオレオレ構成も行き過ぎると害になる。 その辺のバランスをとって、次のような構成がいいのではないか、と考えてみた。 考え方 コンテナがEventEmitterを1つ保持する コンテナはEventEmitterの各種イベントをListenする コンテナはpropsとstateを区別して扱い、stateを更新する コンテナはコンポーネントを一つだけ描画する コンポーネントはpropsとして渡されたEventEmitterを発火させる コンポーネントはEventEmitterをListenしない コンポーネントはpropsのみ扱う コード // src/components/header.js
How to work as a Team
autoscale: true How to work as a Team 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 目的 新規でそこそこ複雑なウェブページを作る(アプリに近い) ある程度柔軟に拡張でき、メンテできるような設計にしたい 無難にReact + 何かでちゃんと設計して作っていきたい この設計部分をどう決めていくのかという話 現状 チームにReact/Flux/Reduxを触ったことがない人が多い どれが(主にView以外の設計)ベストかは分からない Flux的な部分の話 ものごとは変わる。 混乱は変わらない 混乱の原因 情報過多 情報不足 適切でない情報 上記の組み合わせ！ via P21 今日からはじめる情報設計 情報の共有 情報不足 そもそもReactなどを知らない人には知ってもらう必
自殺者統計チャート描画サイトをつくった際の気付き（React, React-Router, ちょっとRails） - Qiita
こんなかんじです 自殺を知る、自殺を考える::職業別の自殺者数を年度で並べて表示 自殺を知る、自殺を考える（トップページ） Reactまわり うすくやっていく 前回はRedux+Redux-Routerを使ってうまくコンテキストを分離できてよかったですね、ということになりました。 やりなおしRedux - Redux Routerでコンテキストをわけると楽になる - Qiita しかし、さあまたなにか作りましょうとなったときに、あのActionsやReducersやconnectを思いうかべただけでもういやになるという、どうしようもないめんどくささがあります。 というわけで、今回はReact の Context を使って Flux を実装する - Qiitaをほぼそのまま使うことにより作業を軽くすることができました。 Providerが各コンテキストの親分となり、自分が監視するemitte
React+Reduxのテスト方針をまとめた｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
概要 React.js Advent Calendar21日目の記事です。 Reduxというフレームワークがじわじわ広まっている。Reduxは、Fluxの概念を拡張したもので、アプリケーションでひとつの状態をもつと、クライアントでの状態管理がいろいろ便利になるよ、というコンセプトを持つ。詳細は以下の記事が詳しい。 人気のFluxフレームワークReduxをさわってみた - マルシテイアは月の上 Motivation | Redux 筆者は現在React+Reduxでアプリケーションをつくっているが、今回は、そのテスト方針を書こうと思う。 テスト環境 karma+jasmine+sinonでつくる。E2Eはいろいろと・・・なので・・・メインはユニットテストで実装している。JavaScript DOMをつかってSimulationすれば、最低限は担保できるかなと考える。 テスト方針 大きな方針と
Fluxで消耗するために自分でFluxフレームワークを作ってみた（Amamoriといいます） - タオルケット体操
場所 ギッハブにあります。 github.com 作った動機 Fluxフレームワーク、色々出てきては消えるしReduxとかが提唱されるしでもうわけわかめ。これからアタシ（のプロジェクト）、一体どーなっちゃうの〜〜？！ APIリファレンスみて色々と見比べてるだけの中途半端な知識だと、いざ自分が選んだフレームワークが死んだ時に潰しが利かない…… -> じゃあ一度自分で作ってみよう！ あと社内にFluxわかるマンがいなかったので、公開して広く世間の意見を求めたいという気持ちも強かった。なんかおかしいところあったら教えてくだされ〜〜〜 というわけで作った。 あとES6で書いたコードをnpmモジュールで公開する方法を知りたかったというのもある。 大変だったところ Fluxを実際に実装に落とし込める感じに理解するのが大変だった。 理解するために、Facebookの概念図をみたり、azu氏の実装（Git
fluxフレームワークreduxについてドキュメントを読んだメモ - fukajun - DeepValley -
この辺を読みながらfluxの各パーツの役割、reduxの登場人物について 自分のめもとしてまとめてみた http://rackt.github.io/redux/index.html reduxの思想 1つ情報源を正とする アプリケーションの状態は1つのstoreオブジェクトが管理する stateはリードオンリー 状態を変更する唯一の方法はactionを発行すること 状態の遷移はただの関数によって行う 状態を変更するための処理はreducersに定義する fluxの登場人物 actionCreator actionを作るための関数 ajaxリクエストなどの処理を行い、結果を含めたactionを作成する action アプリケーションで何が起きたのかとそれに付随するデータ nTypeと任意のデータを持つ単なるObject acitonCreatorによって作成されてdispacherに渡され
Fundamentals of Redux Course from Dan Abramov
In this comprehensive tutorial, Dan Abramov - the creator of Redux - will teach you how to manage state in your React application with Redux. State management is absolutely critical in providing users with a well-crafted experience with minimal bugs. It's also one of the hardest aspects of a modern front-end application to get right. Redux provides a solid, stable, and mature solution to managing
grails-react-boilerplate で React に入門した - 1日目 ホットリロード, React Bootstrap - bati11 の 日記
普段の仕事はサーバーサイドばっかりだったので、年末年始でフロントエンドの知識をアップデートしたいなぁ、ReactかVue.jsやろうかなぁと思ってました。それで、こちらの記事を読んでると... uehaj.hatenablog.com サーバサイドJavaをずっとやってきて、モダンなJSの知識や経験があまりないけど、最近Reactってのが話題になっているのがさすがに気になるので挑戦したい人 これは！Javaだけってわけじゃないけど、ずっとサーバーサイドってまさに自分のことじゃないか！ということでコードを読んでみることに。 リポジトリをcloneしてreact-appディレクトリを一旦削除して、react-appを自分でつくり直しながら学ぶことにしました。コード読んでみて分からないことが色々あったので、一歩一歩分からないところを潰しながらやっていきました。その時の備忘録です。サーバーサイドは
The Evolution of Flux Frameworks
There has been no shortage of great Flux implementations, such as Flummox, Alt, or Fluxible. Most of them are focused on making Flux easier to use with the server rendering and reducing the boilerplate. They also often provide convenience utilities like higher-order components and asynchronous action helpers. Still, under the hood, many of them are built on top of the original Flux Dispatcher. Red
reduxをプロジェクトで使ってみた感想 - Qiita
書こうと思った気持ち reduxをとあるプロジェクトで使ってみたのだが、redux自体の存在を知った今年の夏頃はv0.4.0とかだったのに、気がついたらv3にまで上がってくるくらいの発展途上な感じのライブラリでほとんどノウハウがなく死にそうな感じだったので、使ってみた知見を公開しようと思った。 選んだ理由 reactを使ってUIを作った話をこちらに書いた。react単体はJust UIなので、アプリのフレームワークとしてfacebookが高らかに提唱しているfluxアーキテクチャを使ってみようと思った。 flux自体はデータの流れを一方向に限定しよう、というアーキテクチャであり、何をするにもまずactionがトリガーとなり、そこからアプリの状態が変更され、UIはその状態に従って描画するだけである、という思想のアーキテクチャである。 自分の過去の経験から、UI実装では状態遷移周りではまること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
基礎からはじめるReact入門一覧
http://post.simplie.jp/posts/27
DDDBE #12 - ReactJS / Flux
