New newsletter goes out tomorrow with a tip about signal effects: mobirony.ck.page/4a331b9076 (you can also get access to the complete archive of previous tips)
@Santon-Motho11 ай бұрын
Joshua "I am going to find every possible angle from which to speak about observables" Morony.
@Santon-Motho11 ай бұрын
PS: I love your channel lol
@JoshuaMorony11 ай бұрын
I like observables
@orterves11 ай бұрын
Resistance is futile. You will be Observed.
@d.nazaratiy11 ай бұрын
"Cancellation is much easier with observables than with promises" and then you show a code that do NOT cancel anything for observable: your request is STILL happening. you just missing its result and I wouldn't call it "cancellation" since you still can ignore almost the same way with promise. The biggest misconception of promises vs observables is when people try compare them. These are TWO DIFFERENT conceptions: promise is a mechanism to EXECUTE a singular ASYNC OPERATION while observable is a mechanism to constantly MONITOR CHANGES. That's it. And you have to always think about your architecture before coding instead of blindly use some kind of silver bullet that you just learn. This is a way to deal with misconceptions in general: figure out what your code supposed to achieve, what flow it supposed to follow and only start coding after you know what you should code
@JoshuaMorony11 ай бұрын
This video isn't to present observables as a silver bullet. I agree with the general idea of promises being suited to a single async operation, and an observable multiple. The key point I am trying to make is that what some people see as being just a single request suited to promises, is often actually multiple requests if you consider the lifetime of the data in the application, which is something that suits the observable paradigm well. People often see observables as only being suited to esoteric/bizarre/rare circumstances, my point is that they can be useful for much more mundane situations where people often see promises as the only obvious answer. EDIT: And to your specific point about cancellation, in the case of Angular's HttpClient (Angular is usually the context for my videos) the underlying request is cancelled, but I can concede that's sort of "cheating" in this context since a separate library is handling the cancelling - the inclusion of this probably just detracts from the point of the video
@d.nazaratiy11 ай бұрын
@@JoshuaMoronyyou still don't get it: observables are for MONITOR changes, but not EXECUTE multiple blah-blah-blah. You should not compare these two concepts. They are different. It's like compare yellow and sweet - you can work on your dish based on idea that it should be sweet(your app main idea is a flow of async calls - promises) or that it should be yellow (your app main idea is not a flow but atomic reactions on state changes and events - observables) or you can combine them. But they are two different non-comparable and non-conflicting concepts. And when you are talking about observables as it is something to execute multiple calls - it is like saying that your dish tastes yellow. It makes no sense
@JoshuaMorony11 ай бұрын
@@d.nazaratiy perhaps I don't get the distinction you are making here - in the terminology you are using I would say an observable "monitors" changes over time, e.g. the value for a page number changing, and then reacts to that change by "executing" the appropriate request (e.g. via switchMap), which allows for the code to be declarative. You can do the same thing with a promise, but not declaratively as it doesn't have this ability to observe/react to changes over time, it only perform the "execute" part which has to be triggered imperatively somewhere
@osph552511 ай бұрын
“Simplicity is the ultimate sophistication.” - Leonardo da Vinci.
@yousafwazir316711 ай бұрын
Love the videos
@nomoredarts891811 ай бұрын
To make it even more declarative I highly recommend using point free style, so switchMap(a => doSomething(a)) becomes switchMap(doSomething)
@Hariharan060611 ай бұрын
Amazing example!
@kaischonberger9710 ай бұрын
Another great example why Observables can make a lot of sense for HTTP requests is the implementation of a stale-while-revalidate cache. Imagine implementing a function that returns a stale value from a cache for quick rendering and then after that returns the fresh value from the API. Ugly to implement with Promises, but so easy with Observables.
@aravindmuthu574811 ай бұрын
Well observables still technically call the http request multiple times(look at the network tab) to the server each time any sort of change happens. Observable acts as an interface that communicates with the network and state of application, which is quite useful in large scale applications as well as small ones. The problem is that Rx creates a kind of vendor lock inside the application and the integration with Angular just compounds the problem Edit: I would personally find Observables useful if a state change triggers a cascading domino effect like situation, where a single api call results in a bunch of other api's being triggered, each trying to work in a sequential format, but in most cases I can simply use .then().catch() as it is way more explicit and self contained Finally: Before finishing off, I would conclude with key points: 1) If you're using Angular, use Rxjs 2) If you're using anything else, choose wisely
@JoshuaMorony11 ай бұрын
I'm not sure if I'm missing your point, but I expect the observable to result in multiple requests. The issue I was pointing out with promises wasn't that it makes multiple requests, it was that when taken in the context of all the requests, this is basically tackling the same problem observables are - dealing with multiple requests over time. As for vendor lock in, I've never really had too much of a concern with being dependent on RxJS, but there are currently moves underway to potentially get some kind of observable baked into the browser, which would be cool (obviously not with all of RxJS's gizmos, but it would still be good)
@martinledoux59411 ай бұрын
I'd hardly compare using an open source library like RxJS to "vendor lock-in". Yes, it's a good choice (almost already made for you) if you're using Angular, but you can use it with any framework or plain JavaScript. A couple years ago I heard a podcast that mentioned that 5+ years ago, the RxJS conference was almost entirely Angular people. But then 3ish years ago, that shifted to being nearly 50/50 with React developers. In that case, React developers have a lot of choice, and I'd suggest that using RxJS is a great choice - a wise one at that!
@martinledoux59411 ай бұрын
As for your Edit, that scenario is exactly what makes RxJS so powerful, when dealing with REST APIs. Make a single (re-usable) Observable that starts with a base-API call, which can then be switchMap()ed to a zip() or combineLatest() to make a bunch of follow-up (dependent) API requests using a value retrieved in the first request as a parameter to the subsequent requests. Yes, you can surely write a function that returns a new Promise (deferred) and chain some .then()s together like an RxJS .pipe(), and that would be just as reusable.
@timonkrebs557611 ай бұрын
Great Video. Do you see any "valid" usecases for promise that would not be better with observables? I think the readability of async await is still better in some cases. But having two concepts that can do the same while one is a lot more powerful is not really a good place to be. For simple things i would still prefer promises maybe combined with signals... I would like to have a solution that does not require the subscription handling with the readability of async await. I am still not sure if signals operators could be that.
@JoshuaMorony11 ай бұрын
I'm not like anti-promises or anything - but I do generally find I almost never use async/await in the Angular codebases I have control over. On the other hand, in code bases that are not so declarative that I work in I use async/await quite liberally. I think the declarative aspect is the key point, and where having everything as streams over promises becomes more useful.
@timonkrebs697811 ай бұрын
@@JoshuaMoronyI agree completely. I almost never use Promises in Angular. But I feel like there must be an even better way to do things than rxjs. The biggest issue is having to handle subscriptions. I really hope we can find a way to make the idea of Mike Pearson for signal operators work in Angular.
@jonathangamble11 ай бұрын
It would be interesting to see what you would do on the server. Most modern apps fetch on server for speed, simplified client js, and seo. Even with Universal or Analog...
@JoshuaMorony11 ай бұрын
I'm super keen to give Analog a go, but all the server stuff I am doing at the moment you may be pleased to know is with SvelteKit - but I am just generating a bunch of static sites and there is very little state involved so I haven't really got to explore more complex data flows in this context.
@dopeshots968711 ай бұрын
Josh. What is the difference bw RxJS and RxAngular. where should we use RxAngular
@poh904411 ай бұрын
How do you handle change detection on window resize?
@TheSaceone11 ай бұрын
do you have an old-fashioned standard tutorial on how to import and use signals in ionic?
@JoshuaMorony11 ай бұрын
There isn't anything special about using signals in Ionic, you would just import 'signal' from Angular as normal - is there anything particular you wanted to know?
@user-hd8dm5ur3i11 ай бұрын
@JoshuaMorony Nice content! Can we expect some ionic staff in nearest future?
@JoshuaMorony11 ай бұрын
I generally try to keep things generic since Angular stuff applies to Ionic anyway - is there any Ionic specific stuff you want to see?
@user-hd8dm5ur3i11 ай бұрын
@@JoshuaMoronywhat I'm thinking, it would be good if we can build atleast simple ionic app with crud of course, including some interesting native or custom behavior for add/edit/delete items. There can be added interesting behavior for reload component data using ionic progress-bar/skeleton/maybe refresher. And also with some page navigation using ion-router (because we can use just angular router, but it's interesting to know how to combine them properly and cases when we should do it). Andl also we can do all of it with state (maybe custom service, maybe ngrx and others, maybe signals). What do you think? I guess it will be interesting for all the auditory
@luxiansheng226811 ай бұрын
Nice perspective, how do you handle the endless call stack issue when debugging rxjs? Hard to find the triggers when debugging
@e-jarod411011 ай бұрын
Not a problem because you never need to debug the built-in library You just need to debug your function
@luxiansheng22685 ай бұрын
@@e-jarod4110 The problem is that I don't know who triggered my function. For example, it sent an incorrect param to my function.
@brandonjoaocastillo749010 ай бұрын
Can you please give the name of your theme!???
@JoshuaMorony10 ай бұрын
I'm using Gruvbox
@Alex-bc3xe11 ай бұрын
In angular I do argue always use observables is see no point not doing so.
@AngeloMichel11 ай бұрын
This 'comparisson' is a bit unfair imo... they omit all the boiletplate code from the observable side. In any real world situation you'd use frameworks OR make your own utlity wether or not you're using observables or promises. In fact, in real world examples you have to deal with both senior AND junior developers, which makes it FAR easier to just use javascript (or ts, ofc) because its just more simple to understand. Specially if you're just making a fetcher for a page on some client (like the given example from the video). - So yeah, when in my personal opinion Observables really shine is with let's say... handling a stream of events, or.. handling and converting events or data over time. So in short, remove the abortcontroller, in favor of any framework which abstracts this and the right-side example would be shorter and easier to read and maintain. No need to carefully read if someone used a BehaviourSubject (or if that is even the correct one to use), and this video would have a far different tone I guess :)
@JoshuaMorony11 ай бұрын
I think the comparisons were probably a bad idea for this video as it detracts from the main point anyway - the main point I am trying to make which you touch upon "handling streams of events, or... handling and converting events or data over time" - this is how I treat these sorts of HTTP requests in my application. People often ask why you would ever want to use an observable to handle an HTTP request that just returns a single value, my point is that when you consider the lifetime of the application those requests are often performed multiple times (e.g. you might just get the data for the current page now, but later you will run that request again to get the next page of data), so they essentially are streams of data over time which is what observables are good at handling, and specifically they allow you to write the code declaratively
@DhainautRaphael11 ай бұрын
@JoshuaMorony Thank you very much for this comment, The chosen example is excellent because it is indeed a fundamental question on why to adopt observables / Rxjs within an application. I never really understood the point of managing 'a single response' with observables. I now understand your point of view better and how you “design/build” an application in your mind. Ultimately, it is a question of “paradigm”. With Rxjs, you manage "interactions" as a flow/event to which your code reacts instead of declaring a "sequential approach" (I say sequential here because when we use the async/await syntax we 'flatten' the sequence of 'execution).
@anasouardini11 ай бұрын
The example you give only need a layer of abstraction to be added and for the unnecessary "async" functions to have a sync version (stupid browsers). This is a really bad comparison between promises and observables. You remind me of people quitting the use of Linux because modifying kernel is troublesome: promises can be improved to cover more of what observables can do.