-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Hide repository creation if they are not custom + add upsert support by default #6127
chore: Hide repository creation if they are not custom + add upsert support by default #6127
Conversation
…upport by default
🦋 Changeset detectedLatest commit: e394e44 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Ignored Deployments
|
@srindom here is what it would look like on the product module for the example. We are putting all the repositories that do not have any custom logic into the container directly. @olivermrbl here you can also have a look to the default upsert implementation. Also, I am wondering why we have done it manually and we haven't used upsertMany. But for now I ve kept it as it is and I ll see later |
Also seb, here as you can see I ve changed the way the integration tests are loading the service they are trying to test. The same could be done for the unit tests. In that case, we wouldn't need any default constructor for our usage as we would never instanciate them manually. wdyt? |
A few thoughts: The goal is to minimize the amount of boilerplate needed to setup new data models and start defining business logic around them. Right now, you have to do the following: a) create the model, b) create a repository file where you export a repository, c) ensure that the repository is registered in the container, d) create a service where you use the repository and specify your business logic. I would argue that b and c could be eliminated altogether for the standard case where you don't want to define anything custom. Instead you simply do: a) create your data model, b) create a service using the abstractServiceFactory. The service can use the associated data model to create the repository on the fly instead of having the repository live in the dependency container. I think we can even go further with this idea to when you want to customize things in the service layer. You create your data model and create your service with the abstractServiceFactory. The abstract service factory could ensure that there is a
If you want to do custom repository methods you can create a repository file, but I would even argue that in that case you should just pass it directly to Let me know what you think? |
I see what you mean now @srindom , in the next proposal i was about to extract the loader container logic since most of it is repetitive and can be inferred from the entity with some naming conventions that we already have. Going back to something instanciated from within the service instead of using the DI will make it hard to test. If i want to mock the inner repository then i have to play with lot of mock to reach that goal, it is one of the problem solved by the DI. In my next proposal, the only thing you have to do is create your service and thats it, to type the repo property you can just play with the RepositoryService interface. If you want a custom repository, you create a new file and thats it, it will be loaded automatically since it follows the naming conventions. Note: it doesn't requires any file reading or anything just to be explicit |
@srindom @olivermrbl wdyt of this commit does that correspond to what you expected? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is epic <3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
packages/utils/src/modules-sdk/loaders/container-loader-factory.ts
Outdated
Show resolved
Hide resolved
|
||
const upsertedEntities: T[] = [] | ||
const createdEntities: T[] = [] | ||
const updatedEntities: T[] = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the upsert we have to return all these 3 as a tuple.
they will be used to emit different events for insert and update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, for now I thought keeping it like this to not increase the changes number, but we will still have them available for the changes when we have the event normalisation ready
@fPolic @pKorsholm if you can have a look when you are free, I am only missing your view before being able to merge 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @adrien2p 💪
Merging now – @pKorsholm hope it's OK. @adrien2p can get you up to speed later |
What