-
Notifications
You must be signed in to change notification settings - Fork 324
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
[LIVE-10952][Common] Refactoring of list apps #6055
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
4 Ignored Deployments
|
@@ -0,0 +1,23 @@ | |||
import { DeviceInfoEntity } from "../entities/DeviceInfoEntity"; | |||
|
|||
export const PROVIDERS: Record<string, number> = { |
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.
could be an enum which also stores the default provider 1
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 it could 👍 do you see an advantage of making it an enum ?
I will add the default provider regardless, good point!
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.
actually using an enum breaks some tests because then you can do access stuff with an index like PROVIDERS[1] and then stuff like this behaves in an unwanted way:
const providerName = PROVIDERS[postDash] ? postDash : null;
cf. this test run https://github.com/LedgerHQ/ledger-live/actions/runs/7755719007/job/21151656301
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.
Well the only advantage I see of making it an enum is the implicit typing.
I prefer using enum for readability and I was pretty sure that this behaviour was the same for a const or an enum.
Nevertheless LGTM 👍
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.
it's not the same behaviour because enum[x] is a reverse mapping (it maps from value to name) https://www.typescriptlang.org/docs/handbook/enums.html#reverse-mappings
cf playground:
(I didn't know this playground by the way, nice one)
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.
nice 👍
34830ce
to
093cb1f
Compare
d9d5116
to
0cba9b2
Compare
602f2df
to
4f1371f
Compare
test(common/listApps/v2): more error cases
chore: changeset
fix: imports fix: lint & bad import fix(llm): bad import
fix(getProviderIdUseCase): revert breaking change to an enum
fix(HttpManagerApiRepository): missing type + reword comment
90d4ff7
to
095587b
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.
i see the creation of a new folder "device-core" in live-common, could you consider instead making a new library like "live-device-core" or even just "device-core" ?
we are taking a general direction to not add more logic into live-common but instead moving them out into dedicated library (e.g. live-countervalues, live-nft, ...)
by doing so, you can activate stricter version of typescript config that also help improving the quality. it's also a game changer for the decoupling of our stack
@gre yes that's the direction we're taking, we will probably do this in a subsequent PR |
@@ -10,7 +13,7 @@ export interface ManagerApiRepository { | |||
userId: string; | |||
}): Promise<OsuFirmware | null | undefined>; | |||
|
|||
fetchMcus(): Promise<any>; | |||
fetchMcus(): Promise<any>; // TODO: type properly |
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.
Why not now?
[LIVE-10952][Common] Refactoring of list apps
[LIVE-10952][Common] Refactoring of list apps
📝 Description
listApps
tolive-common/src/device/use-cases/listAppsUseCase.ts
manager/api.ts
logic toManagerApiRepository
StubManagerApiRepository
for mockslistApps/v2.ts
getProviderIdUseCase
that takesforceProvider: number
as a parameter❓ Context
✅ Checklist
Pull Requests must pass the CI and be code reviewed. Set as Draft if the PR is not ready.
npx changeset
was attached.🧐 Checklist for the PR Reviewers