I've been thinking about making a video for this (I probably will) but I don't generally run into any hard problems with testing reactive code - do you have any examples (even if it's just a general description) of situations that have been challenging? I'll try to address that in the video.

if you test the template of the component (I mean not calling component function, but expecting template values, element visibility...etc), then there should be no differences. If you would like to test only ts parts (I don't recommend it, because it is only half of the work), then yes testing rxjs can be trickier, perhaps you will need rxjs-marbles. Meanwhile for imperative code you need only fakeAsync+tick() or done(). At the end you should see (like from Joshua's example), using declarative approach is more maintainable, shorter and in unit test point of view, totally the same.

As someone who worked in some different teams, I have to agree 100%. Declarative code can look cool, but even in the Bonus example here it looks way too hard to read and understand, in my experience code like this causes way more issues. I think having a mix of both approaches is the sweet spot.

Same here

Thanks for the comment! I think a big part of the problem with coding reactively with RxJS is that since it is such a paradigm shift it looks very intimidating and confusing until you spend quite a bit of time learning it. So you kind of need to be convinced the benefits are worth basically coding in an entirely different way and trusting that it's going to make sense at some point. And yes you can certainly make some optimisations to make things more readable, whether that is creating your own custom operator, or just splitting things out into more streams (e.g. as I did with playCurrentPhotos$ to make the role of that a bit clearer, maybe it would be even better to call it emitEachPhotoWithDelay$ to make it even more clear). And as I mention in the video, this stream is an atypical example that is more complex than most of the streams you generally have to work with. If it ends up being too much/you just don't like it, you can always just switch to using imperative code for specific components (especially if it is just your dumb/presentation components, it's not going to impact the overall reactive architecture of the application).

@@JoshuaMorony thanks a lot to have taking time to give a complete answer. I will continue to stay with an opened mind and look/ view your next videos ;) Maybe I will change my opinion about RxJs paragidm/library.

​@@DhainautRaphaelafter a year. Any changes to share Raphael? Any experiments?

If I had data coming in a format that I needed to change yes I would pull that into a service, modify it to the format I need, and then have my components consume that.

Separate your services into two types, functional and transactional. The transactional services are responsible for receiving data from the backend and formatting it in a way that makes sense while functional services are responsible for specific functionality for a feature. That way many feature services can rely on one transactional API service. Each service maps it's data to specifically what it needs for it's purpose.

I haven't actually tried it but I assume EMPTY won't work because it completes immediately, I did try NEVER which emits nothing and never completes, but it doesn't work in this case.

Yes but I think in case your pipe for concatMap is attached to internal one it doesn’t influence on the outside that emits photos I tried this with EMPTY and it works fine for me

Can't you set filter isPaused with another subject? Making it not emit anything while paused. Like this point seemed to me a little weird since it obviously only pauses for 10 seconds.

I try to keep with the default ESLint rules since I am often creating tutorials, so that's really the only reason I am placing the setter like this so that other people don't get ESLint errors if they try it out.

Yep, you can find it on this branch: github.com/joshuamorony/ionicstart-snapaday/blob/insta-story-v2/src/app/slideshow/slideshow.component.ts

Probably! That's why I posted this example to Twitter to try and see if the imperative example was a "fair" representation. It probably could be better, but I also think it's a pretty standard implementation (I don't think I've ever actually seen someone create their own generators/iterables in an Angular codebase). I am super curious to see what the result would look like though.

​@@JoshuaMorony after i did smal exampe, i realize, that i have no idea how to share link to it in YT comments, so here is a base64 encoded link: aHR0cHM6Ly9naXRodWIuY29tL1ZhbmlsbGFNYXN0ZXIvc25pcHBldHMvYmxvYi9tYWluL2dlbmVyYXRvci5qcw== if someone really become interested they can handle it ¯\_(ツ)_/¯

YT algorithm wasn't a fan of you posting a base64 encoded link and delete your comment lol, but I still got the notification for it! Here is vanilla's code for anyone interested: github.com/VanillaMaster/snippets/blob/main/generator.js thanks for sharing!

I find RxJs solves a lot of async problems that are inherent in imperative programming without any need to actually think about them. But that's just me :)

@@samchilvers3711 of course it does as that’s what RxJs is designed to do.

What problem are you running into with routing?

@@JoshuaMorony I find trying to keep the app in sync with the queryParams very difficult to do, unless u subscribe to the activatedRoute or router-store (when using ngrx) manually, then sync the components, or maybe I just had some complicated use cases mixed with some bad luck and inexperience. E.g. Imagine a stream of markets (dropdown) each has a stream of products (list), and a stream of specialties or categories (tabs), on each tab I want to filter the products, the default tab is 0 (if not in the url), every time I change the market the tab should be 0, every market has different number of categories (2 or 3), each time I click on a tab the products are filtered, but the url shouldn't be changed unless I select a product from the new tab. I also want to be able to share the url to open app in the expected state with everything in sync, url, selected market, selected tab with the filtered products, and the selected product (if in the url). Errors should be handled obviously: when market doesn't exist in the dropdown, when tab doesn't exist (3rd tab may exist for some markets but not for others). I managed to do all that using streams and declarative approach, except initializing the app from url and changing the url from the app that I had to subscribe/unsubscribe

I responded to your other comment as well which already covered some of this points, but I'll fill in the gaps here: 1) If you want to code declaratively then you need something like a stream so you can react to changes. With the imperative approach, if something depends on some class member (that is not a stream/reactive), and that class member changes, then it is up to you to make sure you are manually/imperatively handling that change as opposed to it just happening automatically. Assuming that you aren't introducing some kind of bug/unintended behaviour there isn't really a performance concern here, these streams are really just functions behind the scenes 2) Obviously it requires knowing RxJS in the first place, and this is a subjective thing, but I disagree - I think the reactive code is simpler. With reactive/declarative code I can see what something is and how it behave in one place and it is generally shorter. With imperative code the behaviour is scattered around the component. I would say reactive/declarative code generally better adheres to the KISS principle (though I'm not really a fan of dogmatically following principles like that anyway) 3) Not sure what to say to this one - I've never had any trouble maintaining/testing my code. There are some specific situations with very advanced streams that can become a bit harder to test, but these are not the norm, and I generally find testing with streams to be a lot easier - (it is often in the form: do X, check that Y stream emits Z)