-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃殌 - Providing a doc to explain how to handle subrepositories #1065
Comments
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. |
The parent / main model that I received from the back end looks like this :
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 :
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 :
How would you architecture the store given such models, knowing that the application models has more than 20 API calls related to it ? |
Yes, equal level is good! |
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. |
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?
The text was updated successfully, but these errors were encountered: