-
Notifications
You must be signed in to change notification settings - Fork 133
[CIAB] A minor refactoring to avoid leaking the booking status to UI layer #14667
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
Conversation
override val key = "complete" | ||
} | ||
|
||
data class Unknown(override val key: String) : Status |
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 know I mentioned I don't like having an Unknown
value, but after thinking more about this and knowing how flexible WordPress is, I decided to go for the safest approach here.
We can revisit when next-admin implements logic for displaying badges, and see if we need to modify something to align, WDYT?
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.
Sounds good 👍
val localTimezone: String | ||
) | ||
) { | ||
sealed interface Status { |
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 named this Status
and not PaymentStatus
as this seems related more to the booking status and not just payment (for example cancelled
is not really a payment status).
I wonder if we should rename the UI model too or not, WDYT?
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.
At the time, I thought this was the order payment status, but it looks like it's not so yeah the name change makes sense.
It's still a bit confusing to me, because we can have two cancelled
status tags next to each other (attendance and this 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.
It's still a bit confusing to me, because we can have two cancelled status tags next to each other (attendance and this one) 🤔
As discussed yesterday in the call, the cancelled
status for the attendance is just a presentation status, it happens only when the booking itself is also cancelled.
but it looks like it's not so yeah the name change makes sense.
Sounds good, I'll rename the UI model too.
@AdamGrzybkowski while working on this, I noticed |
📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.
|
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.
Thanks for the changes!
val localTimezone: String | ||
) | ||
) { | ||
sealed interface Status { |
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.
At the time, I thought this was the order payment status, but it looks like it's not so yeah the name change makes sense.
It's still a bit confusing to me, because we can have two cancelled
status tags next to each other (attendance and this one) 🤔
override val key = "complete" | ||
} | ||
|
||
data class Unknown(override val key: String) : Status |
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.
Sounds good 👍
BookingPaymentStatus.Paid -> stringResource(R.string.booking_payment_status_paid) | ||
BookingPaymentStatus.Cancelled -> stringResource(R.string.booking_payment_status_cancelled) | ||
BookingPaymentStatus.Complete -> stringResource(R.string.booking_payment_status_complete) | ||
is BookingPaymentStatus.Unknown -> key |
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 if there's a better alternative, but just leaving a comment that this caught my attention. Displaying the raw values to the user could be risky, but it would be very handy at spotting the issue for us. One alternative I can think of would be to hide the badge completely.
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.
Displaying the raw values to the user could be risky
Not necessarly risky, for example for orders, WordPress has plugins that adds custom statuses, and for those we display the raw keys when there is no label, as this is what wp-admin does, and that's what the users are used too.
So I said, I think we need to revisit this when next-admin adds the logic for the badges.
) | ||
} | ||
|
||
private fun BookingEntity.Status.toUiModel(): BookingPaymentStatus = when (this) { |
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 don't have to do this now, but we will need the same mappings in the details screen, so we could start putting those in a separate file, so they are available for reuse.
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, this is something we need, a proper mapper class would be useful for reusability.
Makes sense, I guess. Feel free to rename in this PR, or we can do it later. |
62ea539
to
fdd2d59
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #14667 +/- ##
============================================
- Coverage 38.42% 38.42% -0.01%
Complexity 9818 9818
============================================
Files 2089 2089
Lines 116528 116546 +18
Branches 15575 15592 +17
============================================
- Hits 44778 44777 -1
- Misses 67597 67612 +15
- Partials 4153 4157 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Description
As per the previous discussion, this PR introduces a model in the DB layer that maps to the API status keys, which avoids leaking this information to the UI layer.
Please feel free to share any thoughts or suggestions for improvement here.
Testing information
Code review should be enough, but small test to confirm there is no regression would be fine.
RELEASE-NOTES.txt
if necessary. Use the "[Internal]" label for non-user-facing changes.