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 ?
Related
I'm new to AngularJS, and i'm want to know what's the best and easiest practices to do this simple shop list application.
So this is my shop:
I got three servers in my select input. Each server got own list of items, displayed in another component.
I'm thinking about creating routes with variables like localhost:4200/shop/{server1} which gonna show my list of items based on url path. Select option will just change path in my application to show shop list for specific server.
Is it a good practice, or there is better and easier solution to implement this simple shop application?
If you're asking if filtering data with routing is a good practice with Angular, I can say that it is not a bad one. Here's a link to the official Angular documentation about routing : Angular - Routing
But if you're asking if it is the only way to filter data or spread parameters, the answer is clearly no. Angular projects are SPA (Single Page Application), so you can do everything without touching the url.
For a quick example, you can attach a (click) event on your elements that display the shop list you want
I think you can use just one component and three different click events to display three different results. One component can work in your case. Using a router and routing logic for your requirement will be a costly affair. Your user will have a better application feel if these are covered in just one component and with three different click events.
Using AngularJS 1.5.8 and Django/Django REST Framework as the back-end.
At this points have two URLs (app/ for login and app/dashboard as the main content); would be great to just have app/.
login and dashboard I have as components; navbar and sidebar I have as directives.
Using ngRoute currently and somethings I am reading lead me to believe I should be using ui-router to accomplish this.
Just some basic things that came to mind.
My sidebar has several tools I am developing. I want the user to be able to click on them, and then have the content related to that tool load in the main content area without the page refreshing or the URL changing.
Some of what I have read suggests ui-router might be better for this purpose? I am not, sure as I am just learning AngularJS and still struggling with its concepts. Thus, I don't have any code to post that needs to be fixed. Primarily just trying to understand the concepts and technology I need to look into to accomplish this. Makes it hard to lookup results on Google and SO when you aren't even sure what the terminology and tech is that you should be looking for.
Not sure if ngRoute or ui-router should be used; whether the modules should be built as components or directives; if the content for each tool stays in its own HTML template; etc...
This is a somewhat broad question but what you are looking for is client-side routing. Both ngRoute and ui-router offer this functionality and in very similar ways except ui-router offers significant extensibility with nested routes and multiple named view containers.
My advice is to start with ngRoute and learn it's ins and outs and then switch to ui-router if you find you need this extra functionality.
Client-side routing can either be used with the hash-bang (#/) or using html5 mode you can use a base URL that would function visually like server-side routing.
Now you've got the terms to search at least so happy Googling!
js app that I use MEAN stack at that time I didn't know there was such of thing like mean stack. The problem im having is that I use a more common web approach for example I don't handle my routing in angular I use the traditional full page reload using node/express.js.
I have two question for the experience MEAN stack developer first does it worth it to change my routing to use angular so I can have a more traditional MEAN stack app and the second question is what would be a good file structure to my already builded application for example do i make my "/" route to send res.sendfile('./public/index.html');and then I can control the routing for my angular?
I'm just looking for any advice before I make the change. I don't think it would take me that long since I already use all the technologies.
thanks :)
You have the right idea, and I would encourage you to make the switch. First, like you said, it wouldn't take a lot of time to do. Therefore the cost of learning a new approach is minimal and you stand to lose nothing by it. I think you'll be happy with the results. Serve up a single page on / like you suggested, handle routing in angular instead of in the server, and keep your views in your /app folder, or whatever you like to use. The rest of your servers routes can serve as an API for AJAX requests for data.
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 working website build on top of Google App Engine (Python + Jinja2 template engine). I would like to start redesigning it to be single page application using Backbone.js and Underscore.js. The goal is to use progressive enhancement strategy.
The site will still be rendered using backend on the first visit. And then if the browser supports JavaScript the Backbone.js will take over.
I decided to do it this way for two reasons. First all the links I already have will stay intact and second the Google indexing bot will be able to crawl the site content.
I have two problems with this approach:
I need to have two templates for almost everything on my site one on the backend (Jinja2) and one on the frontend (Underscore.js). I was wondering what are the best practices in cases like this? Is there anything you can suggest to avoid having two templates for everything?
How do I load the templates for the frontend to use Backbone.js + Underscore.js? I can load them all in the initial request or request them asynchronously when they are needed.
I appreciate any thoughts!
Thanks.
Some resources:
http://ricostacruz.com/backbone-patterns/
This one describes how to bind Backbone.js to existing HTML:
http://lostechies.com/derickbailey/2011/09/26/seo-and-accessibility-with-html5-pushstate-part-2-progressive-enhancement-with-backbone-js/
So I recently(this year) went through a similar situation. I'll let you know a head of time that #1 is an incredibly tough thing to deal with. Keep in mind, that you not only would have to duplicate your templates, but ALL business logic surrounding your site. For example, let's say you allow users to add comments on a particular page. Using the method you described, you would have to both have a comment template on the server-side and the client-side, and additionally, duplicate the logic required to add/delete/edit a comment on both the client and the server(to accommodate users with and without javascript). Duplication of the templates is easy using Jinja2 function blocks, but the duplication of the logic is where it gets interesting. I attempted to do just that, and ended up doing a full re-write a few months later.
So the advice I would give to you is ditch the idea that you can support both javascript and non-javascript users. Make your site for one or the other. I personally chose to go the javascript route myself. This leaves you with two options. Make a single page app, or make an app that largely leverages javascript for functionality, but renders everything server-side. There are probably a number of other options, but those are the two most popular that I have seen. I went with the second option. So what I do, is the initial page load is done by the server. Backbone.js then consumes each element and makes models and views out of them. This is largely done leveraging data attributes. So for example to create a comment view I would have an element like this:
<div class="comment" data-id="1" data-body="You Suck"></div>
I would then consume said comment, and create a model out of it like so:
var CommentModel = Backbone.Model.extend();
var comment_el = $('.comment');
var comment_model = new CommentModel($(comment_el).data());
Finally, I would back a view with that created model, which can then add functionality to the site:
var CommentView = Backbone.View.extend({
initialize: function() {},
edit: function() {},
delete: function() {}
});
var comment_view = new CommentView({
model: comment_model
});
Then you might be asking, "What if I need to re-render something, don't I need client-side templates for that?" Nope. Client-side templates are a pretty new thing. I personally try to avoid them as I don't think we're quite there yet, and I have always felt that single-page apps are just not responsive enough for my tastes. I'm sure there are plenty of people who would disagree with me on that, but that's the stance I took with my most recent project. So that being said, I render everything on the server and send the html to the client in the form of JSON, which I then inject into the DOM. So I have a ton of api endpoints, which return JSON to my Backbone.js code. This is what is currently working out for me, but this problem is largely situational usually. You have to really look at what your needs are. For it's worth, I largely based my current system off of what Twitter eventually decided to do after trying the whole single-page app thing. You can read about it here.