Additional fallback for SPA

[Matasx]

Hello,
I'm serving Nuxt SPA JS application from the GenHTTP server. I used the recommended way to first serve known registered API routes and as a fallback use static content from a directory and serve as SPA. This works fine to a certain point.
In my specific case, the SPA application is nuxt.js. The router is set in a way it does not use the client segment of the path for routing as is usual for JS apps (i.e. everything after # sign), but instead it uses the path portion of the url. This works well for static files as the framework also outputs index pages for each path under physical subdirectory.

E.g. if I have a page /accounts/, the framework will generate local file /accounts/index.html that will get served by server and client JS SPA will take it from there.

Now the problem is when I start using resource id parameter inside the path, e.g. addressing the resource as /accounts/123456. This gets routed fine during the initial client side navigation (e.g. user clicks to specific account from account list). Now the problem is when you navigate to this path from new browser context or hit the page refresh, because the request goes to the server first, it will not find and matching content and it will return 404. Afaik the recommended way for serving Nuxt app is to always serve the root index page /index.html and client router will do the rest of the handling depending on the path (e.g. correctly route to the resource or generate 404 page).

I was trying several ways to achieve this with the current state of things, but I couldn't get it to work.

This is my initial setup:

var httpContent = Layout
    .Create()
    .Add("api", api)
    .Fallback(SinglePageApplication.From(ResourceTree.FromDirectory("www")))
    ;

What I would like to have is if the SPA does not find a matching resource, instead of rendering 404, I want it to return "index.html".
Is this currently somehow achievable in the current version or would a change to the GenHTTP library be warranted?

E.g. something like this:

var httpContent = Layout
    .Create()
    .Add("api", api)
    .Fallback(SinglePageApplication.From(ResourceTree.FromDirectory("www")).Fallback(Resource.FromFile("www\\index.html")))
    ;

[Kaliumhexacyanoferrat]

Just for clarification - if /accounts/123456 ist requested - would you expect a HTTP 200 with the content of your index.html? Or a HTTP redirect to your app root? I think returning HTTP 200 will cause some irritation for clients (such as search engines).

We could add a general Fallback concern which will evaluate the inner handler and if it does not return anything return the specified content instead. This would allow to .Fallback() on any handler, and also to specify multiple fallbacks if needed. In your case this then could be:

var httpContent = Layout.Create()
                        .Add("api", api)
                        .Fallback(SinglePageApplication.From(ResourceTree.FromDirectory("www")))
                        .Fallback(Redirect.To("{root}"));

Maybe Fallback is not the right term then anymore. Currently thinking of something like .Then(...) or .ThenTry() or .Or(). Thoughts?

[Kaliumhexacyanoferrat]

See #322

[Matasx]

In general JS client-side rendered SPA apps are not SEO friendly. That's the tradeoff for the page responsiveness. Something that every developer needs to evaluate for themself. I could as well use server-side page rendering and I wouldn't have this problem and it will be also SEO friendly. But I would lose the app responsiveness which is what I'm after. So it may vary case by case, this is just my particular scenario.

That said I think the redirect is not appropriate, because instead of returning the index page, JS kicking in and serving the appropriate page (e.g. the account with id 123456), it would instead just redirect to plain index page and the request information as presented in the url path would be lost.

As for the fluent/builder syntax, I think the keyword fallback is still appropriate, but now the semantics is changing to append, instead of set, so maybe I would consider changing it to AddFallback.