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
[WIP] HACK Week: Reader detail customization #22851
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
76dcbfe
to
d684c03
Compare
d684c03
to
51da0d3
Compare
The priority is still given to the `ButtonColor` object that's passed through the parameter. The `ReaderDisplaySetting` only takes precedence when there are no `ButtonColor` objects being passed. The `@State` wrapper is removed from the `color` property since it seems to be the cause of the button not updating colors after the display setting is updated.
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.
On an iPhone SE with default font settings, there are some display issues with the customization sheet. It appears too big for the screen:
Portrait | Landscape |
---|---|
I found some display issues while changing the font size without navigating away from the screen:
resizing.mp4
I'm guessing this may be part of the toolbar work, but figured I'd mention it just in case. I noticed the close (X
) button is a bit difficult to see with some configurations.
Given that all these are pretty minor and it being a work in progress, I'm good approving it. Overall, nice work!
if let contentCache = commentContentCache, contentCache == comment.content { | ||
return webView | ||
if #available(iOS 16.4, *) { | ||
webView.isInspectable = true |
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'm guessing this was mostly for debugging. Should this be removed?
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.
Hmm, I was thinking of leaving it in. I notice other web view subclasses/containers also have the isInspectable
property enabled, so I think it's fine to ship this into production.
I'll leave it in for this PR, but we can continue to discuss, and I can remove it later during beta if we feel this is unsafe.
WordPress/Classes/ViewRelated/Reader/Detail/Views/ReaderDetailNewHeaderView.swift
Outdated
Show resolved
Hide resolved
WordPress/Classes/ViewRelated/Reader/Theme/ReaderDisplaySetting.swift
Outdated
Show resolved
Hide resolved
WordPress/Classes/ViewRelated/Reader/Theme/ReaderDisplaySetting.swift
Outdated
Show resolved
Hide resolved
WordPress/Classes/ViewRelated/Reader/Theme/ReaderDisplaySettingViewController.swift
Outdated
Show resolved
Hide resolved
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.
testing the build and looking good so far. Approving per request but noting a couple things (that maybe fixed already elsewhere, thats why I'm not blocking this). When I made the text size largest:
Thanks for the review @wargcm & @osullivanchris! Since this is still hidden behind a feature flag, I will aim to merge this today and address the remaining issues through smaller PRs so it's manageable for us and so that the PR is not too "different" from when you reviewed it last 😅 I'll open an issue after this to log the issues so that we can keep track of it. 🙂 |
08e43bd
to
12e74be
Compare
12e74be
to
b13bc83
Compare
Internal refs: zQnohyMpLzBzQ5jzMMKni3-fi-3900_17941, p1710343618122149-slack-C06PGTY5PKK
Warning
Some of the display settings are not fully applied yet, namely:
Since the feature is wrapped under a feature flag, I'll plan to address them separately via small-sized PRs.
This covers the proof-of-concept (WIP) of applying custom display settings to the Reader Post screen. The core idea is around the object
ReaderDisplaySetting
, which encapsulates the preferred color, font, and size.ReaderWebView
, and allow the colors to be injected to the CSS styles.Todo
To figure out next
ReaderDisplaySetting
is used and/or passed around is the "right" approach.ReaderDisplaySetting
to the design system or standard colors.To test
Note that the functionality to save the updated preferences hasn't been added yet. For now, you can test bringing up the customization interface and play around with the selections by:
Regression Notes
Potential unintended areas of impact
Should be none. Feature is hidden behind a feature flag.
What I did to test those areas of impact (or what existing automated tests I relied on)
Manually tested the changes.
What automated tests I added (or what prevented me from doing so)
N/A.
PR submission checklist:
RELEASE-NOTES.txt
if necessary.Testing checklist: