Skip to content

Conversation

@jaclync
Copy link
Contributor

@jaclync jaclync commented Jul 3, 2025

Part 1 of WOOMOB-756

Just one review is required.

Now that the differences between POS as a tab i1 and i2 result in more code changes, I am working on a 2-part refactoring with the ultimate goal to remove cases for the tab visibility check from the POS ineligible enum in WOOMOB-756 while not affecting i1 significantly. In retrospect, I could have created a separate POSTabEligibilityChecker for i1/i2 at the beginning with the tradeoff of some duplicate code. Before making more changes that touch on i1, I decided to update POSTabEligibilityChecker to only contain the i2 logic, and move the i1 only logic to LegacyPOSTabEligibilityChecker. i2 only implementation will be in the next PR.

To hopefully make it easier to understand the differences between i1 and i2:

milestone POS tab visibility check POS eligibility check
i1 all conditions: tablet, iOS 17+, store country, store currency, remote feature flag, WC plugin version, POS feature switch for WC version 10.0+ none
i2 tablet, store country, remote feature flag iOS 17+, store currency, WC plugin version, POS feature switch for WC version 10.0+

This PR focuses on duplicating POSTabEligibilityChecker to LegacyPOSTabEligibilityChecker, then updating LegacyPOSTabEligibilityChecker to be just i1 implementation. Same for the unit tests.

Steps to reproduce

POS tab visibility/eligibility behavior should be the same as before:

Store eligible for POS

  • Log in to a store eligible for POS --> the POS tab should be shown after a bit

Store in eligible country but not eligible for POS

  • Log in to a store in eligible country but not eligible for POS --> the POS tab should be shown after a bit
  • Tap on the POS tab --> after loading state, an ineligible UI should be shown based on the reason

Store not in eligible country

  • Log in to a store not in eligible country --> the POS tab should not be shown even after a while

Testing information


  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@jaclync jaclync added type: task An internally driven task. feature: POS labels Jul 3, 2025
@jaclync jaclync added this to the 22.8 milestone Jul 3, 2025
@wpmobilebot
Copy link
Collaborator

wpmobilebot commented Jul 3, 2025

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

App NameWooCommerce iOS Prototype
Build Numberpr15864-2a024c3
Version22.7
Bundle IDcom.automattic.alpha.woocommerce
Commit2a024c3
Installation URL3p03nqr6797eg
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

@jaclync jaclync changed the title Refactor POSIneligibleReason enum and simplify visibility logic [POS as a tab i2] Temporarily disable i2 to refactor POSTabEligibilityChecker to i1 implementation only Jul 3, 2025
@jaclync jaclync changed the title [POS as a tab i2] Temporarily disable i2 to refactor POSTabEligibilityChecker to i1 implementation only [POS as a tab i2] Temporarily disable i2 from refactoring POSTabEligibilityChecker to i1 implementation only Jul 3, 2025
@joshheald joshheald self-assigned this Jul 4, 2025
Copy link
Contributor

@joshheald joshheald left a comment

Choose a reason for hiding this comment

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

Works as expected, some minor suggestions/questions inline but nothing blocking, all up to you.

private var siteSettingsEligibility: POSEligibilityState?
private var featureFlagEligibility: POSEligibilityState?
/// Legacy enum containing POS invisible reasons + POSIneligibleReason cases for i1.
private enum LegacyPOSIneligibleReason: Equatable {
Copy link
Contributor

Choose a reason for hiding this comment

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

Good choice making the duplicate the legacy, for source control history purposes.

}

/// POS tab eligibility checker for i1. Will be replaced by `POSTabEligibilityCheckerI2` when removing `pointOfSaleAsATabi2` feature flag.
final class POSTabEligibilityChecker: POSEntryPointEligibilityCheckerProtocol {
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not the biggest problem to do it this way around, but source history for the code we keep can be (more) linear if you were to duplicate POSTabEligibilityChecker to a new LegacyPOSTabEligibilityChecker file now, and make the changes there. Then update POSTabEligibilityChecker to have the i2 rules.

The downside is that you'd need to update the callsite to use LegacyPOSTabEligibilityChecker for now.

Not a must-have – it's not as though we'll make a big problem with the history doing it this way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was debating the two approaches, but went the other way because of the large first PR and just kept going. But great point on keeping the git history more granular if we move i1 to a separate class and make changes to i2 in POSTabEligibilityChecker. LegacyPOSTabEligibilityChecker is a better fit for i1 too since the internal enums are already named Legacy*. It wasn't a hard change, so I went with your suggestion with just moving file content without code changes:

  1. Copy and paste the current POSTabEligibilityChecker from this branch (i1 only, reviewed in this PR) to LegacyPOSTabEligibilityChecker. Same for the tests.
  2. Copy and paste the POSTabEligibilityChecker in trunk (i1 + i2) to POSTabEligibilityChecker in this branch. Same for the tests. There are no diffs on these two files now.
  3. Later in POSTabEligibilityCheckerI2: i2 logic #15865, the POSTabEligibilityCheckerI2 content (i2 only, reviewed in that PR) will be copied to POSTabEligibilityChecker. Same for the tests.


struct POSEntryPointControllerTests {
@available(iOS 17.0, *)
@Test func eligibilityState_is_set_to_eligible_when_i2_feature_is_disabled() async throws {
Copy link
Contributor

Choose a reason for hiding this comment

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

This test is a bit confusing... why do we set it to eligible if the feature's disabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea the test case name sounds confusing now that I read it a bit after implementation. This is for the behavior of directly returning eligible for POS entry point for i1 since the store already meets the eligibility check if POS tab is visible / being tapped.

I updated the name to eligibilityState_is_always_eligible_when_i2_feature_is_disabled_regardless_of_eligibility_checker in 24412fc, hopefully it's easier to read.

@jaclync jaclync changed the title [POS as a tab i2] Temporarily disable i2 from refactoring POSTabEligibilityChecker to i1 implementation only [POS as a tab i2] Move i1 eligibility checker to LegacyPOSTabEligibilityChecker with i1 only implementation Jul 4, 2025
@jaclync
Copy link
Contributor Author

jaclync commented Jul 4, 2025

Thanks for the review and suggestions, Josh! I updated the PR and the description with most changes in #15864 (comment) moving content around, tested again, and I am going to merge it.

@jaclync jaclync merged commit da958db into trunk Jul 4, 2025
15 checks passed
@jaclync jaclync deleted the feat/WOOMOB-756-separate-ineligible-enum-to-visibility-and-eligibility branch July 4, 2025 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature: POS type: task An internally driven task.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants