It's almost a month learning angularjs. What I have understood till now is that angularjs forces you to create SPA's though you can create multiple page application/website as well but I don't know how as I don't find good examples out there. Even angularjs seed projects are using SPA concept.
By multiple page website some questions I need answers are:
Will Multipage application able to handle query params just like SPA easily? if yes then how? i.e would we use ngRoute or something else?
Until now I have concluded that there is no way of communicating two controllers if they are on separate pages other than using localStorage, sessionStorage or cookies. Right?
Will we able to handle global events across multiple pages? i.e. If two tabs are open and on 1st tab user logs out, will on second page I can get event notification? (Well I am sure yes, but experts can better tell)
Although SPA is easy to implement (well for my case) and makes HTML fragment easy to handle, but I don't have that case right now as it's not application that I am building, I have complex site that SPA is not the right fit. In short I don't want to use ng-view. So please guide with examples if possible.
If you don't use ng-view, then $route is almost useless. You will have to handle param manually in that case
You are right.
Not possible to communicate between two tabs by angularjs. Angularjs will be instantiated independently in two tabs. You will have to maintain it from server end to the opened tabs
Related
I'm trying to develop a website in Angular. My website happens to be a Multi-Page Application (MPA), where different pages have been developed as different components. I have developed those pages of the website, I was just wondering how can connect those components/pages together like on a button click, the user should be directed to another page, etc.
Also, it would be really great if anyone could provide any references to some resources or tutorials where they teach us how to develop Multi-Page Application (MPA) with the help of Angular. I searched online for quite a while and didn't find anything since Angular is mostly used for Single Page Applications (SPA).
Any help would be highly appreciated. Thanks!
In your scenario it is really important to have some kind of state saving as a SPA does lose its state on hard reload i.e. CTRL+R.
A common approach would be the use of the localStorage to preserve your data that you need to restore the state, but the downside of it is the security as it can be viewed from the devtools.
Another approach would be the use of cookies which requires a backend. I think this is straight forward and commonly asked how to implement cookies.
That's the same approaches how other SSR (server side redered) pages are handle its state.
Additionally:
I think I kinda guessed your problem as you just have different component on different routes. Angular is a SPA, but this does not mean it cannot change the route. It will change the route, but without reloading the browser. There you can reach other components. More about that I would recomment to read this Tour of Heroes example:
https://angular.io/guide/router
Currently we have a large Angular 1 application with a number of routes and modules. We'd like to be able to redo certain pieces of this app with the benefits of a newer framework such as Vue.js, without having to rewrite everything. It seems simple enough to change a link that would load a route to now navigate to a new index page which loads a Vue app.
However, on the new Vue portion of the site, we still want to have the same header as the Angular parts of the site. This header has the functionality of navigation, displaying dropdown lists, showing data and notifications for the user, etc. It seems like we have a couple options moving forward:
Rewrite the header and its functionality in Vue, giving it the same styling. For each page with its own javascript framework, we need an implementation of the header.
Have a single implementation of the header that can be included by whichever page needs it, regardless of framework.
Option 1 isn't very DRY, considering that you'll have to modify each header implementation when you want to make changes. But it seems simpler than option 2, which starts to get difficult when you consider that the body of a page might have to communicate with the header (Vue.js code needs to tell Angular header to add notification, for example) unless header updates are done with something like websockets. Also add on top of that the performance issues with potentially using multiple frameworks on the same page.
Overall our goal is to have an extendable frontend. I don't want to be restricted to developing in framework x for a certain project. I've done a little bit of research looking for real world examples, and came across the concept of "micro-frontends", but I haven't found too much consensus on how to solve something like this.
So my application is growing and becomming a fullscale enterprize application.
Because of this clients of my application has different request as to how it should look and feel.
Some of them want all of the content and some of them wants only parts of the content.
Because of these request we have to allow the users to costimize the application as they see fit.
Now ive been searching online to find a solution to how you might deal with this and i want to hear your opinion on the following:
The application contains the following features:
Chat
Forum
Usermanagement
Games
Now all of these features are used on different pages, some of the features are bound together to make 1 page an example of this might be:
Now the idea was to encapsulate all of these features into an angular module.
And each of the feature components into directives
using the above picture the game highscore would be a directive located in the GameModule.
Say for instance that our clients does not want to use the Game feature. Then all directives located in this module would not be visible / disabled.
Looking at the angular documentation this should be possible. But i need you guys opinion on this? Is is possible to do such a thing and if so how?
I hope you guys understand my question i really want to use best pratice to solve this issue and as far as i can read Modules is the best way of doing this.
As I understand it the "conventional" way to handle page reloads is to duplicate functionality and presentation on the web stack using its controllers, views, and models. I'd appreciate insight on other (possibly better) ways to handle these situations. As well as feedback on the following two approaches:
Reload the js framework based app/suite on every web (stack) app page thus
forcing the js framework to handle all routing and rendering
Use the web stack to route interactions and then use backbone to
display views depending on the interactions.
Thanks!
IMHO the 2. approach is the one Backbone has born to :)
Following this approach we'll finish with what is called Single Page Application.
But to achieve this in medium-large applications can be very exhausting. You have to deal with complicate Router that has to be in charge of initialize or replacing elements, also you have to take care with memory leaks and ghost Views. You have to define a system to refresh your Collections and Models due you are reusing them in every page, ...
So a combination of both approaches can be also a good idea. You can split your application in modules like: ManagingUsers, ManagingPosts, ManagingMedia, create Single Page applications for these modules, containing index, edit, show, ... actions that don't reload the page, and if you move to another module the page will be reloaded and in company of the whole framework and with a healthy memory reset.
I have build a basic backbonejs application and it is one page now handling login, list view and detail views.
I now need to add more business objects to be viewed listed and edited, and I was wondering if there is a best practice on when to move beyond the one page?
BTW it is backbonejs on the front, nodejs and express is on the back
Not really.
You can build the entire thing as a single page app using a router to handle the dispatching between all the various views.
You might want to make "namespace" pages, so like /auth/ is a file that loads just the auth parts of your site, /posts/ might be all the blog posts, etc.
This way you're not loading a ton of javascript into the browser in case someone doesn't never need to use a certain function.