React 本体のみで Redux フレンドリーな非同期処理を実現するアイデア | Recruit Tech Blog
こんにちは。2019 年 10 月に join した kazuma1989 です。スタディサプリENGLISH の Web 版を担当するフロントエンドデベロッパーです。 今回は、React と Redux を用いたアーキテクチャーで問題になる 非同期処理 を扱うアイデアの一つをご紹介します。Redux フレンドリー と題したように、Redux でなくとも（useReducer や unstated-next でも）適用することができます。 アイデアを EffectComponent と名付けました。そもそも Redux において非同期処理の何が問題なのか、そして EffectComponent とは何か説明します。React Hooks と Redux についてある程度知っていることを前提とします。1)言語は TypeScript です。がんばらないで始める のがおすすめです Redux
あなたはReduxを必要としないかもしれない – You Might Not Need Redux by Dan Abramov | mae's blog
今回は、エンジニア向け読み物サービス「Mybridge」のMybridge AIがランク付けした2016年9月のReactに関する記事の1位だった記事を翻訳して紹介します。Reduxの作者Dan Abramov氏の記事です。内容は、簡単に言うと、「無理してReduxを使わなくてもいいよ」という話です。ただ、使わなくてもいい理由をReduxの特徴を挙げながら述べてくれているので、Reduxについての理解も深まる内容になっています。原文がだいぶフランクな感じで書かれているので、日本語に訳すのが少々難しく、わかりにくい部分もあるかと思いますが、是非読んでみてください。 当記事は、You Might Not Need Redux – Medium (Sep 20, 2016) by Dan Abramovを日本語に翻訳したものです。 人々はReduxを必要とする前からReduxを使おうとします。「
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
redux-thunkなのかredux-promiseなのかredux-sagaなのか、それともredux#bindActionCreatorsをやめるのか - Qiita
前提 ここで書くのはあくまで個人的な意見です。 react, reduxはどちらも使い方次第でフレームワークっぽくも使えるし、ただのツールとしても使える。だからreact, reduxを使ったフロントアーキテクチャはいくらでもあっていいと思う。 これはそのうちの一つを提案するものです。 とはいえ特別な実装方式を編み出したわけでは全然なくて、むしろ１周して出戻りしたかんじ。 結論 非同期処理をコンテナ(またはそこで使うモジュール)に書くだけ。 今は、非同期処理をするためのredux middlewareを使ってないです。 過去記事(react, redux周りのパッケージ選定とKPT[2016-05-27現在])にて、この辺についてもなんやかんやと言っているけど、今はthunkもpromiseもsagaも使っていない。その実装が凄くシンプルで気に入ってるので紹介します。 どうやるのか red
Redux っぽく Rx で実装しようとして結果的に Cycle.js に惹かれる話 - Qiita
はじめに Flux のような unidirectional なアーキテクチャに興味があって、評判のよいものに触ってみた感じです。 実際に業務でやってみたことはないので、ガチ勢の方から見たらまだまだ甘いと思われる点が多々あるかもしれません。 TL;DR (投稿から一日たって少し考えがまとまってきたので追記) Redux の印象 before 思想は分かりやすい (Three Principles) アプリケーションの状態 (state) を単一の store で管理 state は read-only (直接更新できない), 更新は action の発行を介して行う state を更新する reducer は純粋な関数 でも action.type で switch する書き方が好きになれない Rx で簡単に re-implement できるとのことなので、 switch なしで書けるように
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
