-
Notifications
You must be signed in to change notification settings - Fork 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
Refactor FXIOS-11046 [Homepage Rebuild] [TopSites] Try to improve topsite rendering on the homepage #24222
Conversation
let topSites: [HomeItem] = topSitesState.topSitesData.prefix( | ||
topSitesState.numberOfRows * numberOfCellsPerRow | ||
).compactMap { | ||
.topSite($0, textColor) | ||
} |
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.
🔥 this makes sense to me to have the calculation here + the previous implementation had a bug
@@ -151,8 +153,16 @@ final class HomepageSectionLayoutProvider { | |||
|
|||
private func createTopSitesSectionLayout( | |||
for traitCollection: UITraitCollection, | |||
numberOfTilesPerRow: Int | |||
size: CGSize, | |||
numberOfRows: Int |
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 are not using numberOfRows
here anymore, seems like we can remove this here and where its set in the diffable code
firefox-ios/Client/Frontend/Home/Homepage Rebuild/HomepageSectionLayoutProvider.swift
Outdated
Show resolved
Hide resolved
@@ -217,9 +207,9 @@ final class HomepageViewController: UIViewController, | |||
} | |||
|
|||
func newState(state: HomepageState) { | |||
homepageState = state | |||
guard self.homepageState != state else { return } |
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.
why do we need to add this check here?
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 don't.. We were just playing around to see if it would help cut down on the number of times the data source gets a snapshot applied as an experiment. The homepage newState
function gets triggered 30+ times and the snapshot gets applied that many times. the collection view only gets reloaded if the snapshot changes but the collection view sections get recalculated each time and this is a lottt.. I will remove this change now but it is worth more discussion with the team.
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.
yeah :( I agree, let me know if you want me to start that conversation or if you would to! We aren't really doing this in all the other places, so was just curious if there was a reason we added it since I think we were on the path that we were okay with this spamming the calls that may reveal underlying problems.
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 removed it. We do this in some places in the codebase but you are right that it is not consistent. We discussed being okay with spamming apply snapshot since it wont actually reload the collectionview unless something has changed but it is concerning to me that we also recalculate the layout many times. 🤷♀️ We added this in to see if it would decrease the number of calls as an experiment.
wallpaperView.wallpaperState = state.wallpaperState | ||
dataSource?.updateSnapshot(state: state) | ||
dataSource?.updateSnapshot(state: state, numberOfCellsPerRow: numberOfTilesPerRow(for: availableWidth)) |
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 like this a lot better! 🔥
@@ -66,36 +66,23 @@ final class TopSitesMiddleware { | |||
return site | |||
} | |||
|
|||
private func getTopSitesDataAndUpdateState(for action: Action, and numberOfTilesPerRow: Int? = nil) { | |||
private func getTopSitesDataAndUpdateState(for action: Action) { | |||
Task { |
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.
Can you elaborate why we decided to break up into two separate tasks instead of using the task group instead?
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.
This is accomplishing the same behavior but is a bit more straight forward. This is the behavior I believe we expect but let me know if I am wrong!
- Fetch top sites
- When top sites are fetched update state
- fetch sponsored sites
- when sponsored sites are fetched update state
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'm understanding this correctly, this change can lead to a race and stale data since otherSites
and sponsoredTiles
are both needed for the latest top sites.
For example, the Task
to fetch other top sites is using the current sponsored tiles and may not hold the updated one. Vice versa the sponsored tiles are using the original other sites and not the latest one. So could there be inconsistencies in getting the latest sites data from both?
The original code ensures all tasks complete before performing final updates and the final updateTopSites
call guarantees that both otherSites
and sponsoredTiles
have been updated. Let me know if I'm misunderstanding!
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.
ugh ya I see. I will add it back. I think it is unfortunate that we have to fire the same action 3 times but I cant see a way around it right now so I will revert this change.
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.
😓 yeah agreed, thanks!
7fbf234
to
22940f2
Compare
This pull request has conflicts when rebasing. Could you fix it @Cramsden? 🙏 |
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 making the updates! I responded to one of your comments, let me know if you need more clarity!
3c02a10
to
a76d264
Compare
Client.app: Coverage: 32.29
Generated by 🚫 Danger Swift against a065161 |
windowUUID: .XCTestDefaultUUID, | ||
actionType: HomepageActionType.initialize | ||
) | ||
|
||
let expectation = XCTestExpectation(description: "All relevant top sites middleware actions are dispatched") | ||
expectation.expectedFulfillmentCount = 3 | ||
expectation.expectedFulfillmentCount = 2 |
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.
should this be 3 instead?
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.
yep! it should be now! and I think there is another test that should be updated to 3 as well. I will make the change!
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.
code looks great now @Cramsden, aside from one minor comment in tests! I pulled the app down from this branch, but getting some issues with top sites... don't think it's your change since I see it in main, but must be something recent, do you see this as well?
This occurs after tapping on a top site.
Screenshot |
---|
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.
weird, I reset my simulator and now it works. approving! just that one nit on the tests! thanks for making this improvement 🔥 !!
📜 Tickets
Jira ticket
Github issue
💡 Description
In order to display top sites on the homepage we need to know the
NumberOfRows
which is configured via a user setting andNumberOfCellsPerRow
which is only calculated via the width of the view. It makes sense thatNumberOfRows
would live on the state since it is configurable with information that is outside of the view, but there is really no reason forNumberOfCellsPerRow
to live on the state since it is only a calculation based on information from the view. This PR attempts to simplify that logic so thatNumberOfCellsPerRow
is removed from the state and actions.Simulator.Screen.Recording.-.iPhone.16.Plus.-.2025-01-17.at.12.25.46.mp4
📝 Checklist
You have to check all boxes before merging
@Mergifyio backport release/v120
)