The problem:
I have a express backend/angularjs frontend web app hosting all of my teams documentation for our users. We frequently need to post links to a specific question (all linked as ids) to our users in Slack. ex. helpapp.com/productTheyNeedHelpWith#QuestionLinkedTo the problem is that when the link is clicked from slack, not when copy/pasted, Slack launches a new browser window/tab to helpapp.com/productTheyNeedHelpWith%23QuestionLinkedTo.
This breaks ngRoute as it no longer recognizes /productTheyNeedHelpWith as the path to load the correct page for and the user gets sent to our home page instead.
Thoughts on possible solutions:
I'd like to solve this issue either in the ngRouting itself by somehow updating the path by replacing %23 with # before $routeProvider does it's magic, or by somehow capturing the full url in app.js and updating it or redirect to an updated version before we've rendered a page view at all.
currently I've set a workaround by using a ng-init event to check the url and, if %23 is found, update it and replace it with the correct extension but this causes an odd double load that leads to a poor user experience.
Final Thoughts:
As I'm not sure of the best way to go about this, and because our code is proprietary, I'm avoiding posting to much 'example code' that may not be relevant but am happy to provide any parts of it that you, wonderful stackoverflowers, may request. Thank you in advance for your assistance.
Related
When developing a web application with angular js, a part of time that developers spend is the time for implementing routing.
When using ui-router in a application, there are two "phases" to consider with regards to routing:
user navigates inside application: when click is made on some button, user is transfered to another state by using $state.go("somestate"). Parameters can be send etc. And url is changed accordingly.
user navigates directly via url.
Lets say application has such route:
/mythings/{thingid}/mysubthings/{mysubthingid}
If user navigates to that url directly by pasting it into browser window, application needs to handle it. My question is what's the best practice to do it?
What I'm thinging is: if looking at url example above what needs to be done when user enters that url in browser:
get {thingid} from url (from $stateParams), then get {mysubthingid} also from $stateParams (probably by using resolve (ui-router feature) when defining state), then inject what was resolved to controller and then make a query to api and get data about "subthing" and present view in ui with that data. So that should work with both "types of navigations": when user clicks and is transfered to state, or when user enter url directly into browser. Is this the right path to go?
And I suppose that any url you go to when you click something in application, you should be able to take that url and just paste it into browser and see the same results without being redirected to anywhere else. If application cannot handle every url in such way, maybe application' architecture needs to be reconsidered?
Thanks
In UI-Router, the main component of the routing is the state. The URL is essentially just an address that points to a specific state of the app. I don't think it's necessarily productive to think of the two ways of navigating as separate; they're just two sides of the same coin. There should be no URL that isn't handled by a state. Any URL that doesn't match a state should be caught by the otherwise definition on the $stateProvider and probably redirect to your home page or a 404 page.
In your example, the thing/:thingId/subthing/:subthingId url should map to a predefined state just like any other state. Let's say that state is main.subthing. The process for loading the data, initiating the controller and rendering the UI should be exactly the same whether you get there by calling $state.go('main.subthing', {thing: 123, subthing: 456}) or ui-sref='main.subthing({thing: 123, subthing: 456})' or you paste myapp.com/thing/123/subthing/456 into the browser. They'll all end up at exactly the same place with exactly the same data by calling the exact same logic (most likely loading thing 123 and subthing 456 in resolves and injecting those into a controller).
You're right that if a url can't be handled by the application, that's a sign that something is wrong. Like I said, bad urls should be handled by defining otherwise when setting up states. But pasting a URL into a browser shouldn't require any extra work if your states are defined correctly. URL handling is baked into UI-Router by default.
I partially agree with you. The point where I disagree is when the URL is obtained by a user who is not supposed to access it. Quite often some websites implement authorization code to check if the user who is currently accessing the page is authorized to do so.
Also I think the route could be a bit different. Something like:
{thingid}/{mysubthingid}
This, I think is a cleaner URL and the parameters could be handled in the same way as the one in your example.
I suggest this in order to make it a bit difficult to unauthorized users.
Anyway, it definitely depends on the kind of application you are implementing. If the app's requirement is to be able to access the page by pasting the URL in the browser then I guess your approach is much better.
When routing in Angular views we add the following. I don't understand the need to add #; if I remove it, I get a 404 Error.
a href="#/AddNewOrder"
Putting # in URL indicates start of the hash part, which is used to address elements inside a single page. In modern single-page web applications, this can be used to address application states.
If you don't put the # there, you're changing the path, which means you're creating a new URL and prompting the browser to load the content at that new URL instead of the current page.
As other posters have suggested, you don't have to use hashes when using html5mode. I left it out, because it brings a few challenges of its own, which I feel to be outside the scope of the question.
enter link description hereYou don't have to. You can configure your URLs to look like normal URLs, but in reality they will still work the same way.
Check https://docs.angularjs.org/guide/$location
And refer to html5mode
It will only work in modern browsers though. Old browsers will still show the hash. But the cool thing is that you can write your URLs the old/normal way.
# or fragment identifier is a way to indicate a specific portion of a single document. Without the #, the url corresponds to a different page.
For example www.yoursite.com/page links to the /page location of your website, while www.yoursite.com/#/location points to the same index page of your website but at a specfic point in the web page #location, or in your case, a different template view.
Angular routing can not load different templates for different server urls. It is specifically designed for single-page applications and any loading of partial views or templates has to happen on the same web-page or location. Hence only the fragment part of the url changes when using angularjs routing.
More information about fragments can be found here: http://en.wikipedia.org/wiki/Fragment_identifier
The biggest problem is that I even don't really know how to describe the problem I'm asking about. It's the first time in more then a decade of wed development.
I'm working on a Rails 4.1.1 app and using angularjs pretty extensively, though I don't know it well yet. And everything seemed to be working fine up to the moment when I tried to add some browser history manipulation to my app (e.g. changing the displayed url when listing though a paginated list so that that url can be copied and distributed). To do this I added a config to my app.
#app.config ($locationProvider) ->
$locationProvider.html5Mode(true)
And then in my angular controller added the $location binding like this
$scope.$watch 'pagination.cur', (newVal) ->
$scope.loadNews newVal
$location.path("/news").search({page:newVal})
(this is ment to change the url in the browser searchbox when the user goes from one page to another).
That workes well, the url does change appropriately, but all the sudden all the html links on the page got broken. I mean litteraly. I click any link on the page (even outside the controller div), the url in the serchbox changes appropriately, but the turbolinks toes not fire the Ajax request to get the new page content. If I then refresh the page, it loads the correct page.
I know it's really weird. What's weirder, that I don't get any JavaScript errors or anything unusual.
The only way I found to get the links working again - is to remove that initial config.
But when I do it, the $location falls back to hashtag syntax, wich is really not at all what I want.
My only assumption is that there could be some kind of a conflict between angular $location service and turbolinks when handling browser history, but even if that's right, I have no idea how to get around it. And I really need that kind of manipulation, 'cause I'm going to be using it alot in this and other apps.
I really don't know, what other information on this problem may be usefull, don't hasitate to ask for updates. I'll post whatever I can.
P.S. Btw, can this kind of manipulation be done by means of turbolinks? 'Cause it's exactly the same thing turbolinks does when changing the displayed url after page body reload, but I can't find any documentation on its public API for that.
UPDATE
Have no idea what's the source of the problem yet, but it seems to be not related to the turbolinks gem. Removing turbolinks requirements from the application.js file does not change anything.
Using $window.history.pushState instead of $location.path solves the functionality problem, but does not explain the initial bug.
in order to make nice urls, I decide to remove the # from my ulrs using the tip from the following question Removing the fragment identifier from AngularJS urls (# symbol) Now, I realized that my urls are not working if I try a direct access to them. from the given example in the related question if put the url below directly in the browser http://localhost/phones
I'll get a 404.
Any idea how to solve this?
You need to write server side code that will generate the page that you were previously depending on the client-side JavaScript to generate.
This will then be the initial view for that URL.
If the client supports JavaScript (and the JavaScript doesn't fail for any reason) it will then take over for future interactions.
Otherwise, the regular links and forms you (should) have in the page will function as normal without JS.
Not sure what i am missing, but I have pushState working on my Backbone based app, where I could click around and have my URL look like www.example.com/route_specified, however if i try to go directly to that page it shows up as not found. If I do www.example.com/#route_specified it works, and quickly changes back to www.example.com/route_specified on the address bar
I am guessing i need to do something in Apache to handle this and make sure that all calls resolve to the index or something like that, but can't find explanation.
Correct. Think about it this way without pushstate enabled. Your server is still trying to serve the page at that route. Since it cannot find the specified document at that location, it throws a 404.
Technically speaking, your server should still produce some sort of result at the url location, then have Backbone take over. In it's simplest form, this is called progressive enhancement. The server should still serve some sort of static page with critical info, which will eliminate issues you will have with SEO. Work your site/app with javascript disabled, serving only the relevant data. Then have Backbone takeover. I have just come across Mashable's redesign, and they integrate progressive enhancement extremely well with Backbone.
If SEO is not a concern, you could always redirect the user to the index page. Just remember that search engines will only index your app page then. If your content is being served dynamically, there wont be any data to index.
Hope this helps.
Thanks
Tyrone