Develop Reference

Nuxt - dynamic params after building does not work

In a Nuxt ("spa" mode) project I have a url with a dynamic param /shop/:product, which can be as such:
/shop/ipad-128gb-rose-gold
/shop/subway-gift-card
/shop/any-string
etc.
Using this directory structure works fine in development environment:
pages/
shop/
_product.vue
However it does not work in production. Looking to the generated bin/ folder I see that there is nothing inside shop/ directory. And I see that Nuxt mentions a solution here: https://nuxtjs.org/api/configuration-generate/#routes
But in my situation, I don't know what the :product param will be (could be any string).
I am fetching the product details in pages/shop/_product.vue from the server (if it exists), otherwise handling the error. So now how do I do that in a production build?
I think I am misunderstanding the Nuxt solution -- am I really supposed to generate all possible routes for every existing product slug??

The solution for me was to use:
// nuxt.config.js
export default {
...
generate: {
fallback: true
}
}
I am serving the app out of the built dist/ folder. And I came across this in the Netlify deployment docs:
For a single page app there is a problem with refresh as by default on
netlify the site redirects to "404 not found". For any pages that
are not generated they will fallback to SPA mode and then if you
refresh or share that link you will get Netlify's 404 page. This is
because the pages that are not generated don't actually exist as they
are actually a single page application so if you refesh this page you
will get a 404 because the url for that page doesn't actually exist.
By redirecting to the 404.html Nuxt will reload your page correctly in
SPA fallback.
The easiest way to fix this is by adding a generate property in your
nuxt.config and setting fallback: true. Then it will fallback to the
generated 404.html when in SPA mode instead of Netlify's 404 page.
References:
https://nuxtjs.org/faq/netlify-deployment/
https://nuxtjs.org/api/configuration-generate/#fallback

When you generate static pages, it produces directories and index.html in each one. How did you expect to have it dynamic if you serve static HTML?
You have 2 solutions:
don't use npm run generate. Run nuxt on the server. Using this solution, you avoid ajax in browser. Instead, nuxt performs it and sends the HTML to the browser. Good for SEO.
have your web server (nginx) point all requests to /index.html - at that point, javascript takes over and it can correctly find the slug and query the products via ajax. Bad for SEO because you need to use ajax to get the content after page finishes loading.
Documentation and configuration about this can be found at nuxt's web.

Handle "Loading chunk failed" errors with Lazy-loading/Code-splitting

