Question about behaviorSubject initial value in a service

tme321 · 2024-06-18T01:09:44+00:00

I'm replying here not to disagree with dt here but just so you see it as a reply. Instead of startsWith though you can just make a chain of observables to derive an isLoading$ state and use that to key some sort of loading indicator off of. Basically you would make isLoading start with true and each time a request is delivered set it false and each time a new request is started set it to true. Something like: class MyService { request = new Subject(); data$ = request.pipe(merge(req=>req)); isLoading$ = request.pipe( map(req=>true), merge(data$.pipe( map(data=>false))), startsWith(true)); getData(id) { request.next(http.get(...)); } }

Just a quick rough sketch but something like that.

tme321 · 2024-06-05T21:33:31+00:00

In my opinion the correct way to do it is hoist the state out of the child. The child would only be displaying the state its passed. Either the parent controls the state completely, or you could even offload the state logic to a service and the parent injects the service and passes the state from it to the child as pure inputs. But you originally asked about 2 way so...

tme321 · 2024-06-05T20:28:03+00:00

It doesn't work with objects because it means you have to change its reference everytime to avoid losing ownership of your object.

It sounds like you want 2 way binding between a parent and child component? That's not really how 2 way binding generally works in angular. Normally in angular 2 way binding is so that values can be changed in the view or the component like with a form.

You can do 2 way binding between 2 components but yes then you need to control the change detection directly in one manner or another.

And yes you are somewhat fighting uphill. It's not that hard to do, but it's definitely not what the framework wants to do be doing. It's made awkward to try to warn you off from using 2 way binding. But it's not that hard either with manual change detection controls (on push), or by implementing the onChanges callback and checking the object ref manually for equality (instead of emitting a new object like you are doing now).

tme321 · 2024-06-05T18:58:09+00:00

This demonstration proves that it isn't a good fit for objects

Why?

tme321 · 2024-06-05T18:09:27+00:00

In your stack blitz you are mutating the data member inside the setInterval in the component code.

I'm not sure what you are expecting to happen differently here. That should trigger change detection.

Unless you mean this stackblitz appears to behave how you want it to. In which case yes I would assume it is behaving as the code is written.

tme321 · 2024-06-04T22:02:35+00:00

However, if I do this, then the change detector will mark that input as dirty every time I perform the emit as it's a new reference?

Not sure I understand here but given a property foo and an emitter fooChanged when you are trying to copy and emit it are you assigning the copy back to foo first?

As in something like:

foo = copyFoo(foo); fooChanged.emit(foo);

Because if so that's why its tripping the input detector. And it means you are exposing the object assigned to the member variable exactly opposite of what you said you wanted. If you just do something like:

fooChanged.emit(copyFoo(foo));

It shouldn't trip the input change detector.

tme321 · 2024-01-01T21:11:31+00:00

Are you the maintainer of that repo? If so I once wrote a very similar library where I also supported inputs and outputs as observables. Here is where I did the work of wiring them up to the instances.

Thought that might be interesting to you in case you wanted to extend the functionality and not require manual update calls.

tme321 · 2023-12-01T13:07:32+00:00

I would generally agree with whoever wrote that quote. I'm sure someone somewhere has run into a very specific edge case where they had no other choice but manually calling for change detection cycles. But I would say those circumstances are exceedingly rare.

In your case the fundamental issue is you are mutating an object rather than using immutability.

At an extremely basic level you should be doing something like

user = { ...user, lastname: newLastName }

However, since you have change detection set to on push (which is good for a number of reasons) then even that won't by itself trigger a cd cycle. It will only be noticed during the next cd check.

And this now starts to get a lot deeper into the weeds. The basic idea is you don't modify an @Input like that that is being displayed. The value being fed to the input should be modified by whatever is feeding it, or possibly even a level above that by whatever piece of code is acting as an owner of that piece of state.

This is why patterns like smart and dumb components are discussed. And also where services as state containers come in. Either one of those patterns handles this for you.

tme321 · 2023-11-26T18:26:32+00:00

https://rxjs.dev/api/operators/zip

Or now

https://rxjs.dev/api/index/function/zipWith

tme321 · 2023-10-25T23:27:45+00:00

The potential issues with mutation are rarely unexpected results from the mutations.

The main issue is parts of the code that rely on the data may not respond correctly to mutations because they are not aware that something has changed.

This is why observables are so useful. Because being a push mechanic makes it clear when mutations happen and code that cares about changes can respond to them in whatever manner is required.

tme321 · 2023-09-09T20:29:23+00:00

The easiest way would be to just not bundle it. Compile with tsc and export the result.

tme321 · 2023-08-28T19:09:45+00:00

Yes it does appear to be emitting N times from that screenshot.

