The mindset you need for a DECLARATIVE code refactor 

Agreed, "readonly or const by default" would probably be a more succinct phrasing of "never change things" but I had to lean into the analogy a bit ;) I actually don't generally use readonly, I just don't reassign things - I don't specifically have anything against it but I'm not sure it's worth the clutter (open to having my mind changed on that though)

I abuse readonly and getter-only fields constantly because otherwise I'm stupid and I'll start changing things which absolutely don't need to be changed

i used to do that then i had to make some tests and it was really hard to change those readonly properties. I usually dont have logic in constructors , instead in ngOnInit so i could just set the values and call ngOnInit for every test.

The problem is you can have some kind of const wrapper like an Subject, with `next()` coming from outer space. Its not really any better than mutable.

My entire codebases are spammed with the readonly keyword :D

Yes absolutely it is going to be required, but also keep in mind that it's sort of an escape hatch too - sometimes you do legitimately need it and it is the right thing to do (handling user interactions is a prime example), but it's also possible to use it in situations where perhaps some data would have been better derived in some other way. So over utilising it will basically just lead to what is essentially imperative code with extra steps.

It doesn't necessarily have to be a Subject/combineLatest but generally yes that is the idea, the "filter" is some kind of reactive entity in your application, and "filteredData" is another reactive entity in your application that reacts to either the "data" reactive entity or "filter" reactive entity changing

If "activated" is toggled via a user interaction then this is a data source and is where you would have to imperatively next a subject or set a signal, this is a thing that is at the "top" of the data flow but anything below that is derived declaratively. However, if "activated" was determined some other way that could be determined from a source (not a user interaction), e.g. some data loading in or something like that, then the "activated" would be derived declaratively from that. "Fully" declarative just isn't really feasible with Angular, but we can get close enough, and certainly to an extent where we get the majority of the benefits.

@@JoshuaMorony Great stuff, this makes a lot of sense. Thank you for your help!

I will generally prefer to set/next directly in the template

Which part, the computedAsync/createNotifier? I wouldn't do the promise/signals approach without it, computedAsync is basically just hiding RxJS behind the scenes so without it I would just be using RxJS In any case, I did end up deciding not to go with that approach for this particular refactor - it was working but was feeling inflexible and perhaps a bit too risky to take on at this stage

Its not that. It easier to use, because it already has documentation. It already has been covered by test. It already battle-tested by other developers. And the last, but most important - it doesn't require your time to maintain and release new versions! Treat yourself of "Not inverted here" syndrome, it only will limit you in long run

It is possible for example to have a separate "error stream" that is derived from whatever it is you are loading that uses catchError + ignoreElements to make that a stream of any errors from some other thing, but personally I prefer a slightly more imperative approach with signals here. This video goes more into how I utilise the "imperative gap" between RxJS and signals: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-R4Ff2bPiWh4.html But essentially what I will do in these situations, say if I am authenticating a user or something, I will have my "userAuth$" stream or whatever, which will end up setting the status (e.g. "authenticating" | "success" | "error") into a signal (typically via connect form ngxtension to avoid the manual subscribe, or you can also just manual subscribe). Then if I wanted to launch a modal on error I would launch that as a side effect of the "status" signal changing to "error" via a signal effect.

Personally I still like RxJS for these sorts of situations, I have 'initial' | 'authenticating' | 'authenticated' | 'error' states some state signal, trigger auth by nexting some observable, and then have some kind of "userAuth$" observable that handles the auth and returns the correct state that then gets set (via connect from ngxtension) into a state signal. Enea is doing some interesting things with createResource though: github.com/nartc/ngxtension-platform/pull/282/files and using Angular Query is also an option here too. But ultimately if you want to tap to set some "isLoading" state I don't think it's that big of a deal (but no you probably shouldn't use computed for side effects)

export class LoadingService { private static _pendingRequestCount = new BehaviorSubject(0); public isLoading$ = LoadingService._pendingRequestCount.asObservable().pipe(map(count => !!count)); public static showLoadingUntilComplete(obs$: Observable): Observable { return of(EMPTY).pipe( tap(() => this._pendingRequestCount.next(this._pendingRequestCount.value + 1)), concatMap(() => obs$), finalize(() => this._pendingRequestCount.next(this._pendingRequestCount.value - 1))); } } You can wrap every HTTP call in LoadingService.showLoadingUntilComplete. The reason it is static is because i've created a Decorator that i place on top of http methods @ShowLoadingSpinner() public getConditionsData(): Observable ....

You're correct, it would need destroyRef in this case

​@@JoshuaMorony I thought I was going mad 😂 keep up the great content 🎉

At a glance (and obviously without context) I would say that the imperative triggerLoad$.next shouldn't be required - the situation is that you have something (your table data) that wants to react when any of three other streams emit (i.e. they finished whatever operation they were doing). So probably you would want something like tableData$ = combineLatest(thingOne, thingTwo, thingThree).pipe(switchMap to fetching table data)

In every JS framework it's either a manual 'invalidation' action (similar to your triggerLoad$ stream) or a simple navigation that triggers stuff to reload. I don't see any way around that, unless you use websockets or server-sent events to invert data fetching responsibility to your database. So it doesn't get any simpler than what you already are doing...

One idea would be to not refresh the data completely after a crud operation. Instead you could manage the state locally by using the response from the API. For example if you delete an item from the table you could filter it out in the local state after you received a success state from the API. If you create or update an item you could also add or replace it to the local state with the response from the API.

its fine until its overcomplicated. If it doesn't bring your pain then you need to change something in that code, leave it as is

Do you have an example you could share? I'd be interested to see how I might approach the situation, but yes there will always be imperative gaps (as there are multiple in the video)

That's just not true. You have something that is the source of the event, say your tree node. It would be an observable of some kind that emits its open/close state as it's interacted with. Some downstream thing can react/.pipe() to the open/close signal, potentially combined with other sources. Imagine some king of zip/combineLatest between this tree node and a text box. When either changes you can decide to make/cancel some server side request. In turn, things like spinners and a downstream in a template can consume *that* as *it* changes. All async.

I disagree in general, a mix of declarative and imperative code with no real strict rules/guidelines being adhered to is likely going to be a worse situation. Yes, rules are made to be broken, but it's not ideological/dogmatism to follow rules in a codebase like "class members must be readonly/declarative" there might arise situations where that rule would be broken, but it would come with consideration/justification. In general, my preference (in order) would be: 1) as much declarative code as possible 2) all imperative code 3) an adhoc mix of both

IME you end up with the constraints of both and the benefits of neither.

Great take! Been at the end of each side and I completely agree - best is somethere in the middle

On the contrary, My Dear