We are developing a Vue.js application based on Vue CLI 3 with Vue Router and Webpack. The routes are lazy-loaded and the chunk file names contain a hash for cache busting. In general, everything is working fine.
However, there is a problem during the deployment. Steps to reproduce are the following.
User opens the application (let's assume route "/"), thus the main chunk file is loaded.
We change something in the application and deploy a new version.
Old chunk files are removed
New chunk files are being added (i.e. hashes in the chunk file names change)
User clicks a link to another route (e.g. "/foo")
An error occurs as the application tries to load a chunk file that has been renamed: Error: "Loading CSS chunk foo failed.
(/assets/css/foo.abc123.css)" (this might be CSS or JavaScript)
What is the best way to avoid errors like this?
One approach that should work is just to retain old chunk files and delete them at a later time. That, however, complicates the deployment of new versions as you need to keep track of old versions and always also deploy the old chunk files with the new version.
Another (naive) approach is to just reload as soon as such an error is detected (e.g. Vue Lazy Routes & loading chunk failed). It somewhat works, but it reloads the old route, not the new one. But at least it ensure that consecutive route changes work again.
Any other ideas? Maybe there is something in webpack that could fix this?

DoNOT cache the entry file(usually index.html).
We add:
expires 0;
add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate';
in our nginx server config.
Then, after you refreshed the client's code, you can use the vue-router's error hook to detect the error and do something properly.

As long as you have a versioned API, you can use the old app files (just leave them on the server and delete after a vew days).
You will get problems as soon as your API changes during deployments.
I assume, you deploy a new API each time you deploy new JS code.
Then you can:
Pass on the API version (simply use the git hash) to the application as header with every response (JS resources, CSS, API requests, 404 responses)
Store the API version in your main JS entry point (or make it accessible somehow, e.g. as generated constant)
On each server response, check if the Server version matches your main client version.
If it does not: Display a prominent warning to the user (like the cookie banners) that he should reload the page (=> allows the user to save chnages in hope the API did not change for that save button).
For async components, we display normal 'not found' messages if loading fails, together with a reload button that appears instead of the component. Reloading without user interaction will cause a lot of confusion.

Handling Dynamic Routes Without a Server

Is it possible to serve a dynamic html page without a backend server or without using a front-end framework like Angular?
Edit
To clarify, the index file is served from a backend. This question is about how to handling routing between the index and dynamic pages.
I have an application that consists of two files - index.html and dynamic.html. When the user clicks an option say "Option A", they are served dynamic.html and the url is updated to /option-a. Now, with a server this is no problem and assuming the user visits the app from the landing page, it isn't a problem either because a cookie can be set. However, suppose a user visits a page at my-domain/option-a. That route doesn't exist and there is no server to redirect so it will 404. They would have to visit dynamic.html.
I think this architecture demands that there's either a server to handle route redirects or a SPA framework.
Is there something I'm missing?

your SPA framework will be active only once your HTML page is loaded and to do that you need to redirect any URL that user tries for your domain to that HTML file. For this you obviously need a server (and since you are talking about my-domain/option-a I assume you have atleast a basic server). You can refer to this link to get an idea on how server can redirect a URL to specific html file: Nodejs - Redirect url.
Once HTML is loaded you can initialize your SPA framework and decide the template to be loaded based on the URL.
Note: without a server you will access URLs using file://somepath/index.html and anything other than this URL will result in 404 and no SPA framework can handle that.

I think the solution is to use a static site generator such as Jekyll or Middleman and allows you to convert information into static pages. That way you functionally are building a bunch of pages but they are all compiled ahead of time. You can add dynamic content that is loaded in from a yaml file and it will compile the content into separate html pages.

It is not possible, but there is a workaround using url parameters like this:
my-folder/index.html
my-folder/index.html?=about
my-folder/index.html?=about/sublevel
my-folder/index.html?=profile
my-folder/index.html?=./games
const urlParams = new URLSearchParams(location.search);
const route = urlParams.get('');
console.log(route);
// Should print "about" "about/sublevel" "profile" "./games"
Of course this approach is not as clean as using a server for routing, but it's the best you can get without a server.
BTW. I tried an alternative solution creating symlinks with all the target routes pointing to the same index.htmlfile. But it did not work because the browser (firefox) redirects by default when it finds a symlink, thus home is shown all the time.

Angular Removed # tags in urls. But not working as expected

I just removed # tag from my url of angular single page app.
I did like.
$locationProvider.html5Mode(true);
And It worked fine.
My problem is when I directly enter any url to the browser it showing a 404 error. And its working fine when I traverse throughout the app through links.
Eg: www.example.com/search
www.example.com/search_result
www.example.com/project_detail?pid=19
All these url's are working fine. But when I directly enter any of the above url's into my browser it showing a 404 error.
Please any thoughts on it.
Thanks in advance.

Well i had a similar problem. The server side implementation included Spring in my case.
Routing on client side ensures that all the url changes are resolved on the client side. However, When you directly enter any such url in the browser, the browser actually goes to the server for retrieving a web page corresponding to the url.
Now in your case, since these are VIRTUAL urls, that are meaningful on the client side, the server throws 404.
You can capture page not found exception at your server side
implementation, and redirect to the default page [route] in your app.
In Spring, we do have handlers for page not found exceptions, so i
guess they'll be available for your server side implementation too.

When using the History API you are saying:
"Here is a new URL. The other JavaScript I have just run has transformed the page into the page you would have got by visiting that URL."
This requires that you write server side code that will build the page in that state for the other URLs. This isn't a trivial thing to do and will usually require a significant amount of work.
However, in exchange for that work you get robustness and performance. When one of those URLs is visited it will:
work even if the JS fails for any reason (such as a dropped network connection or a client (such as a search engine) that doesn't support JS)
load faster than loading the homepage and then transforming it with JS

You need to use rewrite rules. Angular is an single page app, so all your request should go to the same file(index.html). You could do this by creating an .htaccess.
Assuming your main page is index.html.
Something like this (not tested):
RewriteRule ^(.)*$ / [L,QSA]
L flag means that if the rule matches, don't execute the next RewriteRule.
QSA means that the URL query parameters are also passed with the rewrited url.
More info about htaccess: http://httpd.apache.org/docs/2.2/howto/htaccess.html

Problem with forward slash "/" in jQuery AJAX

I always wrote URLs used by AJAX calls in this way: "/Home/Save" with the forward slash in the beginning. Now this last project is being deployed to a virtual directory on a server. Thus, these URLs aren't working anymore, because instead of "example.com/VirtualDir/Home/Save", they would point to "example.com/Home/Save" which is wrong. I quickly fixed the problem by removing the first forward slash "/" in all occurrences of URLs in my JavaScript. All pages work great, except for one! When AJAX call happens on the problematic page, the specified URL gets appended to the page URL. I've spent a few hours yesterday and the whole morning today, and I cannot figure it out. There is absolutely nothing different about this page comparing to others. Has anyone had this problem before? Should I post my code?
EDIT: After banging my head on the keyboard for another few hours, I ended up implementing the following. I got an action in a common Controller that returns the result of Request.Url.GetLeftPart(UriPartial.Authority), which is your http://www.mysite.com. I render it inside my Layout page into a global JavaScript variable, _AppPath. Then, every AJAX call gets its URL like this: _AppPath + '/Controller/Action'. This works everywhere and I still don't know what the hack is the problem with that page. Cheers!

Can you change the Ajax requests so that they instead point to "/VirtualDir/Home/Save"?
If it helps your code, you could have a path variable, so that you can easily update the virtual directory path (or remove it) when you deploy it somewhere else. Or your code could read its location via the window.location.href property and work out things out from there.
It's not so useful to have paths relative to the current document (i.e. without the / slash prefix) because, as you are observing, some of the pages will then fail their requests, when those pages are at a different point in the site hierarchy. An absolute URL would be the one to go for (i.e. with a / slash prefix).
[UPDATED, based on comments below]
#Dimskiy, it doesn't so much matter that the server-side framework is .NET MVC, or that there are no actual folders for those URLs on the server. The browser will just respond according to the URL structure it sees.
So the things to look for are the URLs in the browser address bar for the different pages, and the URLs of the Ajax requests being made to the server (e.g. look for these in Firebug's "Net" panel). And compare the URLs, looking at the number of folders suggested by each URL.
It doesn't matter if there isn't an actual folder on the server. The browser can't tell, it can only look at the URL structure. If the JavaScript is making a call from a page called "foo" to an Ajax resources at "Home/Save", then the request will be routed to "foo/Home/Save". And if the request is made from page "foo/bar" then it will be routed to "foo/bar/Home/Save". That's a relative path - it's relative to the containing HTML document.
A request to an "absolute" path, say, "/Home/Save" (note the / slash prefix) will always go to the root of the domain, e.g. example.com/Home/Save. But since you need your request to go to the "VirtualDir" virtual directory, then your URL will become "/VirtualDir/Home/Save".