ウォーターセル株式会社の社内勉強会 https://water-cell.connpass.com/event/178648/ で発表したものです。 YouTube Liveアーカイブはこちら https://youtu.be/ZLUie-ndKgw
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =
ReactとReact Nativeでコードを共通化し,web / android / iOS (+PC)クロスデバイス開発ReactreactnativeElectronredux React, React Native, Reduxを使って,web, android, iOSアプリのコードを出来る限り共通化します. ReactとReduxを組み合わせて使う場合,見た目を司るPresentational componentとロジックを司るContainer componentにコードを分離します( http://qiita.com/tuttieee/items/a3ca7d9d415049d02d60 ). そこで,Presentational componentは各デバイス固有のコードにし,Container componentは共通化することでロジックをデバイス依存のコードから切り離
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか? たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
This article was peer reviewed by Vildan Softic. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be! I am one of those developers who likes to do things from scratch and get to know how everything works. Although I am aware of the (unnecessary) work I get myself into, it definitely helps me appreciate and understand what lies behind a specific framework, li
玉石混合状態にあったFluxのフレームワークも、ここ最近ではReduxが首一つ抜け出したような感じとなっています。自分はFacebook/Flux派ではありましたが、先月発売された『WEB+DB PRESS vol.92』に掲載されていた伊藤直也さんのReduxの記事を読んで、Reduxを覚えてみようという気になりました。Redux自体はとてもシンプルで、とっつきやすいと思いました。ただReactとの連携はFacebook/Fluxと比べるとややこしい部分が多いかなといった印象です。ちょっとしたサンプルを作ってみたので、Reduxの実装方法とReactとの連携について紹介したいと思います。 ReduxとはReduxは、Facebookの提唱するFluxアーキテクチャに基づいて(影響を受けて)設計されたJavaScriptフレームワークです。作者は@dan_abramov氏。 reactjs
【追記】 もうこれ古いから参考にしないでください https://t.co/mXtcc73Orf — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 Redux にはその昔 connect()() とかいうクソ API と, Redux-Saga とかいう宗教がありました という考古学です — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 読者対象 Tutorial: Intro To React - React Example: Todo List · Redux 「チュートリアルそれぞれ一周した!Reactは何とか理解できたが,Reduxがさっぱりわかんねぇ!」 ぐらいの人向け。自分
3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄を解消する。また結果的にテスタビリティを高める あたりだろうか。 React というと最初に目につくのは VirtualDOM だけれども、VirtualDOM は 1 や 3 を達成するために障害となった技術的課題を解消するためのテクニックであってそれ以上
Atomic Design is a methodology for building user interfaces that advocates designing in isolation at the individual component level before assembling them into pages. The document provides examples of React component code for an announcement item, a divider, and a check toggle that demonstrate how to build reusable UI elements at an atomic level and compose them to build interfaces. It also shows
最近は Flux + React を使っています。Secure Code Tipsでも部分的に採用しました。今回は Fluxアーキテクチャについて、現時点で自分の理解している内容をメモしておきます。 Fluxの概念図Flux: Actions and the Dispatcher | React というページでは以下の図が使用されています。よく見る図です。 現在の自分の認識を基にしてこの図をもう少し詳しくすると、以下になります(だいたいこんな感じという程度の図です)。 * Web API と Web API Utils は省略しています。 Web API と Web API UtilsAction Creators が保持しているメソッド内からAjaxリクエスト処理等を行う場合、その部分をこちらに切り出して使用します。Action Creators と ActionsAction何かしら新
This post is a non-exhaustive quick overview of the so-called “unidirectional data flow” architectures. Not meant to be taken as a beginner tutorial, but rather as an overview of their differences and peculiarities. At the end, I’ll introduce a new architecture which deviates significantly from the others. This post assumes client-side Web UI frameworks only. TERMINOLOGY It would be confusing to t
Reduxはとりあえず使えるようになった後の情報が少ないように感じています。よく出回っているサンプルコードは「Real World 〜」のような名前がついていたとしても、あくまで雰囲気を味わうために用意されたものに毛が生えた程度で、現実に起こる問題に対する回答や指針を示しているわけではありません。業務で使うことを検討するのであれば、プロダクトの成長と共にどうやってスケールしていくかイメージできないと導入に踏み切れないですよね。本稿ではサンプルコードより大きな規模で開発していくために、Reduxにおけるコンポーネントの再利用について紹介します。 実現したいこと コンポーネントの再利用によってどのようなことを実現したいのかイメージしてもらうため、馴染みのあるアプリケーションの機能を具体例として挙げてみます。 Gmailで名前にマウスオーバーしたときに出るプロフィール情報 プロフィール画像の表示
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く