Skip to content

Conversation

@irfano
Copy link
Contributor

@irfano irfano commented Oct 8, 2025

Part of

Description

This PR adds the filter screen UI, it doesn’t include the filtering logic or sub-screens.

I aimed to align it with the current Order filter screen design.

Steps to reproduce

  1. Use a CIAB site.
  2. Manually install the bookings plugin from this ZIP file: p1758531103469849/1758101141.913349-slack-C03L1NF1EA3
  3. You'll need to enable bookings v2 on your CIAB testing site. You can do that by installing the Code Snippets plugin to your site and adding the following PHP snippet: define( 'WC_BOOKINGS_NEXT_ENABLED', true );
  4. Navigate to Bookings.
  5. Change the tab to All.
  6. Tap the Filters button.

The tests that have been performed

Screens below.

Images/gif

Screenshot_20251008_031924 Screenshot_20251008_032022 Screenshot_20251008_031904

Screenshot_20251008_032030
  • I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

@dangermattic
Copy link
Collaborator

dangermattic commented Oct 8, 2025

2 Warnings
⚠️ This PR is larger than 300 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.
⚠️ Class BookingFilterListViewModel is missing tests, but unit-tests-exemption label was set to ignore this.

Generated by 🚫 Danger

@wpmobilebot
Copy link
Collaborator

wpmobilebot commented Oct 8, 2025

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.
App NameWooCommerce-Wear Android
Platform⌚️ Wear OS
FlavorJalapeno
Build TypeDebug
Commit5d3d83c
Direct Downloadwoocommerce-wear-prototype-build-pr14719-5d3d83c.apk

@wpmobilebot
Copy link
Collaborator

wpmobilebot commented Oct 8, 2025

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

App NameWooCommerce Android
Platform📱 Mobile
FlavorJalapeno
Build TypeDebug
Commit5d3d83c
Direct Downloadwoocommerce-prototype-build-pr14719-5d3d83c.apk

Copy link
Contributor

@AdamGrzybkowski AdamGrzybkowski left a comment

Choose a reason for hiding this comment

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

@hichamboushaba Since Irfan is AFK do you want to check my comments? I don't think those are blockers and we can update the code in the following PRs.

BookingFilterListScreen(
state = BookingFilterListViewModel.BookingFilterListUiState(
items = options.orEmpty(),
onClose = { requireActivity().onBackPressedDispatcher.onBackPressed() },
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Shouldn't we use findNavController().popBackStack() for "going back"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, Adam! I agree that using popBackStack() and MultiLiveEvent.Event.Exit fits our current architecture better. Thanks for handling it.

I also added a TODO comment to remind us to handle those actions later: 76a2cec

Copy link
Member

Choose a reason for hiding this comment

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

Given this is called by the app bar navigation button (Up button), we should prefer using navigateUp, it doesn't make any difference for this screen since it can't be deeplinked from outside, but just to follow the best practices 🙂

onClose = { requireActivity().onBackPressedDispatcher.onBackPressed() },
onShowBookings = {
// TODO Pass new filter payload instead of `true`
navigateBackWithResult(BookingListFragment.BOOKINGS_FILTER_RESULT, true)
Copy link
Contributor

Choose a reason for hiding this comment

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

I would consider switching this approach to an in-memory persistence for applied filters exposed as a Flow. This way, we don't have to "return" them. The booking list screen would simply observe them and react to the updates.

@hichamboushaba Thoughts about this?

Copy link
Contributor

@AdamGrzybkowski AdamGrzybkowski Oct 9, 2025

Choose a reason for hiding this comment

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

Some extra thoughts:

One of the cons of this approach would be the extra logic to handle process death. With filters being passed via args we would have this solved by SaveStateHandle for free, with an in-memory filter persistenca that's not the case.

❓ Do we want to persist the filters across app launches?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question. I noticed that we persist the latest filters for orders, so I’d say we should do the same for bookings, unless @hichamboushaba disagrees.

If we all agree to persist it, I’d suggest merging this PR first and handling the persistence in a separate one.

Copy link
Contributor

Choose a reason for hiding this comment

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

oh hi @irfano 👋

If we all agree to persist it, I’d suggest merging this PR first and handling the persistence in a separate one.

Yes, that's obviosly not part of this PR!

I noticed that we persist the latest filters for orders, so I’d say we should do the same for bookings

I noticed it after I asked the question and I agree it would make sense to align.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry folks, I missed the ping about this. I think given it's easy to support persiting filters, we should handle it, we just need to let the iOS folks about this to have a similar feature.

If we add the persistence, I would suggest not returning the filters with navigateBackWithResult, we can just observe them, if we use DataStore for storing the, then we can observe the changes right in the list, and with this we'll have a unique data flow. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Also, @irfano go and enjoy your AFK 😄, we'll take it from here for this PR.

Copy link
Contributor

@AdamGrzybkowski AdamGrzybkowski Oct 9, 2025

Choose a reason for hiding this comment

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

If we add the persistence, I would suggest not returning the filters with navigateBackWithResult

Yup, it's already removed in this PR.

we can just observe them, if we use DataStore for storing the, then we can observe the changes right in the list, and with this we'll have a unique data flow. WDYT?

Yes, I already have a working code. Will open a PR soon.

@codecov-commenter
Copy link

codecov-commenter commented Oct 9, 2025

Codecov Report

❌ Patch coverage is 0% with 58 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.41%. Comparing base (d8fe4c0) to head (5d3d83c).
⚠️ Report is 14 commits behind head on trunk.

Files with missing lines Patch % Lines
...d/ui/bookings/filter/BookingFilterListViewModel.kt 0.00% 42 Missing ⚠️
...twork/rest/wpcom/wc/bookings/BookingsRestClient.kt 0.00% 13 Missing ⚠️
...e/android/ui/bookings/list/BookingListViewModel.kt 0.00% 2 Missing ⚠️
...ork/rest/wpcom/wc/bookings/BookingsFilterOption.kt 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##              trunk   #14719      +/-   ##
============================================
- Coverage     38.43%   38.41%   -0.02%     
- Complexity     9887     9888       +1     
============================================
  Files          2105     2106       +1     
  Lines        117088   117138      +50     
  Branches      15646    15659      +13     
============================================
+ Hits          45001    45002       +1     
- Misses        67914    67964      +50     
+ Partials       4173     4172       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@AdamGrzybkowski
Copy link
Contributor

@hichamboushaba Since I've added some code here, do you want to assign yourself and review, or should I approve this myself? :D

Copy link
Member

@hichamboushaba hichamboushaba left a comment

Choose a reason for hiding this comment

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

Looks good, nice work.
I've reviewed just your changes @AdamGrzybkowski, given you reviewed the other changes.

onShowBookings = ::onShowBookings
)
)
val uiState = _uiState.asLiveData(viewModelScope.coroutineContext)
Copy link
Member

Choose a reason for hiding this comment

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

np, is there a reason we are passing a specific coroutine context here? asLiveData already uses Dispatchers.Main.immediate by default, so I don't think this has any effect.

Copy link
Contributor

@AdamGrzybkowski AdamGrzybkowski Oct 9, 2025

Choose a reason for hiding this comment

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

Good catch - I missed it. Removed in 5d3d83c

@hichamboushaba hichamboushaba merged commit cfbae08 into trunk Oct 9, 2025
16 checks passed
@hichamboushaba hichamboushaba deleted the issue/WOOMOB-1239-booking-list-filering-ui branch October 9, 2025 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants