Check out a free preview of the full Enterprise Architecture Patterns course

The "Observables Q&A" Lesson is part of the full, Enterprise Architecture Patterns course featured in this preview video. Here's what you'd learn in this lesson:

Lukas answers questions about IDE theme configurations, promises vs. observables, and if data should be transformed on the server or client in an asynchronous call.


Transcript from the "Observables Q&A" Lesson

>> So the first question that I had was around my IDE and I believe the question was around string literals if I'm not mistaken, so if I did something like colored string equals law, this test is this what we're talking about like this magic take the color string letter right here, was that?

Yeah, that was your? All right, so [SOUND] how that is happening is, I believe, it is a function of the current theme that I'm using within my IDE editor, which is the material theme. Let me see if I can see this here. Looking right at it. And so I'm pretty sure it is the benefits of this theme by Mattia Astorino.

The fact that it's been downloaded like 2.8 million times 1000 Holland coyotes can't be wrong. It has to be good, so it's the icons and also I have this additional community material theme. So probably what I could do at some point, there's actually a command line to export all of my plugins.

I would be more than happy to just do that. And so everybody could just see what I have configured in my IDE if that would be interesting. But this is a really good theme, I use it quite a bit and I really particularly like this color thing. The other thing worth mentioning, the font that I'm using is operator mono.

It's not free, but I think there's probably some comparable fonts out there. That's really kind of the crux of it is I'm running the material theme with operator mono as my font. And so let me see in the chat room, yeah, Kevin, nailed it, encode URI. We had a question around observables and more so, the question was, can promises do the same thing?

And the answer to that is, depending on what we mean by the same thing, promises can do some of the things. Meaning, a promise can get a single value, asynchronously and return it to whoever holds that promise. That is the extent in which observables overlap with or promises overlap with observables.

So I would say promises provide a, an incredibly small subset of functionality in relation to observables. So for one observables don't have a concept of operators. So you simply cannot transfer transform your data is it's moving through the promise stream. There's no such thing, not only that is that A promise will only ever resolve one time.

And so, you're only ever going to get one value with an observable you'll get n number of values. Along with that the promises do not have the ability to cancel and retry. And so if you're doing any kind of asynchronous call that you need to actually cancel it and retry or recover.

Well, promises don't allow you to do that, which is exactly why. And one of the impetus of creating this was around Netflix and all of the asynchronous problems that they were having with communicating with the back end servers. And so in terms of the ability to handle situations and recover, that, yes, you can make an asynchronous call and it can come back.

You can do that with a promise, but if you need to do anything other than that, then You have, it's going to be challenging, it's going to be very, very hard. And so the ability to consume a value more than once to transform the data and then to recover if something goes wrong and retry.

To me is they had me at hello take my money.
>> When you are communicating with a server and you have to transform the data. How do you decide where you transform that data to the service to the effect and to the component? How do you decide where you transform it.

>> For me just is a default. If somebody asks me that without any other details, I'm gonna say put it in the effect. That, if you're transforming the data, there's a good reason why you would be doing that. And so I'm transforming this data for a reason. So I'm going to do, I'm gonna transform it before I start an application state.

So I would do it at an effect and the effect is that I would make the asynchronous call I would get that data. I would emit a completion event, which would then go into, another effect that all it does is transform the data. It would transform the data, emit another effect that would then probably put that in the reducer.

So you can imagine, you have the server event, the server response. That's one effect, so it's asynchronous. But then I would just put, encapsulate the transformation logic into another effect. And so I might actually put that in like a standalone service, but the transformation itself the act of it.

What happened in a second effect, which would then push that off into the reducer? And so this is also why I like a like streams and we'll see this in a little bit hopefully is that you can actually take a stream and use it to initiate. And you can just pass these events or these streams and sequence them up.

So that by the time you get to the end, any number of things have happened and you're able to compose it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now