Replies: 1 comment
-
|
Hey there @jsierles 👋, I think you got remix wrong, there's no static generation in remix so therefore there's no need to revalidation on your app. There's some core fundamentals differences between Next.js and Remix, while Next(pages dir) does both SSR and SSG/ISR while in Remix we only have SSR. If you want to have a static-like behaviour in Remix you have to rely on proper caching to cache and revalidate your content, this way you can easily achieve what next does with SSG/ISR with more granularity and control. Here are some links for learning more about Remix and caching:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello everyone. I'm trying to decide whether to use Remix or Next.js. I prefer the simplicity of remix and the built-in auth, but I'm not fully understanding how revalidation works.
Suppose I have a page that's built from multiple queries, which the backend must issue in order to enforce permissions. If the client uses POST to change one piece of data, where is the work done to rerender the page? On the client, on the server, or on both?
When the page is rerendered, do all of the queries have to be reissued? To reissue only the relevant queries, do I have to isolate those queries to a particular subroute? Does this necessarily couple screen components with data, so that to get performance I have to avoid distributing data across multiple components?
I plan to be using stale-while-revalidate because once the data for a page is fully fleshed out, the pages should thereafter change only infrequently. If the user refreshes a page, or closes a tab and then re-enters the site, will the user's changes be evident before the SWR refresh period?
I'll be using forms to change some data, buttons to change other data, and drag-and-drop to change still other data. All of this data must persist.
Beta Was this translation helpful? Give feedback.
All reactions