Nextjs app router multiple pages.

[zZHorizonZz]

I'm trying to use Quinoa with Next.js, and it's kind of working, but I think there's something weird going on with the routing. Basically, I'm using the app router, and if I have a main page and, for example, an about page, I cannot go directly to the /about page. I need to go to /about.html. But, if I have a <Link> to the about page and click it, it goes there without a problem, and the final URL is indeed /about and not /about.html. This also affects browser history goback which routes to 404 even though the previous page should be loaded successfully. I have created a test suite for this. https://github.com/zZHorizonZz/quarkus-quinoa/tree/test/next-app . I think this is related #727 even though it's for pages and not app router. So my question is what's the result of all this should it work and is this a bug or is this intended?

[melloware]

Is this your issue: #727

[melloware]

well it does work fine with NextJS 12 which is what I was using when I wrote the code and tested it. SO do you want to submit a PR updating the NextJS part of the docs? Saying what you have discovered? Basically NextJS sucks and they change stuff so frequently and SSR = a nightmare. I use React with Vite with tremendous success you can see my demo project here: https://github.com/melloware/quarkus-primereact

A PR updating the docs would be great!

[zZHorizonZz]

Yeah, I will try to write something. Should I also add a warning to the NextFramework class that says something like, "Currently, usage of Next.js version 13 and later is not recommended due to routing issues" or something like that?

[melloware]

Yeah something like that would be good. You can use an Admonition in the ASCIIDOC like CAUTION or NOTE

CAUTION: Make sure `.dockerignore` does not exclude `.so` files!

that makes it show up inthe AScii Doc like this

[UbiquitousBear]

So, I did some digging, and I think I'll use React for now and switch to Next if needed in the future. Based on this link, it seems they're planning to address the routing issue for exported output for dynamic routes maybe in the future, which might lead to other breaking changes with SPA, I reckon. (The reality of never-ending changes in the JavaScript ecosystem is real...)

Though, I think the documentation should be updated until then to state that the App Router works somewhat finicky, and, for example, dynamic routes on newer versions of pages router don't work at all based on my test. Or maybe remove Next.js from the list of supported frameworks for now until it's in a workable state?

Just reading the notes from the attached ticket, it looks like refactoring to use the pages router could be an option; was that given any thought?

[zZHorizonZz]

Citing this https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b333434ef6

In traditional SPA setups like CRA and Vite, you have one file like index.html that's served for every route. The downside of this is that (1) it's empty, (2) it contains your entire bundle by default (code splitting and React.lazy doesn't help here a lot because it creates waterfalls — you still have to load the main bundle first before it "decides" to load other scripts).
But if you look at what Next.js generated, it's an HTML file per route:
out/index.html
out/404.html
out/stuff/[id].html
So you'd need to teach your static server to do this rewrite:
rewrite / to out/index.html
rewrite /stuff/whatever to out/stuff/[id].html

Proper routing would likely require edits to router itself. I'm not sure this is desirable, as Quinoa supports other frameworks that already handle spas correctly. Additionally, there's the issue of routing dynamic pages with App Router.

As for Pages Router, it might work if you have SPAs disabled. However, it would still require changes to support dynamic routing similar to Next.js. For example, the router would need to account for all route styles, including:

• Dynamic segments: [slug]
• Catch-all dynamic segments: [...slug]
• Optional catch-all dynamic segments: [[...slug]]

The router would then need to map these to the correct file. For example, post/2020/second-post/with/catch/all/routes should return post/[...slug].html. However, we would still need to determine how to configure these routes within the router.