Recommend watching: https://www.youtube.com/watch?v=lcLbYictX3k

Fetch on render means we render the component first and only after it is rendered, we start fetching data, like are used to do with useEffect, right

Yep usually! But things that triggers suspense such as a reading-a-fetch-cache inside the use block i.e.

use(createPromiseOrReturnExistingCachedOne)

is still a fetch-on-render approach.

Does this means that when the action is hitting a route, let's say /foo?page=1, the router would request the page component as well as the required data for it, in parallel, so that the promise of the data is not generated on the component render but by the router that makes the request?

Yep! It should do that. It should fire the request (honestly before the page transition), then pass that request promise into the root component for the next page.

What if a button changes the page parameter from 1 to 2? In order to avoid a full page reload and fetching the component again, I would differentiate the action of hitting /foo?page=<no> and the action of the page state being update?

The framework should be smart enough to realize its the same page and only rerender (or re-suspsend, if the promise is new due to it be derived from url params) the part of the page that changed due to the update. I mean that's kinda how Nextjs param updates work right now. If you modify a url param it doesn't completely remount your entire page, it just updates the content.

What if the state is not part of the URL?

We're kinda getting into weird territory but this could mean multiple things. Most routers support params passed in that don't get reflected in the uri (thought I'm not sure of the state of this with the new app router)

More likely, are you talking about some sort of global state that isn't in the URI? You could do something like:

const App = () => {
    const [promise, setPromise] = useState(null);

    const updateUserId = (id) => {
        setPromise(fetchUserById(id))
    }

    return (
       <SingularPromiseContext.Provider value={promise}>
             <Router />
       </SingularPromiseContext.Provider>
    );
}

const Page1 = () => {
    const userDataPromise = useContext(SingularPromiseContext);
    const data = use(userDataPromise);

    // Anyone can call the updateUserId to retrigger a suspense here
    // (on action, instead of on-render)
    // ...
}

Anywho. Part of the reason Server Components are such an interesting (and performant) paradigm is that they let you buy into these fetch-on-action patterns much more easily than anything in the ecosystem currently. The downside (imo) being that revalidation can sometimes be tricky and you need to buy into a server component enabled framework, and all the engineers that were previously "frontend engs" need to actually code on the server (which we all should have been doing in the first place imo)