What is the purpose of Backbone's Router? Can't we do the same thing without it? With a router, a click on a link would change the URL of a page and the last bits of the URL would trigger a function. Why not just assign a click event on this link and trigger a function there?
I don't use backbone specifically, (rather, I use iron-router for my project) but it's purpose is to route URLs to pages. Consider the following: you have 50 links scattered across your website's source all pointing to /awesomePlace (which serves awesomePlace.html). You've decided awesomePlace isn't so awesome anymore and have declared that there is a moreAwesomePlace.html. You could go in and change each of those 50 links to /moreAwesomePlace or you could change the route once. The router could then serve up moreAwesomePlace.html whenever anybody visits /awesomePlace.
That's just one example. I personally haven't spent too much time with routers yet but I'm sure somebody can give some better examples than I have. Hopefully this helps explain things a bit though.
Yes, we can implement same functionalities without router, router is just an helper utility, just like JQuery for DOM manipulations. Reason behind using router all about scalability and flexibility. If you follow "on click do some thing", it does't scale. In a single page application every click might have multiple handlers. One click on item might demand changes to multiple widgets. with routers you can add/remove hooks for the same click. And in future if you want to change the implementation of Router or hooks, you are free to do that, only thing that you need to make sure is contract btw these two remain same.
Related
I have been following the concept of componentalization, and is an advocate of it, but kind of looking for a solution for a normal scenario below. It could be that my approach is wrong and must be changed, or something I am unaware of. I have been looking everywhere and trying out many things, but havent seen a success. It must be something I missed out.
I want to add a componenent with internal routing. Basically, the idea is this component can exist on any page, but uses a relative route from its parent to be in a particular state.
The requirement is that it can exist in different tabs which has states and it has to be a directive.
Can someone help me out with this concept or point me in the right direction? Would want to implement it in AngularJS 1.4
Edited
The below image depicts the scenario. Can we place the register component/directive in any tab, be it dashboard or tab2 or tab3.
We also have states in the Register component( I understand that states work in when config runs), but those are to be handled in the component code, but should stay independent of the parent route, like a standalone component.
eg: if component ABC is in page1, the route should be page1/ABC/step1
if later we decide to move it to another page, the route should be page3/ABC/step1 and this has to be done without adding the routes "page.ABC.step1" and "page.ABC.step2"
So the idea is to move around the directive without changing route configs.
I hope I have conveyed the idea properly. If you need more do let me know.
I'm joining a team that is currently working on a single page app. It is written with AngularJS, but it doesn't matter for the topic.
The App is so complex (many independant views with complex different states within each) that they completly removed the router (well, excerpt the default route).
I'm googling around but I can see no example of webapp that is not trying to work properly with URLs. Is there any risk of not using any URL, beyond the fact that "it is not the elegant way" ?
EDIT : ui-router does not fit, because of this issue : https://github.com/christopherthielen/ui-router-extras/issues/90
It sounds like you want to look into something like UI-Router which works on states.
https://github.com/angular-ui/ui-router
I can't imagine any significant issues with your app if you do it this way, but I can see massively bloated controllers and code to try and get around any issues you find.
as #Varedis said, you can use ui-router, but to answer your actual question, consider the use case for urls.
If you have only one url, there's only one entry point into your app. This can be annoying if the user expects to be able to quickly go to a certain area (state) within your app. Only one url means that the user can't bookmark, directly go to, or find with a search engine, any specific part of your application.
You can use other mechanisms like cookies or LocalStorage to keep track of state, but these are less user-visible.
I work on the project and i founded a month ago, ui-router-extras which provide parralel states but it can't instiante more than one state instance.
Is there another solution to do that ?
I'm working on an isolated scope custom directive that has a few different states.
Does it make sense to use ui-router/ui-view inside this directive in order to handle the states?
It's a "note widget" that lists notes. If there are no notes, it displays a message instead of the list that says they should add a note. If notes are being loaded, it shows that notes are being loaded. If a user adds a note by clicking the add I mentioned above or the + then the view is a textbox. So there is at least 4 different views.
My initial instinct is that it would be polluting the directive and giving it a hard dependency to ui-router and my application because it defines the states. Am I just over worried?
I would tell it this way: yes, use the ui-router, but not for a directive - use it for your appliation. In fact, the best you can do is to read few blog posts and go through sample application to understand the principles. You'll soon realize, that there is no need to use the ui-router partially..
from The basics of using ui-router with AngularJS (by Joel Hooks)
...ui-router fully embraces the state-machine nature of a routing system. It allows you to define states, and transition your application to those states. The real win is that it allows you to decouple nested states, and do some very complicated layouts in an elegant way.
You need to think about your routing a bit differently, but once you get your head around the state-based approach, I think you will like it...
and here AngularJS State Management with ui-router (by Ben Schwartz)
...The most interesting thing about AngularJS's new router, isn't the router itself, but the state manager that comes with it. Instead of targeting a controller/view to render for a given url, you target a state. States are managed in a heirarchy providing inheritance of parent states and complex composition of page components, all the while remaining declarative in nature...
Here I put together all the links, up to date, targeting the sample example, the most interesting code snippet sample.js..
Summary, try to implement the ui-router on the application level. Directive could then by a conductor only, helping your users to navigate, to walk through among states...
I've read a lot of threads here but can't find a real answer.
I'm building a desktop app that first loads a lot of json records (let's call them "cards"). Then the user can filter them down with by using many checkboxes, so he can "sum/substract" options (read: query vars).
I'm also trying to use routes.
So, I can have for example (and I don't really know if I'm doing it the right way):
app.com/#/cards/?near_address=London
app.com/#/cards/?near_address=London&cat=concerts
app.com/#/cards/?near_address=London&cat=concerts&day=8
app.com/#/cards/?near_address=London&radius=10000
[...]
Basically, every time the user change filters, I should add/remove query vars.
I could do it in many ways, for examble using some simple "state" json object, but I'm not sure it would be a good practice, mostly because I'm not really sure if I can instead do it maybe only by using routes (I'm quite new to the routes concept).
Is there any "good practice" in doing this kind of things with backbone?
thank you
Using routes to store state is actually a very good idea. That's what routes are there for, to store state, but it's up to you how granular you would want to go with them. some developers choose to go route per page and some choose to get more granular like your example and that's perfectly fine too. You just have to be careful not to go overboard and make your URLs too long and cryptic.
Using routes to store states gives your a few really important benefits:
Your pages will be refreshable. There is nothing more annoying than refreshing a page and losing all your progress and be take back to the start page of the app.
Your URIs are sharable. I could create a filter see the result and send the uri to anyone and they would see the same page as I was.
They make your life easier as a dev. which goes back to your pages being refreshable, they allow you to change your styles or scripts files and refresh the page and see the updated page without having to navigate through your app to get back to the same view over and over again.
I have a web application with require.js, backbone.js and jquery.
The brief structure of the app is as follows:
There are 2 sections on the screen (toolbar and main content below).
There are multiple components (address management, event management), each triggered by a hash fragment change and require a
page transition.
There is one backbone.js router. It's the heart of the application. The router is activated with a new hash fragment (manually entered,
back button, menu item selection).
Up until now, in the router, I made the page transition, I DIRECTLY called the controller ("view" in backbone) of the selected component.
So there's a CENTRAL handling of controller calling.
But this has to change now to a DISTRIBUTED handling. I now need to respond to a new hash fragment from two different places: From the toolbar component and from router.
So my idea is to exchange the direct controller calling mechanism with pub sub. Now MULTIPLE components could register for a special action and the router just "fires the event".
I searched around and found Chaplin (https://github.com/moviepilot/chaplin), a backbone.js example application.
The developers of Chaplin seem to have a similiar thing called "ApplicationView" (https://github.com/moviepilot/chaplin#toc-router-and-route):
"Between the router and the controllers, there’s the ApplicationView as
a dispatcher."
Is there anyone who has already this kind of architecture and can tell me his experience with this or has anybody solved this in another way?
I've used a similar, though maybe less complex, architecture in this project. I give a pretty good explanation in this answer to a related question. The quick overview:
I manage app-wide events that change the application state using a singleton State model that works similarly to Chaplin's pub/sub architecture. This is just a basic Backbone model, with some added methods to deal with serializing and deserializing attributes as strings, so they can be set in the URL.
Application components that change the application state in response to user interaction or other input do so by setting properties on app.state.
Components that need to update when the application state changes do so by binding to change events on app.state (it looks like this is exactly the way Chaplin's mediator works, though they renamed the methods to fit the pub/sub paradigm).
I treat my routers like specialized views that update the address bar and respond to user input in that area. Changing the address (manually or by clicking on a link) causes the router to set() the necessary changes on the app.state model, and everything else updates accordingly.
I hope that's helpful - I think it's a little simpler than the Chaplin approach.