Skip to content
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: use rtk query for loading owned safes #4356

Closed
wants to merge 1 commit into from

Conversation

schmanu
Copy link
Member

@schmanu schmanu commented Oct 10, 2024

What it solves

Resolves #4350

How this PR fixes it

Uses RTK query and its caching to load owned Safes.

How to test it

  • Toggle the sidebar and observe only one request for loading the owned Safes

Checklist

  • I've tested the branch on mobile 📱
  • I've documented how it affects the analytics (if at all) 📊
  • I've written a unit/e2e test for it (if applicable) 🧑‍💻

@schmanu schmanu requested a review from iamacook October 10, 2024 14:26
Copy link

github-actions bot commented Oct 10, 2024

Copy link

📦 Next.js Bundle Analysis for safe-wallet-web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 961.15 KB (-10 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

One Page Changed Size

The following page changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load
/share/safe-app 9.58 KB (🟢 -143 B) 970.73 KB
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this.

Copy link

Coverage report

St.
Category Percentage Covered / Total
🟡 Statements
74.44% (+0.01% 🔼)
12868/17287
🔴 Branches
52.92% (+0.11% 🔼)
3104/5866
🔴 Functions
58.68% (+0.06% 🔼)
1893/3226
🟡 Lines
76.15% (+0.01% 🔼)
11692/15353
Show files with reduced coverage 🔻
St.
File Statements Branches Functions Lines
🟡
... / gateway.ts
60% (-8% 🔻)
100% 50%
62.5% (-10.23% 🔻)

Test suite run success

1504 tests passing in 204 suites.

Report generated by 🧪jest coverage report action from 786d9b6

Copy link
Member

@iamacook iamacook left a comment

Choose a reason for hiding this comment

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

We also need to include extractRehydrationInfo for persistence of the new endpoints.

@compojoom
Copy link
Contributor

@iamacook we are not persisting this data? On refresh of the page we should fetch it from the server again.

What I noticed that is that when the sidebar is closed there is no query that need the data so rtk is unsubscribing from the query after 60s. We should actually increase the caching time to maybe something like 10mins?

@iamacook
Copy link
Member

@iamacook we are not persisting this data? On refresh of the page we should fetch it from the server again.

The cached owners and all Safes are initially returned. This means that a returning user would already have a populated sidebar, for instance.

However, whether we want to keep this behavior is open for discussion, particularly when considering the complexity of implementing it with RTK Query.

@iamacook
Copy link
Member

I've since realised we should definitely test creating/being added to a Safe now that the caching has been adjusted, and if it correctly updates.

@schmanu
Copy link
Member Author

schmanu commented Oct 11, 2024

Closing it until we rework the sidebar.

Reason:
This refactoring changes the behavior of the sidebar loading as well:

  • Previously we always triggered a request but if we had a cached value we served that value until the new data came in.
  • This behavior would be lost now

I think to properly improve this we should redesign the sidebar and rework the sidebar logic such that we do not require all owned Safes anymore to render the basic Sidebar.

@schmanu schmanu closed this Oct 11, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Oct 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add caching to owned Safes
3 participants