-
Notifications
You must be signed in to change notification settings - Fork 4
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
[DSDK-178] [TS] [SDK] Setup InversifyJS and SOLID conventions #9
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
39d60ca
to
4be158a
Compare
packages/core/src/internal/config/data/LocalConfigDataSource.ts
Outdated
Show resolved
Hide resolved
packages/core/src/internal/config/data/RemoteConfigDataSource.ts
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,6 @@ | |||
// Domain scoped types | |||
|
|||
export type Config = { |
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.
[ASK] Wrong package. Should be in api/
?
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.
Discussed with @mbertin-ledger and we decided to put it in the model
folder for domain types
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.
IMHO this is no sense as this object is exposed to the app (which is considered as the future client of the SDK). Let's discuss with the team if you prefer 😉
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.
I just see the UseCase
is also exposed. In the future I don't think this will be like that. IMHO it misses a component acting as a bridge between the app
and the sdk
(cf. https://github.com/LedgerHQ/device-sdk-mobile/blob/develop/sdk/src/main/java/com/ledger/devicesdk/sdk/LedgerDeviceSDK.kt)
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.
Good first Clean Archi and SOLID implementation. Just a few comments 🙂
export interface LocalConfigDataSource { | ||
getConfig(): Config; | ||
} | ||
|
||
export interface RemoteConfigDataSource { |
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.
[ASK] 100% personal but I prefer creating 2 distincts files to make the navigation in the project easier
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.
I don't have a strong opinion here, we decided to set it up this way with @mbertin-ledger, but let's ask everyone what they think ?
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.
Same as @smartine-ledger, I prefer 2 files
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.
Same I prefer 2 files
packages/core/src/internal/config/data/LocalConfigDataSource.ts
Outdated
Show resolved
Hide resolved
packages/core/src/internal/config/data/RemoteConfigDataSource.test.ts
Outdated
Show resolved
Hide resolved
bind(types.RemoteConfigDataSource).to(RestRemoteConfigDataSource); | ||
bind(types.GetSDKVersionUseCase).to(GetSDKVersionUseCase); | ||
bind(types.ConfigService).to(DefaultConfigService); |
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.
[SHOULD] Single Responsability Principle Violation. Consider creating different files 😉
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.
Not sure what do you mean here, the only responsibility is initialising the ContainerModule.
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.
Right. But all containers should not be initialising in the same file. If you do you are creating a god object.
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.
Again, not use I understand, as here we are only initialising the config
module, which is loaded in src/di.ts
file
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.
you are not just initialising the config
but also the datasources
and the usecases
. It is not a big deal for the moment but this will in a big app.
I think you will understand my point when we have much more component to initialise 😉
packages/core/src/internal/config/data/LocalConfigDataSource.ts
Outdated
Show resolved
Hide resolved
expect(mod).toBeDefined(); | ||
}); | ||
|
||
it("should return none mocked data sources", () => { |
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.
[ASK] What about adding GIVEN
WHEN
THEN
comments like suggested here ?
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 more pseudo language for tests like Cucumber / Gherkin tests. Also, more oriented toward E2E test in my opinion
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.
yeah we need to see how we will integrate Cucumber / Gherkin tests - i agree I don't think it's necessary to have those pseudo language inside unit tests
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.
Already discussed about that with @mbertin-ledger and I disagree adding this kind of comments 👍 . It's too verbose
import { inject, injectable } from "inversify"; | ||
import "reflect-metadata"; | ||
import { ConfigService } from "./ConfigService"; | ||
import { types } from "../di/configTypes"; |
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.
[ASK] How about avoiding relative imports?
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.
I currently don't have the setup for aliases in TS.
However as I said, I was never a big fan on them, but I won't be against it if it's something we agree upon
Nice PR overall, just one change requested regarding |
17066cf
to
a396ebb
Compare
a396ebb
to
2ba743e
Compare
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.
Great setup PR ! thx 🦖
ac9d800
to
353e17b
Compare
packages/core/src/internal/config/data/LocalConfigDataSource.stub.ts
Outdated
Show resolved
Hide resolved
353e17b
to
fcb5a41
Compare
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.
great job 🙏
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 great setup 🙌
[SHOULD] delete root |
fcb5a41
to
44c6e39
Compare
44c6e39
to
4f1ead8
Compare
📝 Description
This PR aims to bring the setup for InversifyJS following the SOLID principles.
There is a new internal
config
module that can be used as an example to implement new modules.To make it easier there is a
module:init
script in thecore
package.json.From the root
Explanation of each folder in the
config
moduleconfig
)Each file is provided with an example of unit test, and there is coverage (only scoped to
src/internal
for now but we widen it as we progress in the development process❓ Context
🧐 Checklist for the PR Reviewers