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

Refactoring NotificationsProvider #319

Merged
merged 14 commits into from
May 10, 2024
Merged

Refactoring NotificationsProvider #319

merged 14 commits into from
May 10, 2024

Conversation

ruixhuang
Copy link
Contributor

No new code, just breaking down NotificationsProvider to multiple provider objects. I am going to add notification logic for the TP/SL trigger order status, so it's better to refactor the code first.

@prashanDYDX
Copy link
Contributor

This seems like a great opportunity to add tests. If adding tests is difficult/annoying, I think that's a code smell that there are better ways to architect our objects (pointed out some potential improvements in my other comments) that we should address now since we're refactoring anyways. Happy to help brainstorm here.

DEF004F52F2F2D30519CC77F4A88FEF2 /* Support Files */,
);
name = abacus;
path = "/Users/ruihuang/v4-abacus";
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm do we want this checked in?


val title =
uiImplementations.localizer?.localize("$statusNotificationStringKey.TITLE")
?: return null
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably want guard clauses at the top of the method

@ruixhuang
Copy link
Contributor Author

This seems like a great opportunity to add tests. If adding tests is difficult/annoying, I think that's a code smell that there are better ways to architect our objects (pointed out some potential improvements in my other comments) that we should address now since we're refactoring anyways. Happy to help brainstorm here.

This PR is intended to do a minimal refactor to unblock upcoming feature work, so we are relying on existing tests. If additional tests are needed or they should be architected differently, please create tickets so we can prioritize them in the future.

@prashanDYDX
Copy link
Contributor

This seems like a great opportunity to add tests. If adding tests is difficult/annoying, I think that's a code smell that there are better ways to architect our objects (pointed out some potential improvements in my other comments) that we should address now since we're refactoring anyways. Happy to help brainstorm here.

This PR is intended to do a minimal refactor to unblock upcoming feature work, so we are relying on existing tests. If additional tests are needed or they should be architected differently, please create tickets so we can prioritize them in the future.

Oh okay great, I didn't realize there were already tests for this logic.

private val parser: ParserProtocol,
private val jsonEncoder: JsonEncoder,
private val useParentSubaccount: Boolean = false,
private val providers: List<NotificationsProviderProtocol> = listOf(
Copy link
Contributor

@prashanDYDX prashanDYDX Apr 29, 2024

Choose a reason for hiding this comment

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

I would remove this default value, so that we can remove the transitive dependencies from NotificationsProvider (stateMachine, uiImplementations, environment, jsonEncoder, parser, etc)

Objects should only inject dependencies that they use directly. This makes testing much easier and simpler.

detekt.yml Outdated Show resolved Hide resolved
# Conflicts:
#	integration/iOS/Pods/Pods.xcodeproj/project.pbxproj
# Conflicts:
#	build.gradle.kts
#	integration/iOS/Pods/Pods.xcodeproj/project.pbxproj
#	src/commonMain/kotlin/exchange.dydx.abacus/state/manager/StateManagerAdaptor.kt
#	src/commonMain/kotlin/exchange.dydx.abacus/state/v2/supervisor/SubaccountSupervisor.kt
#	v4_abacus.podspec
@ruixhuang ruixhuang merged commit e050f64 into main May 10, 2024
3 checks passed
@ruixhuang ruixhuang deleted the features/notification branch May 10, 2024 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants