I am building a multi-page application and would like to leverage Backbone's Router to initialize my views on page load. I haven't been able to find a way to leverage routers without using hashes and I don't need or want to use push state.
Basically, all I want to be able to do is use the Routers URL pattern matching to match the url and initialize my views depending on which page is loaded from the server.
Perhaps I am thinking about this all wrong or maybe there is a way to do this natively in Backbone Routers that I am missing. Any suggestions are greatly appreciated.
From the Backbone documentation (emphasis mine):
Backbone.Router provides methods for routing client-side pages, and connecting them to actions and events.
In other words, the Backbone Router was only designed to handle client-side URLS (the part after the hash), not server-side ones (the part before the hash). There might be a way to hack the Router and Backbone.History to use full URLs instead of just the hash, but it would not be easy and I'd recommend against it.
One alternative you could consider is some sort of onDocumentReady logic that checks the URL of the page and, if it's hash doesn't match it's URL, adds a hash. This would make it so that if someone visits "/foo" your code would convert it to "/foo#foo", and the Backbone Router could be used normally.
Another option though would just be to write your own "router" of sorts, which will actually be simpler than Backbone's because it only needs to work once per page load. Here's a simple example:
var mockRouter = {
foo: function() {
// do stuff for page "foo"
},
bar: ...
}
$(function() {
mockRouter[window.location.pathname]();
});
Related
Is there a way to keep track of history outside of a backbone router. I have a pagination service provided by Laravel, the links between pages are like the following "#leads?page=7". Everything works, but I have no clue right now on how to apply track of history outside of the router. The router works for the dashboard options but not for the pagination.
I am not using Backbone.Marionette for a single page app, but more for varius tools on my site. I wanted to have Laravel render the initial pages for SEO reasons. I had Laravel write the first pagination block then I have Marionette rewrite it after any interaction. You have to love twice the amount of work, but I like the fact that I don't have to worry about search engine not seeing the page.
In order to do this, I ended up not using the backbone router for this tool at all. I used javascript history. It is only available in newish browsers, but that is what our site supports. If you do need to support older browsers there is a shim, but I have not used it.
// add to history
history.pushState('', 'Search: ' + tags, url);
// get current history
updateUrl: function(){
var currentState = history.state;
return (currentState) ? currentState : $(this)[0].baseURI;
}
It definitely was more work, but I was able to get it working the way I wanted.
I'm structuring a Multi Page App in angular. I have a main app with its ngRoute configured so that the resulting url is something like:
http://localhost:8080/project/main#firstTemplate
http://localhost:8080/project/main#secondTemplate
http://localhost:8080/project/main#thirdTemplate
...
Now I must move to another app in the same project so that the Url is something like:
http://localhost:8080/project/secondary#fourthTemplate
I'm able to achieve this by manipulating the string resulting by $location.absUrl() and pass it to $window.location.href but it's horrible.
Is there a better way to do the same thing?
You should do this by the means of your router. There is a default router in angular, though I would suggest you going with https://github.com/angular-ui/ui-router - as I think it is much better than Angular v1.x defaults.
With that router you can define few states (1 state per each URL), define URL for each state, define views to be displayed in that state, actions on entry/leave etc. Then, you can get access to $state object and its go() method to switch between states - as well as easily have it done automatically on elements by specifying .
My Angular app is splitted into several subapps. I'm working with laravel which is also responsible for the routing between the subapps.
So there are the following urls handled by laravel:
ModuleX: /moduleX
ModuleY: /moduleY
ModuleZ, Item n: /moduleZ/item-n (unlimited amount of items)
And finally on top of these there are my 3 Angular subapps.
So for example: /moduleZ/item-1/#/hello/world
Additionally the templates, partials and a RESTful API are served by laravel under the following urls:
/templates
/partials
/api
If I set the base url with the html tag <base href="http://www.example.com/app/"> I can use relative urls for templates, partials and the api but not for the routing. I'll allways have to add the module url part like that moduleX/#/hello/world.
If I set the base url like for example <base href="http://www.example.com/app/moduleX/"> I can write all links like #/hello/world but the templates, partials and api requests aren't working anymore.
The whole app also sits in a subfolder so I can't just use for example /templates.
So basically my problem or the question now is, what's the best way for handling the different base urls? I don't really like it to prepend the module name to every link.
Look it's might be a particular solution, but may be you should use filters for urls?
For example:
.filter('routeFilter', [function () {
return function (route) {
if (some condition mean this direct html link){
return 'MODULE-X/' + route;
}else{
return route
}
};
}])
I would suggest you let (sub-)apps know their real base not the parent's one, but you make the server responsible for climbing the path hierarchy to find higher level shared resources for missing local ones. This also makes it very easy to prototype new sub-apps, test changes to common pieces independently first, etc.
In a webserver like Apache, this would look like a rewrite rule (conditional on not finding a file) it just substitutes the same file in the parent hierarchy.
In laravel (according to the router docs) it looks like you can add optional 'directories' to your current rules, i.e.:
Route::get('/.../app/templates/{name}', function($name)
...
becomes:
Route::get('/.../app/{module?}/{item?}/templates/{name}', function($name, $module, $item)
...
You could then use $module and $item if you need to test a resource change with specific sub-app/items.
The drawback in making the server responsible for handling inheritance is the independent client fetch/cache of identical resources with different paths. But you can at least choose between large file inefficiency or access latency by using either rewrites or redirects. You can also always hardcode significant paths in production clients later and still benefit from having a hierarchy for testing and graceful handling of occasional errors in client side links.
You can do it in a simpler way if you use combination of service and directive.
You can implement a directive similar to ngHref which when given a link will transform it and append the given link back. It will be injected with a service which will give it the base url or relative url or anything module specific.
This service which is injected in directive will be configured using serviceProvider in app.config block of each sub-app. Since angular injector have only one instance of each service I think you will need more than one injector or one injector per sub-app. Its unclear whether they share injector among them in your app.
You can configure each service according to module to return different base paths. Which will be appended by directive to each link every time.
With this you can use <base href="http://www.example.com/app/"> and that should solve your problem.
I haven't written any code but I can help if you need it.
I have been unable to find any articles on Backbone.Marionette using pushstate withOUT Node.js, or grunt, or require where a serious discussion is made about URL handeling. A user should be able to send a link to an internal page to her grandmother and have the link work, for example. The pushstate functionality seems uniquely ill-suited to the real world. Can someone comment and perhaps provide some links to serious articles on the subject?
Generally speaking, there's really just 2 things you need to do...
Tell Backbone to use pushstate by calling Backbone.history.start({ pushState: true });. You may also need to add something like root: 'myApp' to that parameter if your Marionette app is served from http://example.com/myApp instead of directly on http://example.com.
Configure your web server so that no matter what URL the user requests, the same content (your Marionette app) is returned (without doing a redirect).
The catch is that #2 is implemented differently depending on what type of web server you are using. And you haven't told us what stack you're on. In ASP.NET, for example, this can be handled by setting up a 'catch all' route by adding something like this to your RouteConfig.cs file:
// all requests (except those explicitly handled by another route)
// go to HomeController.Index and then the Backbone router examines
// the URL client-side to determine client-side what to do
routes.MapRoute(
name: "Default",
url: "{*clientRoute}", // this is wildcard which captures the entire URL
defaults: new { controller = "Home", action = "Index" }
);
Other web server stacks will have different ways of achieving the same type of thing.
I'm currently building a single page app using backbone.js
In order to keep all application pages accessible and crawl-able I made sure that the server side can also render the pages when accessing them directly.
The problem is as follows:
When pushState is not available it initiates the router using the current URL (e.g. if I accessed a url with http://example.com/example the router will build the hash fragment on top of that url)
So:
Is there any way of handling this (besides redirecting the use)
If you are redirecting as soon as the JS (using pushState feature detection) you still have a problem of urls not having hash signs.
Generally asking, is there a better approach of designing this kind of application?
Thanks!
I think the evolving consensus is pushstate or nothing (ie to degrade web 1.0 and drop hash-bang routing all together) if SEO-friendly browsing matters to you.
Its one of the reasons I don't use Backbone.js and just use PJAX is that pushstate and DOM rendering times are so good you can be single page with very little JS and hash-bang routing has always been rather hackish.
Thus an option is to not use Backbone's router all together and just let something like PJAX (or DJAX or something similar) do the routing work and let Backbone just do the inner page event/rendering stuff (ie validating forms, modal windows, etc..).