search

bcgov / cas-registration

A web app for Registration in OBPS under the Clean Growth branch
Apache License 2.0
1 stars 1 forks source link

"Client-side" data refresh #406

Open shon-button opened 6 months ago

shon-button commented 6 months ago

Currently, we manage data changes from the backend to the frontend by using server action and revalidatePath, or refresh page.

This paradigm works well in use cases that flow from one screen to another but, may prove inefficient and/or a poor user experience if the screen does not need to "refresh page or navigate away" after a data change.

Perhaps, we might implement a "client-side" data management using useState rather than refresh browser page (revalidatePath) strategy.

Possible change:

Modify client/app/utils/actions.ts to accept a GET endpoint to call after data updates which returns new data accepted by the client side component. Modify client/app/utils/actions.ts to apply logic after updates to either do nothing; revalidatePath; or GET new data as result for component. Tie onSubmit handler with useState

joshgamache commented 6 months ago

Is this somewhere that on-demand revalidation might work? I'm still not super familiar with Next 13/14/App dir, but it seems like it might apply in this case. Skimming over client/app/utils/actions.ts:actionHandler(), it seems like it might work there.

shon-button commented 6 months ago

@joshgamache in fact on-demand re-validation is handled in client/app/utils/actions.ts:actionHandler() where if a re-validate path is provided then the path is re-validated (on demand) using revalidatePath which uses "refresh page" strategy (I believe) . As mentioned above we may want to avoid this refresh page strategy on some screens using useState instead as detailed above.