Naming things is hard. Naming things in programming is even harder, IMO. RxJS and observables bring more confusion for some people when it comes to naming because they’re just not sure what to make of them. Observables are a lazy type that, when subscribed to, pushes values at you like a collection. Observables can have side effects, just like functions. Observables might just have side effects, in fact.
In truth, it probably doesn’t matter too much how you name them, as long as you’re consistent, you can understand your code, and perhaps more importantly, your team and/or the person that comes after you can understand your code. …
Visual Studio Code is a powerful IDE, and my editor of choice while working on RxJS. They have some amazing debugging features, but I was having a really hard time getting it to work with TypeScript-based Mocha tests while working on the experimental branch of RxJS.
The following is my configuration that got things working for Mocha and TypeScript debugging with VSCode:
(Note: You’ll want to change
modules/**/*-spec.ts to a glob that matches your test files)
"name": "Mocha All",
I’ve been working at Google for a little over a year now, and many people have thought that during this time I’ve been working on the Angular Team. Even more people have thought I worked on RxJS full time. Neither of those things were even close to true.
Over the past year I’ve been working on Alkali, which is an internal platform-as-a-service built with Angular and Java (and a host of other technologies including RxJS). It is a fantastic project, and an even better group of people, and I’m sad to be leaving them. Fortunately, they’re just downstairs, so I’m not that sad. …
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.
For example, if you’re using a
switchMap, you can return a Promise inside of there just the same as you can return an Observable. All of these are valid:
If you have access to the function that creates the promise, you can wrap it with
I want to be clear: You can’t cancel a Promise. (I know, I know, mixed messages)… If something gives you a promise, your ability to cancel it has already been decided for you… you can’t. This is because promises, unlike Observables, are eager. Once you have a promise, the process that will produce that promise’s resolution is already underway, and you generally don’t have access to prevent that promise’s resolution any more. More importantly you can’t tear down resources. …
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.addEventListener(‘click’, () => subject.next('click');
subject.subscribe(x => console.log(x));
While this is helpful for people new to RxJS (and in that capacity totally fine), it’s not really the “Rx way” to handle things like this. Ideally you’d wrap your event registration in an Observable that can set it up and tear it down. …
Over the last 4–5 years I’ve had the amazing opportunity to mentor some even more amazing people. I want to share what I’ve learned.
You might be mentoring someone right now and not realize it! Do people ask your opinion? Do you get hit up for advice? Congratulations, you’re probably mentoring!
Everyone has things they know and things they don’t. This means there’s always an opportunity to learn from or teach someone else. In tech especially, everyone is a beginner at something. …
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 Observable, and then keep 3 subscription objects that they’re going to call when some event occurs.
I can see how it would happen. People are used to using `addEventListener` N times, and then having some clean up where they have to call `removeEventListener` N times. It feels natural to do the same with subscription objects, and for the most part you’re right. But there are better ways. Keeping too many subscription objects around is a sign you’re managing your subscriptions imperatively, and not taking advantage of the power of Rx. …
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.
With Hungarian Notation, one adds a prefix to their variable names that denotes the type the variable contains. Generally, this prefix is about one to three characters in length. For example:
const sTest = "test";
const nShortPI = 3.14;
const obsClicks = Observable.fromEvent(domButton, …
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 dispatched as usual.