[ECO-2243] Fix NextJS config and cache

[CRBl69]

Description

This PR fixes the NextJS caching configuration and routing configuration:

• Caching:
  • revalidate is hard coded to 2 as NextJS does not support setting revalidate to dynamic values.
  • force-static and force-dynamic are removed since they're mostly useless.
• Routing:
  • app/page.tsx and app/home/page.tsx were duplicates. With the new configuration changes, app/page.tsx is removed (actually, replaced with a loading page just in case anyone manages to land here) and / redirects to /home.

Testing

See vercel (also vercel logs for cache).

Checklist

• Did you check all checkboxes from the linked Linear task?

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
emojicoin-dot-fun	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 7, 2024 11:23pm
emojicoin-dot-fun-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 7, 2024 11:23pm

[xbtmatt]

I'm a little confused why we are switching from forcing all requests to be static by default caching everything. As far as I understand, caching requests will cache them indefinitely unless revalidate is set. Setting it to 1 should work for fetches on that page, but I'm not sure about requests from any other part of the route tree or layout.

Also, did you test the variable revalidate amount and find that it didn't matter what you set it as? Because I have seen the value changed in the .next/fetch/* files. And the docs here suggest it's valid to use a number: https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#revalidate

I believe that it's only ignored in the edge runtime, but I believe that's only used in our middleware right now (I could be wrong about this).

In general though there are many cases where we really don't want to cache at all, and some where we want to cache much longer than 1 second. I think if we want to implement caching in any capacity, we should have e2e tests for it and a thorough investigation into how it works.

That is, until we have an extensive understanding of how caching works, we should probably just default to no caching at all, and it seems like this is the opposite of that.

In other words, I think we should default to const fetchCache: 'default-no-store' if we're going to do anything

[xbtmatt]

Just commenting here to reiterate that the main thing to test is all server fetches used in files with the "use server"; directive at the top, since they are all essentially overloaded nextjs fetch functions.

The main thing is to see what router path they're included in, since the file can be completely disparate from the file-based directory that normally resolves the path for caching

[xbtmatt]

This is working pretty well! Thanks for implementing this- I appreciate you getting this stuff to work with a more simple/elegant solution than using unstable_cache everywhere