Skip to content
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

Merged
merged 4 commits into from
Jan 25, 2024

Conversation

valpinkman
Copy link
Member

@valpinkman valpinkman commented Jan 23, 2024

📝 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 the core package.json.

From the root

pnpm core module:init moduleName

Explanation of each folder in the config module

  • data: different data sources and their implementation
  • service: (or repository) provide business logic, uses the data sources
  • usecase: used in the public API, uses the services
  • model: different types used by our domain (here config)
  • di: where all the binding for the dependency injection is done

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

  • The code aligns with the requirements described in the linked JIRA or GitHub issue.
  • The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
  • There are no undocumented trade-offs, technical debt, or maintainability issues.
  • The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
  • Any new dependencies have been justified and documented.

Copy link

vercel bot commented Jan 23, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
device-sdk-ts-sample ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 24, 2024 3:48pm

packages/core/src/internal/config/service/ConfigService.ts Outdated Show resolved Hide resolved
@@ -0,0 +1,6 @@
// Domain scoped types

export type Config = {

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/ ?

Copy link
Member Author

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

Copy link

@smartine-ledger smartine-ledger Jan 24, 2024

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 😉

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)

Copy link

@smartine-ledger smartine-ledger left a 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 🙂

Comment on lines +5 to +9
export interface LocalConfigDataSource {
getConfig(): Config;
}

export interface RemoteConfigDataSource {

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

Copy link
Member Author

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 ?

Copy link
Contributor

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

Copy link
Contributor

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

Comment on lines 19 to 21
bind(types.RemoteConfigDataSource).to(RestRemoteConfigDataSource);
bind(types.GetSDKVersionUseCase).to(GetSDKVersionUseCase);
bind(types.ConfigService).to(DefaultConfigService);

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 😉

Copy link
Member Author

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.

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.

Copy link
Member Author

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

Copy link

@smartine-ledger smartine-ledger Jan 25, 2024

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/di.ts Outdated Show resolved Hide resolved
expect(mod).toBeDefined();
});

it("should return none mocked data sources", () => {
Copy link
Contributor

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 ?

Copy link
Member Author

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

Copy link
Contributor

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

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";
Copy link
Contributor

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?

Copy link
Member Author

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

@aussedatlo
Copy link
Contributor

Nice PR overall, just one change requested regarding reflect-metadata imports. 👍

Copy link
Contributor

@alexandremgo alexandremgo left a 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 🦖

Copy link
Contributor

@ofreyssinet-ledger ofreyssinet-ledger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great job 🙏

Copy link
Contributor

@jdabbech-ledger jdabbech-ledger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM great setup 🙌

@jdabbech-ledger
Copy link
Contributor

[SHOULD] delete root tests folder as test module files are in use

@valpinkman valpinkman merged commit 4138604 into develop Jan 25, 2024
4 checks passed
@valpinkman valpinkman deleted the chore/clean-archi branch January 25, 2024 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants