Well, where I have seen this happen is in an Angular 4 application using NgRx for the store stuff though NgRx really has little to do with it. In the circumstances I have seen there will be a call to a selector in an ngOnInit, ngChanges, or constructor of an Angular component, and the fact that this lifecycle hook is being hit more than once is at first invisible and then must be troubleshot over time as it turns out something is wrong. This can come from a component being instantiated anew in, for example, the case of the constructor, and one way to keep that pain from being pervasive is to adopt a pattern that uses smart and dumb components and only have the outermost actor in the Russian doll hierarchy speak to the store. If you are breaking with as much, you may want to keep an identifier for selecting with a selector such as the unique id for a record or a string for a search term in a private field inside of the component and only call the selector if the term has changed since the last time the attempt was made. (Wall it off with some if statement logic.) Obviously, an initial attempt will have a different find-with-me key than a null value. This should not work with a constructor if the component is really getting instantiated anew I suppose. In the case of the particular application I am working on I'm not sure what gives. This has a thread on a scenario in which a constructor for a component can run twice if the component is just bootstrapped badly. That seems buggy. If you are calling out to a selector from ngOnChanges you may use SimpleChanges to filter which inputs have been updated and only react when applicable in the name of not redundantly going to the API. That makes me happy.
No comments:
Post a Comment