Issue
In my angular app I have implemented user auth and a recipe library that is tied to each user's account. For this I have a AuthService and a RecipeService, but since I want the user recipes to be tied to the loggedin user, I'm not sure what the best practice is to check auth in this scenario. The way I see there's two options:
inject AuthService in RecipeService and save the loggedin user so that I could just make the methods require a user ID parameter, therby creating a dependency
keep services decoupled, but always require a userId parameter for getting recipeData, meaning many components will have to get both AuthService and RecipeService injected, instead of just RecipeService.
I feel like both can work, but is there a preferred way/rule with this kind of thing? My goal is to understand the decision process in general with situation like these, not necessarily only to solve this particular problem.
I went the decoupled route, but I find myself often repeating the process getting user (or caching it for component) -> then nesting another request for recipe like:
this.itsAuthService.getUser().subscribe((user) => {
const aRecipeID = uid();
const aRecipe:Recipe = {
...
}
this.itsStorageRef = ref(this.itsFStorage, `recipes/${user?.uid}/${aRecipeID}`);
if(user!= null){
uploadBytes(this.itsStorageRef, this.itsImgFile).then((result) => {
this.itsRecipeService.createRecipe(user?.uid, aRecipe, aRecipeID).then(() => {
console.log("Recipe saved.")
});
})
}
})
Solution
There are as many approaches as there are developers, you just have to find your own.
Here are the most common ones :
(Assuming you have user service, recipe service, and http/firebase service)
1 - each service handles his own feature : no service depends on another one. To combine them, you do it manually everytime you need it.
2 - same as approach 1, but instead of doign it manually, you create a fourth service that combines all 3 of them, and you only use this service, not the other ones.
3 - You declare higher order services and lower order ones : the higher can't inject depdendencies, and lower inject higher ones. Here, your recipe inject user and http, but user and http don't inject anything (except the absolute necessary ones).
Each approach has its own perks and drawbacks :
1 - total decoupling and reusability, but tideous
2 - Same as one, but you add "business" services that cannot be reused
3 - Thight coupling but quick to do and less code required
You also have to understand : reusability is very subjective. LinkedIn ayatollahs will scream at you if you do not use method 1, but the reality is that you probably won't need to reuse your services elsewhere than your own project.
For instance, if tommorow you do a mechanics application, do you really need to reuse your recipe service ? If you change your backend / auth method, do you need to use your user service ? If you switch to websockets, do you still need your http service ?
Seeking reusability is always a thing to do, but you also have to determine when it's useful, rather than detrimental.
As always, this is the point of view of some random dude on the Internet, so don't take this is an absolute rule you have to follow !
Answered By - MGX
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.