Removed the shimmering modifier from OwnerUpgradesView

[bozidarsevo]

Closes: #11611

Description

• There was a problem with SwiftUI Shimmer package so to fix the issue we had to use exact commit reference until they merge and tag the proper fix removed the shimmering modifier from OwnerUpgradesView
• The shimmer modifier was producing bug in a way that views were being animated in a loop by moving from bottom to top and messing up the entire view layout
• We will keep an eye on the SwiftUI-Shimmer repo and when the correct commit is merged we will update the package management
• The last commit on SwiftUI-Shimmer main branch still has a bug so I used the commit from unmerged PR

Testing instructions

• Open IAP upgrade screen
• If the content is loaded fast and you do not see any redacted and shimmering content you should check that the close button (X) and navigation title are positioned correctly and fixed on the top.
• Check gifs below and compare how it was before and how it is now

Screenshots

Before	After

---

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

[wpmobilebot]

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

	App Name	WooCommerce iOS
	Build Number	pr11683-e1c1d81
	Version	16.8
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	e1c1d81
	App Center Build	WooCommerce - Prototype Builds #7637

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[iamgabrielma]

Thanks for taking care of this!

I have two questions/notes:

• I believe we're aiming to disallow referencing dependencies by commit, and that CI checks will start to fail if we do so (at least for pods, I'm not sure if SPM is also included in this, but might be something to check with infra before moving forward, here's the context: p1704255760658109-slack-CC7L49W13
• Is there any concern regarding referencing a un-merged PR from their library?

[jaclync]

• I believe we're aiming to disallow referencing dependencies by commit, and that CI checks will start to fail if we do so (at least for pods, I'm not sure if SPM is also included in this, but might be something to check with infra before moving forward, here's the context: p1704255760658109-slack-CC7L49W13

If I understand the expected behavior that will be enforced in the future correctly p1704280854743209/1704255760.658109-slack-CC7L49W13, we only want to point libraries to a commit and non-commit references won't be allowed after Gio's PR Automattic/dangermattic#30 🤔 I'd think the same principle applies to SPM, but it might be worth double-checking with apps-infra.

• Is there any concern regarding referencing a un-merged PR from their library?

Good question, referencing a commit in an un-merged PR might be problematic if they do squash merge or if the author does a force push. It's tricky that we can't use the main branch because of the outstanding issue, maybe we can fork the library (we probably want to check with apps-infra about how to do this so that the forked repo is an A8C repo) and also ping the PR author / library owner about merging this fix and tagging for release.

[bozidarsevo]

Authors PR that is merged is not fully fixing the issue and it looks like the author is not really checking other PRs and issues :/ And he did not even tag that fix with a new version number.

Maybe a fork would be the best way of making sure simple packages like this work properly for us.

What would be the best solution for us?

Maybe we can even write our own shimmer version?

[iamgabrielma]

Thanks for the clarifications @jaclync !

What would be the best solution for us?
Maybe we can even write our own shimmer version?

Good question, I don't really have an answer 😅 Since the shimmer is used across multiple views/features let's move the discussion to P2 for a decision. Right now only seems to affect this view, but if the library is sort of abandoned then is certain we'll keep encountering issues as we add more instances of it in the future.

For the specific animation oddness that we were trying to fix initially, I'd say that for the time being we can just remove the .shimmering modifier from OwnerUpgradesView, which seems to fix the issue from a quick testing.

[jaclync]

+1 to Gabriel's comment above to p2 the plan to fork the repo / write our own version, and then remove the shimmering modifier for this particular view to fix the issue for now. When we create an issue for the shimmering library change after the plan is finalized, we can add a note about adding the shimmering effect back to this view.

[bozidarsevo]

Tnx @iamgabrielma @jaclync for feedback! I will update this PR according to our comments and write a P2 for continuing the discussion 👍

[bozidarsevo]

Updated the code and wrote the P2 -> pfoUAQ-7T-p2

[iamgabrielma]

Thanks for taking care of this! LGTM 🚢