-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[Reader IA] Integrate Top Bar Filter UI to Filter functionality #19856
[Reader IA] Integrate Top Bar Filter UI to Filter functionality #19856
Conversation
Generated by 🚫 dangerJS |
📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack 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 this PR @thomashorta 🙇 ! Overall it looks good. I'm reporting an issue I found in one of my test accounts though. While comparing the viewpager tabs and feeds content for before / after, I see a missing menu item for "Followed P2S" (that is a filterable with only Sites and no Tags elements, I think similarly to the Automattic item)
Not sure how common this scenario is, but I think that menu is related to P2 the product sites that I think I created in that account from here if it's useful to create the test scenario.
cc @RenanLukas fyi.
I don't think I understand what is the issue you're reporting here. In your comment, I only see a screenshot from the old UI (before) and there doesn't seem to be a report of what is the issue after the changes. |
Hey @thomashorta 👋 , it seems I missed to paste a picture of how it looks for me with the version on this PR, sorry if it was not clear from the description and here is a before/after 👍
What I was trying to say here is (using the same user for the before/after):
About how to get the Followed P2s on your side, what follows is my best guess
but I can share my test account with you if it's quicker (just dm me in slack 👍 ) |
Ah, I understand it now, though I don't think it has anything to do with this PR since this is integrating the filter functionality (blogs and tags) with the real data from each field, and not related to the feeds and drop-down menu itself. Regarding this:
The code in this PR already makes sure that we only show the "Blogs" pill for Automattic and P2 feeds, since I added the same logic used by the subscription management sheet to decide if the tag filter pill should be shown (https://github.com/wordpress-mobile/WordPress-Android/pull/19856/files#diff-2e098785089098d2a88d269ff91d4fb30d8f03c6c0fa67defdd892da6551e063R510-R511). I think it makes sense to open a different issue for the "Followed P2" feed not showing on the drop-down menu, wdyt? |
…der Following tab" This reverts commit 530bb5c. This revert is needed since now we do rely on information from the Following blogs on the Following feed due to the new filters UI on the Top Bar.
Thanks for the PR, @thomashorta . I went through the testing steps and it's working as expected. I'm now moving to the code review. I wanted to point out that adding this call again did not work for me to fix #19891: Screen.Recording.2024-01-09.at.5.16.09.PM.movI've tried building locally and also with the APK provided by the |
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.
@thomashorta code LGTM 👍
I just didn't approve yet to confirm if the strings with new content and same keys are a problem or not.
<string name="reader_filter_sites_title">Sites</string> | ||
<string name="reader_filter_tags_title">Topics</string> | ||
<string name="reader_filter_main_title">Following</string> | ||
<string name="reader_filter_sites_title">Filter by blog</string> |
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 don't remember by heart: do we have to rename strings when the content changes to they're correctly picked up by GlotPress script?
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.
If I remember correctly, the script (or maybe GlotPress) is smart enough to see the changes and mark the Strings as "untranslated" in the platform. cc @oguzkocer or @AliSoftware to confirm that though.
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.
We should always treat strings as immutable—once you created a key with a value, you should avoid changing its value later on, especially if the first value already made it to a previous release.
This is because otherwise once this change hits trunk it will be sent to GlotPress and the new copy retranslated… but if we then pull the translations from GlotPress into the release/*
branch before submitting to Google then that change of the copy would end up making its way to the release branch… despite being a change tied to something in trunk
.
In summary modifying the value of an existing key will cause a discrepancy in the release/*
branch, between the codebase (which will expect the old copy as that's what it was when code was frozen) and the translations (updated with the new copy when we'll pull the latest from GlotPress)
TL;DR: prefer using a brand new 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.
Thanks, @AliSoftware
I'll change the string keys with new content to brand new ones.
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 @AliSoftware for the answer, that makes sense!
<string name="reader_filter_tags_title">Topics</string> | ||
<string name="reader_filter_main_title">Following</string> | ||
<string name="reader_filter_sites_title">Filter by blog</string> | ||
<string name="reader_filter_tags_title">Filter by tag</string> |
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.
Same question about keeping the same string name when content changes.
.../src/main/java/org/wordpress/android/ui/reader/views/compose/filter/ReaderFilterChipGroup.kt
Outdated
Show resolved
Hide resolved
.../src/main/java/org/wordpress/android/ui/reader/views/compose/filter/ReaderFilterChipGroup.kt
Outdated
Show resolved
Hide resolved
Generated by 🚫 Danger |
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.
LGTM
Fixes #19855
Fixes #19851
Caution
Should not be merged before #19844
This integrates the new Filter component with the existing Filter functionality, while also updating the Filter Sheet to look a bit closer to the new specs, but some things, like the Edit Button and the style update for site items will be done in future PRs.
As a side effect, this PR also fixes #19851 since the root cause of that bug also caused the feed to refresh when selecting a Filter, which was needed for this PR.
19855-reader-ia-filter-integration.mp4
To Test:
Regression Notes
Potential unintended areas of impact
What I did to test those areas of impact (or what existing automated tests I relied on)
What automated tests I added (or what prevented me from doing so)
PR Submission Checklist:
RELEASE-NOTES.txt
if necessary.UI Changes Testing Checklist: