I have an ember.js router based application with an interesting quirk. Since the router documentation is rather sparse, I'm not sure if this is a feature or a bug or an un-intended consequence of some of my code elsewhere.
When I reload the page containing the app in my browser, the App jumps to the route of where I last was. I have the routes serialized as a hash. So an example would be I'm on app.html#/users/1/details and I delete the hash and add a random query variable app.html?reload=randomnumber and load the page. As soon as ember loads, it is adding the #/users/1/details back to that address.
Is this a feature/consequence of ember, or is it some junk that I wrote. I haven't found anything that I wrote that could be causing this so far.
If it is an ember feature, is there a way to disable it?
What are you calling "reload", exactly?
Ember cannot keep any state in your browser when route is serialized using a hash. It has nothing to see with Ember: when reloading the page, the whole state is lost, and reset according to requested url returned content initializations.
Nevertheless, when a hash is present, it is used by Ember to reset the router's state.
So what I would suspect is you are still reloading the URL .../app.html#/users/1/details.
Did you take a look at your Network history, in the developer tools (or equivalent)?
The first item should be a GET request, and it will indicate the effective requested URL and the hash if any.
Related
I want a single dynamic route to handle all requests in this application, so I have written a file named [[...slug]].js to do so. I use getServerSideProps() for data loading, so it is server-side rendered, generally. I don't have any index.js files.
When it runs locally in development mode it works perfectly fine. When deployed (to Vercel) everything keeps working except links to /. <Link href={"/"}>… will request an index.json file from the server, get a 404 response and show error page. Why?
Gotcha!
I use getServerSideProps() to fetch data depending on the slug. (Actual content is from Sanity.io and is queried to see if the content's slug property matches either slug from the URL or a default page slug).
When running the app in local development mode with next dev, the params.slug argument will be undefined when loading the root ("/") URL. It has the same value whether the root URL is loaded by a refresh or a navigation action (clicking a link to /, using back button).
However, when the site is deployed, this behaviour changes. params.slug is still undefined when the page is first loaded, but if it loads in response to a client-side navigation event the slug is suddenly set to index. Since I neither had a page with slug index nor ensured we used the default slug when index was requested, I got unexpected 404 responses. Using "index" as one of the values that triggers the default slug fixes it.
I don't know if it is a bug in Next JS, but it was definitely a gotcha that confused me for a while.
As I know, this is to visit a route and pass param to the url
$location.path('/home').search({key:'value'})
This is to clear every param and url and visit the route, history is keep
$location.search('').path('/home');
How about don't keep the history? Like transactional flow, once the user paid, you don't want to let the user to be able to go back. I know there's history service but I think there's more simpler way to do it. I tried to use valina javascript redirect method but it reloaded the entire page which is inconsisten for my SPA.
You can call
$location.search('').path('/home').replace();
and it will not create an extra record in the back-history of the browser.
See documentation here.
I am using mithril 0.2.2-rc.1. I saw in the routing documentation:
Routing is a system that allows creating Single-Page-Applications (SPA), i.e. applications that can go from one page to another without causing a full browser refresh.
Indeed when I am routing to the same page with different parameter only the part that I want to change is refresh expect this :
m("img[src='assets/images/logo.png'][alt=''][width='100']")
I can see in the network communication that the image is reloaded (another GET request).
Is there a way to avoid that?
route.js
m.route.mode = "pathname";
m.route(document.getElementById('app'), '/', {
'/': main,
'/modelling/:level': main
})
It's difficult to see how the two pieces of code fit together, but two things suggest themselves:
Every change of route (even if that change results in the same route entry, eg /modelling/x to /modelling/y) will result in the entire DOM being regenerated. You can prevent this behaviour by calling m.redraw.strategy( 'diff' ) in each route component's controller.
Repeatedly requesting the same resource does not lead to extra calls to the server: a multi page site with every page requesting the same JS and CSS will only load those resources once, and will hit browser cache on subsequent requests. Thus repeatedly asking for the same image resource will not generate any new calls to the server.
If you check the documentation of the m method you will see that the config attribute lets you retain elements across redraws. So this should work for you:
m('img', {config: function persist(el, isInit, context)}) {
context.retain = true;
}
I have an web app. Basically its a single page application. The initial page is a flat html file called index.html, with a single script declaration pointing to require.js. From there I use backbonejs to handle the client side logic. The index.html is being served by nodejs.
My issue is that, any action within the page, for example, i click on a link, the backbone router is called. Which is the behavior I want being a single page application.
For example: www.testserver.com then i click on a link which shows a modal screen for registration www.testserver.com/register, via backbone router with push state on
The issue arrises when, instead of accessing a certain link within the app, i open the url straight in browser. For example I paste, www.testserver.com/register, in the browser. The request is then sent to my node router. I am assuming this is the correct behavior, since the page doesnt exist yet, meaning the backbone router doesnt exist as well.
I was wondering, on what the correct work around for this is. What am i supposed to do, when i access this link? How do i pass the correct behavior back to my backbone application.
Thank you very much.
The server should return always the index.html page. When you start the router in your Backbone than, the router handle the navigation and call the function you defined for the actual route.
Assuming you don't need to do any SEO type stuff such that each unique URL loads its own metadata, just always serve the same index.html as stated. However if you want to have different static head content based on the URL, you should do that within node based on the path (e.g. keep an array of metadata for each route that you slip into a slightly-more-dynamic initial view template, based on your existing flat index.html)
I've been looking for some javascript hooks for the back button in the browser. But they only seem to support back/forward between hashed url's. That is, you can only navigate from www.mysite.com#page1 and www.mysite.com#page2, if you click back, and the url becomes something without a hash, they all fail. Like this one: http://www.asual.com/jquery/address/samples/tabs/ Click one tab, then back, it won't work.
But on http://www.beautyoftheweb.com they've managed to get the backbutton to work between hashed and non-hashed url's. Any idea how they've done this?
Are you sure? I'm seeing a hash:
http://www.beautyoftheweb.com/#/highlights/all-around-fast
^-- here
But assuming there are some URLs that don't have them: What kind of failures are you seeing elsewhere? I have an intranet app where I'm using Really Simple History for history management, and you can happily go backward and forward between URLs whether or not they're application URLs using the hash, application URLs not using the hash, or completely unrelated URLs for other pages/apps. (You can also bookmark the hashed ones, and the app comes back to the right place when you use it.) That works in my app because on initial load, I look to see what hash (if any) is present and reload that state as necessary. (I don't rely on — or even use — RSH's data-storage aspect, just the hash manipulations.)
Edit Just tried the live demo of the first jQuery history plug-in I found in a quick search. It handled going back and forth between "hashed" and "unhashed" URLs just fine. I went to the "#2" link, then edited the URL in the address bar to remove the hash entirely and pressed Enter. That took me to the correct page. Then clicking Back I got the "#2" page correctly. In fact, if you go here I'm linking directly to the "#2" link, and it loads its state accordingly. I think you've been seeing some naive use of history libraries where the coder hasn't handled the initial load correctly.
From what I see, all the URLs are of the form http://www.beautyoftheweb.com/#/<something>, for example: http://www.beautyoftheweb.com/#/experience/cnn - hence, all are using hashes.