[CIAB Bookings] Update filter screen navigation to use Compose Navigation

[hichamboushaba]

Closes WOOMOB-1608

Description

As discussed and agreed, this PR updates the filters internal navigation to use Compose Navigation, the navigation is still driven by the state of the ViewModel, the added NavHost and its graph will just reflect the selected page.
As stated, the benefit of this solution is that we'll have a correct lifecycle for the sub-ViewModels we use for the filter subscreens, as the navigation component will use a proper ViewModelStore tied to the composable destination.

To better test the solution, I rebased the draft customer filter PR on this branch, and this shows how we can instantiate the sub-ViewModels, and how we can navigate back.
For communication between the parent ViewModel (BookingFilterListViewModel) and other ViewModels, we'll use simple callbacks passed to the subscreen Composables, which then pass them back to their ViewModels. Assisted injection improves this solution, as shown in this commit. This approach eliminates the need to rely on events for communication.

Please share your thoughts on the suggested approach.

Test Steps

1. Test the changes in the PR [WOOMOB-1469] Booking Customer Filter #14834
2. Open the booking filters screen
3. Test navigation to the date time and customer filter screens (the other items will crash the app)
4. Test selecting a customer and confirm the result is returned

Important: For step 4, make sure that you select an actual customer, and not a guest, tapping on guests won't have any effect.

Images/gif

Screen_recording_20251029_185420.mp4

• 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]

	1 Warning
⚠️	This PR is assigned to the milestone 23.6. This milestone is due in less than 2 days. Please make sure to get it merged by then or assign it to a milestone with a later deadline.

Generated by 🚫 Danger

[wpmobilebot]

📲 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 Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	6474dc8
	Direct Download	woocommerce-wear-prototype-build-pr14859-6474dc8.apk

[wpmobilebot]

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

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	6474dc8
	Direct Download	woocommerce-prototype-build-pr14859-6474dc8.apk

[AdamGrzybkowski]

Great work! I like it!

For communication between the parent ViewModel (BookingFilterListViewModel) and other ViewModels, we'll use simple callbacks passed to the subscreen Composables, which then pass them back to their ViewModels. Assisted injection improves this solution, as shown in this commit. This approach eliminates the need to rely on events for communication.

I think that's a good idea, I'm okay with events too. One thing to keep in mind is that we will likely need to update the Root ViewModel multiple times without closing the screen, with the multiselect options.

[AdamGrzybkowski]

Suggested change

	composable(BookingFilterPage.List.route) {
	BookingFilterRootPage(state.items)
	}
	composable<BookingFilterPage.List> {
	BookingFilterRootPage(state.items)
	}

np: We could use the type-safe destinations to build the graph. We need to make those serializable, but I don't think it's a problem here.

[hichamboushaba]

Yes, I thought about it, but given we don't use the serialization plugin on the app, I didn't use, and given we most likely won't need it as the state already exposes all the information that we need, I decided to just use String routes, and they will be static routes.

[hichamboushaba]

Related to this, I thought about converting BookingFilterPage to an enum, but I'm not sure if we'll need to pass data for the items in the future, I think given the root ViewModel state is available, we probably won't need any addiitonal data on the currentPage property, WDYT?
If we use an item, we can then just use the name property for route, but it's a minor point.

[AdamGrzybkowski]

Good call. At the moment, I can't think of any data we would pass so I think we should be okay with an enum!

[hichamboushaba]

Done in 6474dc8, I kept using Camel Case for the item names, and kept the route extension, this way even if we need to use a sealed inteface, it will be an easy change.

[hichamboushaba]

One thing to keep in mind is that we will likely need to update the Root ViewModel multiple times without closing the screen, with the multiselect options.

Good point, but I think it's something to discuss later: If we need to follow what you suggested, then we can use two callbacks. But we may not need it if we follow the same approach we use in Order filters today, we save the changes only when the user either taps on "Show orders" or back button, which means we'll close the screen anyway when updating the root ViewModel.

[AdamGrzybkowski]

Correct, though the Show orders button click is handled in the BookingFilterListViewModel so whatever was selected on any of the child pages (while one of those still being visible) has to be already in that VM state as a temp filter (not stored yet).

[hichamboushaba]

Correct, though the Show orders button click is handled in the BookingFilterListViewModel so whatever was selected on any of the child pages (while one of those still being visible) has to be already in that VM state as a temp filter (not stored yet).

Yes, later after I sent the comment I thought about this and figured my mistake, you are right, we'll need two callbacks then. Thanks @AdamGrzybkowski

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 38.27%. Comparing base (022c591) to head (6474dc8).
⚠️ Report is 26 commits behind head on trunk.

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #14859      +/-   ##
============================================
- Coverage     38.27%   38.27%   -0.01%     
+ Complexity    10089    10082       -7     
============================================
  Files          2132     2132              
  Lines        120771   120772       +1     
  Branches      16568    16553      -15     
============================================
  Hits          46224    46224              
  Misses        69850    69850              
- Partials       4697     4698       +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.