TwitterやSlackのRedux Storeを覗く
{ domainData1 : {}, domainData2 : {}, appState1 : {}, appState2 : {}, ui : { uiState1 : {}, uiState2 : {}, } } ref: Basic Reducer Structure and State Shape · Redux 正規化 Recipesでは正規化についても言及しており、リレーショナルデータを管理する場合はデータベースのように正規化することを推奨していました。 以下は投稿が複数のコメントを持つ例です。postsはcommentsのidだけを持っています。 { posts : { byId : { "post1" : { id : "post1", author : "user1", body : "......", comments : ["comment1", "comment
redux-workerized で Redux と Vue を接続する - mizchi's blog
mizchi/redux-workerized 作った。 yarn add redux-workerize で入る。 元々は react-hooks で redux へのアダプタを書いていただけのライブラリだったが… TypeScript フレンドリーなAPIにする ReactRedux.Provider の異なるAPI表現だけじゃ面白くない じゃあ Redux.Store を worker に置いて postMessage で更新しよう mapStateToProps や更新処理の抑制の処理もCPU使うから、worker に置こう JSON飛び交ってるだけだし、 React だけじゃつまらないから Vue Plugin も提供しよう 結果、ビジネスロジックが Worker に切り出された上で、 React と Vue が同じ Store を共有するようになった。 どうなってるかというと
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Redux vs. The React Context API
👋 Hey! If you have a subscription to egghead.io you might enjoy my course on the Context API over there. It's only about 35 minutes long and covers a lot of ground: how to manage state with Context (without Redux), patterns for structuring your code, how to display notifications, testing, performance. All in real-world scenarios. React Context for State Management React 16.3 added a new Context A
なぜ私はReduxをやめて MobXを使うようになったのか
https://www.hubspot.com/state-of-marketing · Scaling relationships and proving ROI · Social media is the place for search, sales, and service · Authentic influencer partnerships fuel brand growth · The strongest connections happen via call, click, chat, and camera. · Time saved with AI leads to more creative work · Seeking: A single source of truth · TLDR; Get on social, try AI, and align your sys
JavaScript: Reduxが必要なとき/不要なとき（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: When (and when not) to use Redux – LogRocket 原文公開日: 2018/01/20 著者: Christian Nwamba サイト: LogRocket 2018/03/13: 初版公開 2021/06/03: 更新 Reduxが登場するまで、複雑なタスクを組むときのステート管理は相当つらい作業でした。Reduxは、Fluxというアプリケーションデザインパターンにヒントを得て、JavaScriptアプリでステートを管理するために設計されました。ReduxはReactと併用されることが多いのですが、ReduxはjQueryやAngular、Vueといった別のフレームワークとも併用できます。 Reduxのサイズは非常に小さい（依存関係も含めてわずか2KB）にもかかわらず、アプリの各コンポーネ
RailsエンジニアがReactを始めてSSRとReduxとTypeScriptを導入するまで | bitjourney Kibela
RailsエンジニアがReactを始めてSSRとReduxを導入するまで Roppongi.rb #3 "Rails x Frontend-Tech" 自己紹介 github.com/gfx BitJourneyでKibelaを開発 Speee, Inc. で技術顧問をしてる Reactは現職で初めて触った（2016年8月~） 今日の話 Kibelaのフロントエンドの話です。 読みはキベラ Markdownで書けて、フロー情報（Blog）とストック情報（Wiki）を区別して整理できる情報共有ツール これまでの話 新規Railsアプリに小さく導入するReact // Speaker Deck （dex1t, 2016/09/05） 小さく導入して学びながら開発を進める ⭕ Interactive UI componentをReactで＆jQueryも併用 ❌ viewをすべてReactで実装
React+Redux未経験者のプロジェクト受入 - Qiita
自己紹介 渡辺 貴明 EngFrontend follow me! アジアクエスト株式会社 フロントエンドエンジニア 今日の話 React未経験者が、 Reduxのプロジェクトにスムーズに参加するため 何をしたか？ 想定する状況 ソースはreact-redux-universal-hot-example を元に複雑にした感じ 大事 アーキテクチャはこんな感じ これから物量をこなす段階 新しく人を追加する ES5のjsはできるがReact触ったことない 必要なこと Reactを覚える必要がある Reduxも覚える必要がある BFFでのAPIの叩き方も覚える必要がある ES2015も覚える必要がある 問題 Reactだけ覚えても仕事に入れない 丁寧に覚える時間はない しかし、覚えないと渡せる仕事がない やったこと 専用のチュートリアル的なものを作成 最小構成のサンプルを作って真似して書いてもら
あなたは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を使おうとします。「
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
Coffee, jQueryで書いていたElectronアプリをES6, React, Reduxで書き直した - k0kubun's blog
ElectronベースのTwitterクライアント: Nocturn ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog の時にCoffeeScriptとjQueryで作っていたNocturnというTwitterクライアントがあり、これをES6, React, Reduxを使って書き直した。この記事ではその時に得た知見、感じた事を書いておく。 移行したスタックと移行時に感じたこと あらかじめお断りしておくと、僕は普段はRubyでサーバサイドの実装や運用をやっている人であり、JavaScriptに関してはほぼ素人の意見なので、以下はReactとかRedux興味あるけどまだ触ったことないですみたいな人向けの内容になると思う。 CoffeeScript → ES6 移行 参考: 春からはじめるモダンJavaScript / ES201
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービスの成長を支えるフロントエンド開発 #denatechcon
React/Redux Introduction
http://post.simplie.jp/posts/27
mizchi の Redux 考