ThreadじゃなくTaskを使おうか？ - QiitaHelp us understand the problem. What is going on with this article?
コールバック……駆逐してやる…この世から…一匹…残らず!! - Qiita
このテキストは JavaScript のコールバック地獄に疲れたひとのためのコールバック駆逐術指南書です。対象読者は JavaScript道初段くらいの人です。このテキストを読むと、以下のそれぞれの手段における非同期処理制御の仕組み、利点および欠点がわかるようになるかもしれません。 コールバック地獄 jQuery.Deferred async.js Concurrent.Thread generators co fibers Web Workers (※なぜか『進撃の巨人』の一部ネタバレが含まれるので注意してください) それは『何故人はコールバックするのか』という話でしょうか？ 非同期処理って面倒ですよね。JavaScriptではいわゆる コールバック地獄 というやつにしばしば陥りがちです。たとえば、Ajax でふたつのファイル hoge.txt と piyo.txt を持ってきて、それら
JavaScriptは如何にしてAsync/Awaitを獲得したのか Qiita版 - Qiita
はじめに JavaScriptは如何にしてAsync/Awaitを獲得したのか - がおさんち 技術部屋 ※事前に↑の記事は読まなくても大丈夫です という記事を、以前に個人ブログの方に書いたのですが、私も今年からはQiita始めたので、この記事をリファインして再度書いてみようと思います。 また、この記事では↑の記事では書ききれなかった話もいくつか増やしています。 例えば、不定回数実行されるPromiseの話だとか、非同期処理における例外処理周りの面倒くさい話だとか。 そういうちょっとだけ高度な話も混ぜつづ、前回書いたものよりもクオリティを上げるのを目標にします。それではいきます。 第一章 ～人類はsetTimeoutを採用しました～ 古代のJavaScriptで、以下のような処理をしたい場合、どうしていたでしょうか。 ブラウザ更新直後に『a』を表示し、その2秒後に『b』を表示し、更にその1
Promiseとasync-awaitの例外処理を完全に理解しよう - Qiita
はじめに JavaScriptは非同期処理との闘いです。 人類が非同期処理を倒すために、Promiseやasync-awaitという最終兵器を生み出して、劇的にクリーンで平和な世界が生まれたという話は以前しました => (もしかして： JavaScriptは如何にしてAsync/Awaitを獲得したのか Qiita版) しかあぁし！！！ 甘い、甘いのですよ！！！！！ 人類を苦しめ続ける非同期処理が、そんな簡単に完全に倒せるわけがないのですよ。 非同期処理の本当にヤバイ深淵、それが「例外処理」です。 みなさんはPromiseで開発していて、 「なんか途中までうまく行ってたんだけど気づいたら例外が外側に飛ばなくなった…なんでだ…」 「助けて！Promiseにcatch書いてるのに何故か例外がcatch出来ないの！！！」 という経験はないでしょうか。私は何度もあります。 この記事では、具体的に何
Redux の Reducer で非同期の状態変更を扱えるように拡張した「Rxdux」について - Qiita
Redux の不満 Fluxの実装であるReduxの不満点のうちの１つとして、Reducerの扱いがある。もちろんReducerの考え方とそれによるStoreの状態管理、およびcombineReducersによる状態の分割統治についてはまあよいのだけれども、Reducerには同期的な状態変化しか扱えない（扱わない）という制約がある。得てして実際のアプリではモックで同期処理で行っていたことでがいつの間にか非同期の処理となったりすることもあり、その場合Reducerで上手くやってたことでもAction Creatorの方に移動しなきゃいけなくなったりする。 Action Creatorsでは現在のState情報を見るのにはgetState()といきなりStateツリー全体にアクセスすることになる。Reducerではうまくできていた分割統治がここでは厳しくなる。なんとかMiddlewareで工夫
redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
