【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
Facebook製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog
昨日、Facebook製のReact用ステート管理ライブラリRecoilが発表されました。Facebook製といってもReact公式のステート管理ライブラリとかそういう位置付けではないようですが、それでも大きな注目を集めているのは間違いありません。 そこで、筆者がRecoilに対して思ったことや、筆者の視点から見たRecoilの特徴を記事にまとめました。 なお、この記事の執筆時点では副作用の扱いなどの点はいまいち情報が揃っていません。この記事では速報性を重視し、コアのステート管理部分に絞って考えています。また、まだexperimentalなライブラリなので、今後この記事の内容からRecoilのAPIが変化したとしても悪しからずご了承ください。 この記事を書くときに筆者が色々試していたCodeSandboxはこちらです。 https://codesandbox.io/s/recoil-san
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
【SSRも】Fleur − 新しいFluxフレームワーク【イケる】 - pixiv inside
みなさんこんにちは！ VRoid Hubでフロントエンドエンジニアをしている花倉ミツカ (a.k.a. ラグ)です 🙌 今回のpixiv insideはちょっとだけお仕事から離れて(ガチ)アイスブレイクです。私が1年ほど開発しているFluxフレームワーク、Fleur (フルール, @fleur/fleur)について、その設計や使い方についてご紹介させていただきます！ 目次 どういうフレームワーク？ 実際の使い方 質問 まとめ どういうフレームワーク？ pixiv Sketchで採用されている Fluxible というFluxフレームワークを参考に、「書きやすさ」と「現代的な機能の採用」の二点を重視してTypeScriptでフルスクラッチしました。（Fluxibleは私が知ってる中で一番"整っている"フレームワークだと思っています♨） Fleurの大規模なプロダクションでの採用実績はまだあ
Vue.observable & TypeScriptで手早く安心できる状態管理を手に入れる - Qiita
Vue.jsにおける状態管理方法として何を使っているでしょうか。 dataにつっこむ ReduxとかMobXとか といった方法もありますが、もっともメジャーなものはVuexでしょう。 Vuex&TypeScriptがなかなか大変 フリーダムなフロントエンドに疲れたのか、最近はTypeScriptを採用するケースも増えているかと思います。型で保証されている安心感は一度味わうと抜けられないですよね。 しかし、実際やってみた方であれば実感するかと思いますが、VuexとTypeScriptを組み合わせるのはなかなかに大変です。 クラスコンポーネント化したVueコンポーネント内でのVuexとの接続に関しては、ktsnさんが公開されているvuex-classを利用することで可能となります（ありがたい）が、Vuex内部でのstate/getters/actions/mutationsの定義においてきっち
typelessというReact向け状態管理ライブラリがめっちゃいい - Qiita
typelessというreactの状態管理ライブラリが非常に良いので紹介します 2019/10/24: 入門記事 書きました What is typeless? react+typescriptで使う前提のreduxラッパーライブラリ。reduxが抱える以下のような課題を解決する 異常に多いボイラープレートコード 重複した型注釈 大量の依存ライブラリ 欠如したコーディングガイドライン これらの課題を踏まえて以下のコンセプトでデザインしている TypeScriptフレンドリー 実用に耐えうる機能を全て内包する 容易なモジュール追加 多くのユースケースに対する解決策をデフォルトで提供 ＊参考： https://typeless.js.org/introduction/motivation reduxの抱える課題について ドキュメントのmotivationの項で書かれていることは多くの人が課題を
ReactのNew Context APIは便利だけどreduxを使うのはやめないと思った | WEB EGG
Reduxの新しいContext APIが発表され、2ヶ月くらいが経過した。 — React’s ⚛️ new Context API – DailyJS – Medium 私は少しバージョンの古いReactを主に使っているため、しばらく情報を追わずにいたが、 — Reactの新Context APIとRedux is deadはどう関係するのか？ – terrierscript – Medium — React v16で実装された new Context APIを使って、Reduxへ別れを告げる - Qiita などの記事が登場するようになったので、自分は新しいContext APIとどう向き合うのかを考えてみた。 TL;DR 新しいContext APIはとても有用で、それ自体は活用しようと思う。 ただしContext APIがReduxを置き換えるものではないと思っており、引き続きR
React におけるローディングの状態管理について - freee Developers Blog
エンジニアの @_tohashi です。freee developers adevent calender 5 日目をやっていきます。 React などを使用した UI コンポーネントの実装、特に状態をどこで管理するかというのは実装者やアプリケーションの要件によって分かれがちなポイントであると思っていて、例としてはフォームの入力値、ダイアログの開閉、スピナーの表示などが挙げられます。各種ドキュメントや Issue, Example を見ても様々な流派があり、結局のところ Redux の FAQ にもあるようにこれが正解といったものはなくモデリングや要件に応じて適宜判断すべき話ではあるのですが、チーム開発においてはある程度方針を統一しておく必要があるでしょう。 本記事ではそうしたコンポーネントの状態管理のうち、特に非同期処理が絡んできて複雑になりがちなローディングについて自分の経験をもとに実
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
React Redux の SPA を運用して得られた知見と実装例、開発フローもあるよ！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以前 React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 と言うテーマで発表した内容に、加筆修正して記事にしてみました。2年半くらい取り組んで見ての結果や感想をシェアできればと思います。 対象読者 SPA の開発に興味がある方 最近の WEB フロントエンド開発に興味がある方 ある程度 React や Redux を触ったことがある方、触りたい方 目的 具体的な実装例をもとに知見を共有し、Web 開発の役に立ててほしい おかしな実装や、もっと良い方法があれば、教えてほしい 内容 コードベースでの実装例の紹介
react-routerではなくuniversal-routerでReact + ReduxのSSR + SPAする | nabeliwonote
react-routerがv4になったことで既存のアプリケーションが完全に壊れて困っちゃった人。いると思います。 まあでも頑張ればv4でも動くようにできるしv3からマイグレートする系記事もぽつぽつと出ているので、詰んでしまったりv3に居残り続けるみたいな選択にはならないと思いますが。 しかしそこは今後もドラスティックなメジャーバージョンアップを行うことが予想されるreact-routerなので、この際別のルーティングライブラリを選択してもいいのではないか、みたいな。 そういうモチベーションで今回の記事を書いてみました。 そしてこの記事ではreact-routerの代わりにuniversal-routerを使います。 universal-router is… universal-router 名前の通りUniversalなルーターです。クライアントでもサーバーでも動くよっていうあれ。 git
Repositoryの後ろにネットワーク越しのシステムがあることの是非からRedux的世界へ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基本非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて
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ページを開く
アメブロ2016 アメブロフロント刷新にみる ひかりとつらみ