Profile server client refresh #420

bitbeckers · 2025-02-07T15:43:00Z

Refactors the data fetching of the hypercert profile tabs to user server side APIs. Also implements a path invalidation flow that clears cached calls when a fraction claim was succesfully executed

Refactors and optimises the data fetching of the tabs pages to speed up the loading of the data

vercel · 2025-02-07T15:43:06Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
hypercerts-app	❌ Failed (Inspect)			Feb 17, 2025 7:20pm

typo in filename, console logs, redundant business logic

Jipperism

I'm struggling a bit to come to grips with how all of this works. I understand we're polling from the client side now, but I'm not sure how the api routes get invalidated as they will be caching results as well. Calling revalidateServerPath("profile/[address]") will invalidate the cached data for all server components. I take it that it will invalidate all api's under that "profile/address" path as well? Because that data is now not server-component bound anymore but being fetched using react-query.

Another question: how does this data get invalidated if the user closes their window before the transaction completes? Are we then stuck with stale data until the next invalidation due to interaction (or vercel deploy)?

Jipperism · 2025-02-10T12:43:22Z

app/api/profile/[address]/claimable/route.ts

+        return { ...fraction, metadata: metadata?.data ?? null };
+      }),
+    );
+    claimable.data = processedData;


Reassigning this is a bit unidiomatic.

what do you mean? should it be named differently? Suggestions?

I mean doing something more like { ...claimedable, data: processedData }, so we avoid mutating values. I think in this case the chances of errors popping up due to this reassignment are minimal tho, as it's a lambda function that doesn't share references with anything else. To be fair, it's a bit of a nitpick but I usually try to avoid doing this.

Are you ok with it being a temporary implementation untill we have hypercerts-org/hypercerts-api#240

Jipperism · 2025-02-10T12:45:16Z

components/profile/hypercerts-tab/hypercerts-tab-content-claimable.tsx

+import { useQuery } from "@tanstack/react-query";
+
+export const ClaimableContent = ({ address }: { address: string }) => {
+  const { data: response, isLoading } = useQuery({


I would prefer to see this split out to a separate file, so that revalidation issues are fixed everywhere automatically once this gets used in a different plaec as well. That would also allow for specifying the return type in the hook instead of having to cast the data type after.

The typecasting is only temporary untill we have this fixed in the API. Basically you can't get allow list records with metadata at the moment, hence the attaching of metadata in the API endpoint as well.

The query key is specific to this file, so why would we split out the hook that's only used in one place?

It's currently also used to get the tab counts? Granted, due to the query key being equal the call will only be done once, and both these components will just pull the results from the query cache.

moved into hooks and pushed

Jipperism · 2025-02-10T12:53:57Z

components/profile/hypercerts-tab/hypercerts-tab-counts.tsx

+  });
+
+  const { data: owned } = useQuery({
+    queryKey: ["hypercerts-owned", address.toLowerCase()],


This is a good example of where we would benefit from splitting out those hooks to their own files. The key differs between this one and the one used in hypercerts-tab-content-owned ("hypercerts-owned" vs "owned-hypercerts") which means that

invalidating won't updated the hypercerts everywhere

we're fetching twice (and polling) for the same exact data instead of reusing

more surface area for typing errors

Good catch, but this call is actually painfully inefficient for only getting the call. Wouldn't it be better to just call for the count?

Doing a call just for the count would also work.

Using the same hooks as for the content components untill this is resolved: hypercerts-org/hypercerts-api#255

Added a TODO. It would be a nice to have, so we can progressively render the tab content, skeletons and actual data

Jipperism · 2025-02-10T13:01:45Z

components/profile/unclaimed-hypercert-claim-button.tsx

+      queryKey: ["hypercerts-data", address.toLowerCase()],
+    });
+    await revalidatePathServerAction(`/profile/${address}`);
+    router.refresh();


Do we need to refresh? Seems to me that invalidating the queries should be enough to trigger a new fetch?

Can't tell you this at the moment as the API isn't invalidating the data that it should. The refresh was already in the batch claim button and I just made them consistent.

Also, according to the docs invalidating dynamic paths doesn't apply without refetching: https://nextjs.org/docs/14/app/api-reference/functions/revalidatePath

Jipperism · 2025-02-10T13:03:28Z

components/profile/unclaimed-hypercert-claim-button.tsx

-          `/profile/${account.address}?tab=hypercerts-claimable`,
-          `/profile/${account.address}?tab=hypercerts-owned`,
-        ]);
+        await refreshData(getAddress(account.address!));


It seems like we are not invalidating /hypercerts/${selectedHypercert?.hypercert_id} anymore now.

If I read the correctly, we should precisely specify all API call paths: https://nextjs.org/docs/14/app/api-reference/functions/revalidatePath

correct?

Depends on what you mean by API call path. As I understand it, the paths you specify here are supposed to be frontend paths, and not api paths. The server components that use fetch to get data before being rendered that are in those frontend paths will then have their cache purged, which results in them refetching data when refreshed.

Updated the invalidation methods to match the profile, api and hypcert view pages according to the doc. Again, a bit pending on this one to be completed to validate: hypercerts-org/hypercerts-api#254

Replace useQuery implementation in hypercerts-tab-content and -counts component with hooks for reusability

Removes unused hooks and services from the hypercerts folder

Updates the refreshData methods in the unclaimed hypercerts claim and batch claim button to: - invalidate the user's profile page - invalidate the relevant API paths - all hypercert view pages for the claimed fractions hypercert IDs

