サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
benlesh.medium.com
Every now and then I’m asked a question about how to use async functions or promises with RxJS, or worse, I’m told some “fact” about how async-await and Observables don’t really “work together”. RxJS has, from inception, had a high degree of interoperability with Promises. Hopefully this article will shed some light on that. If it accepts Observable, it accepts PromiseFor example, if you’re using
Promise Cancellation Is Dead — Long Live Promise Cancellation! Not very long ago Domenic Denicola (worth a follow, a very smart guy) withdrew his proposal for promise cancellation from the TC39. A lot of people might think that means that promise cancellation isn’t coming to JavaScript. Those people would be right, if you couldn’t already cancel a promise via very similar means to what was propose
Subjects in RxJS are often misunderstood. Because they allow you to imperatively push values into an observable stream, people tend to abuse Subjects when they’re not quite sure how to make an Observable out of something. The pattern looks a little like this… // What people usually first do with Subjects when they find them // (TRY NOT TO DO THIS)const subject = new Subject(); button.addEventListe
Well… okay, just don’t unsubscribe quite so much. I’m often enlisted to help someone debug an issue with their RxJS code or figure out how to structure an app that is composing a lot of async with RxJS. When doing so, I generally see the same thing pop up over and over again, people keeping handles to tons and tons of subscription objects. Developers will invariably make 3 HTTP requests with an Ob
Once in a while I’m asked what I think about naming observables with an $ suffix. For example: const click$ = Observable.fromEvent(button, 'click');Well, I personally could take it or leave it, but I know some of you can’t live without it. What I want to write an article about, however, is the origin of “Finnish Notation” and different dialects. Hungarian NotationWith Hungarian Notation, one adds
I’ve since rewritten the piece and moved it to my personal blog here:https://benlesh.com/posts/learning-observable-by-building-observable/ Frequently via social media, or in person at events, I’m asked questions about “hot” vs “cold” observables, or whether or not an observable is “multicast” or “unicast”. People seem to be really mystified by what they feel to be the dark inner-workings of `Rx.Ob
Created by Jay Phelps and myself for use on our projects at Netflix, redux-observable is middleware for redux that is inspired by redux-thunk. redux-observable allows developers to dispatch a function that returns an observable, promise or iterable of action(s). When the observable emits an action, or the promise resolves an action, or the iterable gives an action out, that action is then dispatch
TL;DR: You want a HOT observable when you don’t want to create your producer over and over again. COLD is when your observable creates the producer// COLD var cold = new Observable((observer) => { var producer = new Producer(); // have observer listen to producer here });HOT is when your observable closes over the producer// HOT var producer = new Producer(); var hot = new Observable((observer) =>
This might be controversial, as most people I know are huge fans of async/await. If you’re not familiar, it’s this nifty little syntax addition that allows developers to deal with APIs that return Promises in a more “native” way: async function doSomethingCool() { let someValue = await getSomePromise(); console.log(someValue + '!!!'); }As opposed to: function doSomethingCool() { getSomePromise.the
このページを最初にブックマークしてみませんか?
『benlesh.medium.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く