-
Notifications
You must be signed in to change notification settings - Fork 137
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
[Woo POS][Non-Simple Products] Remove null price check on Products and Variations screen #13312
Changes from 11 commits
3534925
1695808
6be3917
cc201eb
f62b5fe
8271098
a61c31e
5e38fc5
243579b
601ad2e
9dfff65
57c3d64
a953166
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,6 +12,7 @@ sealed class WooPosTotalsViewState : Parcelable { | |
val orderTaxText: String, | ||
val orderTotalText: String, | ||
val readerStatus: ReaderStatus, | ||
val isFreeOrder: Boolean, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 The UI doesn’t really care if the order is free; it only cares whether the reader status is shown or hidden. The state model would be cleaner and more readable if, instead of adding an isFreeOrder property to WooPosTotalsViewState, we changed ReaderStatus to reflect when we don’t want it displayed. For example, we could add a data object Hidden: ReaderStatus() subclass, rather than relying on WooPosTotalsViewState.isFreeOrder. This approach would also simplify the UI code. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 It would also be great to add a unit test for orders that include only free products. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After thinking more about this, I feel adding a new
We could probably rename There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Feel free to take the approach you think is best 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
) : WooPosTotalsViewState() | ||
|
||
data class PaymentSuccess(val orderTotalText: String) : WooPosTotalsViewState() | ||
|
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 suggest using
>
and<
operators directly improve code readability.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 believe this approach won't work in all cases when dealing with BigDecimal, because these operators internally rely on the exact scale of the BigDecimal values during comparisons. For example:
If totalAmount is BigDecimal("0.00"), it may not behave as expected when compared to BigDecimal.ZERO using > or <, as the comparison might fail due to scale differences.
Using .compareTo(BigDecimal.ZERO) is more robust because it ignores scale differences and focuses solely on the numerical value, ensuring consistent behaviour regardless of how totalAmount is constructed (e.g., 0.00 vs. 0).
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 think this is not true, according to docs:
As a result, using comparison operators translates to the same call to the
compareTo()
function that is used currently.You can verify that by CMD-clicking the comparison operator (
>
) – it will redirect to the underlyingcompareTo
function implementation in Kotlin std lib.I suggest using comparisons like that:
which compiles to:
Let me know what you think or if I'm missing something @AnirudhBhat.
💡 Another improvement would be to add a null check (throw IllegalStateException in case
orderTotal
) instead of allowing such illegal state in code (comparing potentially null value which will result in NPE thrown fromcompareTo
function anyway, but throwing it earlier would make potential bug easier to debug).