Tuesday, October 31, 2017

Singleton pattern in Angular 4 apps?

I don't want to go to the database every time I display a dropdown list full of app administrators when the names in that list change so infrequently. I thus need to store some state on an object so that I may only call out to the database once, store the state, and then see the dropdown list for a second time in my wanderings of the app without going to the database a second time. Alright, to facilitate this, a coworker has made a model (TypeScript class) for holding singleton gunk and he loops it (an instance of the class) in at the constructor signatures of components. How does he keep the state when a new component is reached or the route is changed breaking with a strict SPA approach? What stops one controller from stepping on top of another and newing up a new singleton state object? If the outermost module loops in the singleton model as a provider or perhaps as one of many singleton objects in an array of objects, then the model will not step on itself at different constructor signatures. Something behind the scenes keeps the singleton nature from being sabotaged. I haven't written the code myself. This is my understanding. Also, you don't want to have spaghetti gunk in all of your controllers to check to see if a property on the singleton state object is truthy or falsey before using it and if falsey, and ONLY then, hydrating it from the database before returning it. Instead you should make your own miniservices for these mechanics. They are dubbed "resolvers" in the app I am currently working on.

No comments:

Post a Comment