- Refactors the refactor into server side data fetching, aiming for as much SSR as possible - Moves actions for hypercerts and allowlist into `actions` folder to make their purpose explicit - Removes the suspense boundary on the hypercerts-tab-content component and puts it on the highest level possible - the UnclaimedFractions table - Adds allowlist action for fetching unclaimed fractions with metadata attached

allowlists/actions/getAllowListRecordsForAddressByClaimedWithMetadata.tsx

components/profile/hypercerts-tab/hypercerts-tab-content-claimable.tsx

Jipperism · 2025-02-17T18:51:09Z

components/profile/hypercerts-tab/hypercerts-tab-content-claimable.tsx


-  return <UnclaimedHypercertsList unclaimedHypercerts={data} />;
-};
+  return <UnclaimedHypercertsList unclaimedHypercerts={[...data]} />;


What's the reason for ...spreading the results here?

The action returns a readonly object and spreading creates a now non-readonly array

This might be too nitpicky but do we know why/where it's marked as readonly? Because this just created an new array with references to the same objects as in the original data, which end up being mutable (which we shouldn't do anyways).

Because that's what the readFragment method returns. It ensures typesafety and data consistency imho, we can view our Graph as the SoT and mutating API responses should be explicit. At least, that's how I interpret it.

The cleaner option could be to expect an readonly array in the component. Which I think is valid but we should apply in more places then

components/profile/hypercerts-tab/hypercerts-tab-content-owned.tsx

- removes the delete action from the metadata fetcher. The requestmap is ephemeral so we let is run with the lifecycle of the method

bitbeckers added 2 commits February 7, 2025 13:01

fix(cache): split server client data fetching and refresh

9a40be3

fix(profile): hypercerts tabs

d4dfcd0

Refactors and optimises the data fetching of the tabs pages to speed up the loading of the data

bitbeckers added the bug Something isn't working label Feb 7, 2025

bitbeckers requested a review from Jipperism February 7, 2025 15:43

bitbeckers self-assigned this Feb 7, 2025

vercel bot had a problem deploying to Preview February 7, 2025 15:44 Failure

fix(build): resolve implicit any hypercert tab created and owned

614433f

vercel bot deployed to Preview February 7, 2025 16:02 View deployment

This was referenced Feb 7, 2025

Fix/profile page rendering #297

Closed

feat: batch claim fraction #378

Merged

Base automatically changed from feat/batch-claim-fraction to dev February 7, 2025 18:10

chore(cleanup): code cleanup

2ae67ce

typo in filename, console logs, redundant business logic

bitbeckers changed the title ~~WIP: profile server client refresh~~ Profile server client refresh Feb 10, 2025

bitbeckers marked this pull request as ready for review February 10, 2025 09:28

vercel bot deployed to Preview February 10, 2025 09:30 View deployment

Jipperism reviewed Feb 10, 2025

View reviewed changes

bitbeckers mentioned this pull request Feb 11, 2025

[bug] caching issues on profile page and hypercert view page #393

Open

2 tasks

chore(refactor): refactor query calls into hooks

6280283

Replace useQuery implementation in hypercerts-tab-content and -counts component with hooks for reusability

vercel bot deployed to Preview February 11, 2025 09:23 View deployment

chore(cleanup): cleanup unused hypercerts hooks and typos

c86fe2a

Removes unused hooks and services from the hypercerts folder

vercel bot deployed to Preview February 11, 2025 09:38 View deployment

vercel bot deployed to Preview February 11, 2025 10:02 View deployment

Merge branch 'dev' into fix/profile_server_client_refresh

66fd627

vercel bot had a problem deploying to Preview February 11, 2025 10:06 Failure

bitbeckers requested a review from Jipperism February 17, 2025 17:09

vercel bot had a problem deploying to Preview February 17, 2025 17:11 Failure

Jipperism requested changes Feb 17, 2025

View reviewed changes

bitbeckers added 2 commits February 17, 2025 20:14

feat(allowlistaction): update metadata fetching response

9ca26f2

- removes the delete action from the metadata fetcher. The requestmap is ephemeral so we let is run with the lifecycle of the method

fix(datachecks): make check on data less verbose

2825095

vercel bot had a problem deploying to Preview February 17, 2025 19:20 Failure

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Profile server client refresh #420

Profile server client refresh #420

bitbeckers commented Feb 7, 2025 •

edited

Loading

vercel bot commented Feb 7, 2025 •

edited

Loading

Jipperism left a comment

Jipperism Feb 10, 2025

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025 •

edited

Loading

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 11, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 11, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025

bitbeckers Feb 10, 2025

Jipperism Feb 10, 2025 •

edited

Loading

bitbeckers Feb 11, 2025

Jipperism Feb 17, 2025

bitbeckers Feb 17, 2025

Jipperism Feb 17, 2025

bitbeckers Feb 18, 2025

Profile server client refresh #420

Are you sure you want to change the base?

Profile server client refresh #420

Conversation

bitbeckers commented Feb 7, 2025 • edited Loading

vercel bot commented Feb 7, 2025 • edited Loading

Jipperism left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jipperism Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jipperism Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bitbeckers commented Feb 7, 2025 •

edited

Loading

vercel bot commented Feb 7, 2025 •

edited

Loading

Jipperism Feb 10, 2025 •

edited

Loading

Jipperism Feb 10, 2025 •

edited

Loading