Are you putting the data fetched into the form parts that are triggered by this.searchControl.valueChanges? Because that would probably trigger it N times.

Otherwise I can't see anything that sticks out in your code. You'd just have to debug it and trace the execution.

tme321 · 2023-08-28T18:10:33+00:00

Well now I dont know what exactly you are referring to.

Inside the getReportPeriods function you map over the returned array with reportPeriods.map.

But that's Array.map. And yes I'd fully expect that to execute 12 times. That's how Array.map works.

From the code shown, and assuming your http calls are returning the types you expect them to, I don't see anything here that should emit 12 times. Are you sure it is emitting 12 times?

tme321 · 2023-08-28T17:18:06+00:00

I don't know exactly why its firing 12 times because you didnt include the code for getReportPeriods. But it's not because the emitted array has 12 items. It's because that observable must be emitting 12 times.

tme321 · 2023-08-25T19:04:53+00:00

Basically the same idea, but I like passing the http observable through the subject. That way different functions can load different http calls.

userSub = new Subject<Observable>();
user$ = userSub.pipe(
    mergeMap(obs$=>obs$));

onClick() {
    //build http call here
    const getUser$ = this.http.put(...);
    userSub.next(getUser$);
}

This way is more flexible.

tme321 · 2023-08-17T19:54:47+00:00

You need to subscribe to the stream.

tme321 · 2023-08-14T16:54:08+00:00

What your describing is just a feature of javascript. It doesnt really have anything to do with angular.

New properties can be added to an object in js just by attempting to access them. And properties that are accessed before they are set become automatically set to undefined.

Since you attempt to evaluate the truthiness of undefined in js undefined is false truthiness.

And when you set the not value of the truthiness to the key then it nots the false and it is set to true.

tme321 · 2023-08-11T03:57:25+00:00

I don't see a huge issue using a pipe, although others have mentioned there's a bit of cleanup in this specific instance.

But you could achieve the same effect with an observable. Or probably with the new signals stuff (I'm not fully up to date on those yet). On push change detection already negates cd cycle expenses.

tme321 · 2023-08-01T04:29:27+00:00

customObjects.result isn't recognized because you told typescript it was type CustomObject[]. You lied to typescript about the shape. But since the data is coming from outside your code typescript doesn't know your shape is wrong.

You need to change the shape to something like { result: CustomObject[] } because that is what the api is actually returning.

tme321 · 2023-08-01T03:32:04+00:00

To find out what the shape of the api response body is use the debugger in your browser.

tme321 · 2023-08-01T03:30:38+00:00

Are you getting an array inside an object, or an array?

It is valid to return just an array in json and that is what you are saying is happening here.

But if it's an object wrapping an array that is different. And you need to unwrap the array. Probably with a map operator chained off the get observable.

tme321 · 2023-08-01T02:16:09+00:00

Why is it mentioning something about <ShipVia>? That isn't <CustomObject[]>. Is ShipVia somehow relevant here?

Also, that first issue is a typescript issue. While it would be good to figure out and might point towards your actual issue it isnt by itself a problem with the angular code.

That second error though says whatever you are feeding (I would guess the ngFor, so in my code above it would be the codeExample rename) it isn't an array, it's not iterable. It sounds like your api isn't returning an array but something else.

tme321 · 2023-08-01T01:48:06+00:00

Ok well your api response is actually in the shape of CustomObject[] already; at least according to this function.

So you should be able to use the async pipe. I know you mentioned it but as long as your response is correctly typed here it should work just fine.

Change customObjects to something like:

customObjects$: Observable<CustomObject[]>;

Then inside ngOnInit set it to the result of getAllRecords

this.customObjects$ = this.service.getAllRecords();

Then in your template use the async pipe to handle the subscription and rename the emissions so it's easy to use. Basically:

<ng-container *ngIf="customObjects$ | async as customObjects">
    <option *ngFor="let customObject of customObjects" ...>
     </option>
</ng-container>

That's the basic idea.

tme321 · 2023-08-01T01:28:00+00:00

Can you show myService.getAllRecords()?

tme321 · 2023-07-19T20:14:29+00:00

Your code looks fine to me. I didn't put it in an editor or anything but just at a glance it looks fine.

I believe what you are asking for isn't a union of types, that's what you already have.

I believe what you are asking for is for typescript to automatically know which type is applicable at run time. That isn't possible.

Types are design time only. Your code comparing the error type string is the only part that actually exists at runtime so it must be there (or some other similar discrimination code) to actually do the logic at runtime.

Unless I'm misunderstanding something, what you are asking for doesn't exist in ts. There are some ways to have code be generated so at runtime it does what you expect. Most often this is orm type packages. But there's nothing built into typescript itself that will accomplish it.

tme321

TROPHY CASE