🚀 - Providing a doc to explain how to handle subrepositories
bdebon opened this issue · 10 comments
Which @angular-ru/* package(s) are relevant/releated to the feature request?
No response
Description
The current doc is super synthetic and easy to understand, I really appreciate the care you wrote the doc with.
Nevertheless, there is one thing I still can't figure out and it creates a lot of debate in the frontend team of my company.
We have a repository for our main Entity called Application.
This Entity has many children collections, which means many child repositories eg: Commits, Logs, Messages...
For now, we have decided to create as many repositories as the number of different entities we have. And they are all on the same level. We don't really know how to create this mother/child relationship between our entities.
When we are fetching an application, we are also fetching all the children entities linked to this application (one API call for commits, one API call for logs, one API call for messages, etc).
But when we change the application, we then have to empty the children collections manually to make room for the children entities of the new application?
Or do we have to add a key inside the children to indicate who the parent entity is?
Or...?
Is the problem clear or do I need to develop it more with a concrete example?
You can make your PRs for help us)
I would like to PR the solution the problem is I have no clue about the good solution here. We are right now struggling on how to deal with this pattern. Do you have an idea how to handle this architecture?
I don't have experience with child states) I don't like them. If you know best practices, you can explain it
I would love to use any best practice provided here. So far I have followed all the best practices I could find in the doc, and I put a lot of effort understanding it because in the end we are always winner when we follow it. But for this case like, I don't see a good practice provided and it's definitely a common use case so I feel like the doc should have a word about it.
But if I understand well your statement, you think that all our states should be on an equal level and that we should not try to create mother/children relationship between our different states even if in real life they really have this relationship.
Maybe what I say is unclear and I should provide you a concrete example.
The parent / main model that I received from the back end looks like this :
Application
-Id
-Name
-Etc...
But on the same page as the application page, i also have to query commits or logs that are received like this from the API :
Commits
-Id
-ContributorName
-Etc...
Logs
-Id
-Format
-Etc...
My problem is to be able to select those commits or logs given an application id with the benefits of still using entities state operators helpers (like in any entity state manager like @ngrx/entity package) from NGXS data like addOne, removeOne etc etc... I do not want to fall into the trap of having to do all those operations by myself like i did in the past with spread operators and stuff.
Currently my commit state looks like this :
export interface EntityStateDictionnary<T> {
[key: string]: Dictionary<T>
}
const applicationCommitsInitialState: EntityStateDictionnary<ApplicationCommit[]> = {
commits: null,
}
this.patchState({
commits: {
...this.getState().commits,
[`${appId}`]: applicationCommits,
},
})
How would you architecture the store given such models, knowing that the application models has more than 20 API calls related to it ?
you think that all our states should be on an equal level and that we should not try to create mother/children relationship between our different states even if in real life they really have this relationship.
Maybe what I say is unclear and I should provide you a concrete example.
Yes, equal level is good!
this.patchState({
commits: {
...this.getState().commits,
[`${appId}`]: applicationCommits,
},
})
sounds good
but with this approach we don't really consider commits as repository, we can't use selectAll, addMany, updateOne, etc... that's a real drawback...
Unfortunately, I have not come across such a case, perhaps you will be able to give cool examples and good practices. Always happy with new PR from community
We will do our best to provide good example because we really love this library and it really helped us to remove thousands lines of code. We have just this last case that is a little bit tricky and we don't agree too much on the different solutions we found in the team.
I am more for everything on the same level in a way that we keep all the power of your library but the problem with this, as soon as we change the current entity we are browsing, we have to flush all the other child collections to be able to store the new children collections of the new entity. We can't keep the previously fetched API data. We constantly need to refetch the children data as soon as we change the current parent. It is easier on front-end side but it induces more pressure on the api.