I am trying to integrate segment.io to work with Angular. My angular app is a SPA so I have to add some code to my components to allow segment to register the page visits.
In the code used to register page visits, there is a property called referrer that, according to the docs is:
Full URL of the previous page. Equivalent to document.referrer from
the DOM API.
The problem I am having is the referrer property value sometimes just remains empty, or sticks to one page even if I move to several other different pages.
So my questions are:
Does referrer mean links outside my app or also the previous routes visited within my app?
Am I supposed to set this manually in the app?
Yes, you're supposed to set it manually in your existing pageview hits to Segment.
Basically, in your case, referrer would be just the previous route. If the previous route doesn't exist, then use the document.referrer.
And yes, organically, if your app doesn't have a previous route, then document.referrer may contain an outside url, which is completely fine and expected.
Also, Segment provides pretty neat support for questions like this, so you can confirm with them.
Related
We've implemented Tealium throughout our site, including some newer, single page app (SPA) content. Our devs are new to Tealium, so we're all kind of building the car as we drive it.
I've read Tealium's docs on both single page apps and the standard order of operations. What I don't fully understand is when vendor tags fire on SPA sections. For example, when I first land on a SPA page, I see the HTTP requests indicating the tags have fired (We haven't disabled the initial page view event yet). But as I navigate around that app, triggering the manual link/view events that the devs implemented in the site code, I see those events being logged but the HTTP requests from vendor tags are inconsistent or not-existent. For example, we have a Google Ads tag that appears to fire with each of these events, but we also have Microsoft Ads tag that does not, despite both tags' Load Rules being configured to load on all pages.
Can anyone confirm whether utag.view() and utag.link() fire vendor tags when called? If I'm misunderstanding a piece of the implementation, I'd be grateful for a clarification. Thank you :)
As a general rule, Tealium knows nothing about your app's events. Like most tag managers, it'll default to firing off a utag.view() indicating a new pageview once the page has loaded, but in an SPA app, that happens once and it's got no hook into your router to understand future navigations.
Rather, it's on you to instrument your SPA and augment the router so that when a new route is successfully rendered, you call a utag.view() and when other actions occur that you want to track, you make the appropriate utag.link() calls as Tealium will not do this for you.
The basic question is if there should be one HATEOAS entry point per page or one entry point for the entire app?
Most examples I have seen implement a single page with a HATEOAS backend, e.g. a list that is paginated using prev and next links. But what happens when the app navigates to a different page that has completely different capabilities and needs a different entry point? How does one organize such an app?
Concrete example: We have an app with tab navigation. The home tab shows a product catalog so the entry point is /products which returns page 1 of products along with pagination links. However, now I click on the orders tab which must show a list of past orders. This page needs a completely different entry point /orders which the home tab knows nothing about. In fact, user can directly navigate to the orders tab using a deep link.
How to think about this problem? Are there any examples illustrating an approach?
There's a few different ways to solve this. Here's two:
The SPA takes context from the uri (such as an id), and uses it to search on the API. The API can describe templated links/actions to search for resources by their id.
Instead of doing client-side routing, let the server decide what to render.
We're going more towards #2. If we have a uri such as:
https://spa.example/https://api.example/foo/bar
We take the path part of this uri and hit the API. Based on what the API responds with, we decide what to render. This means that most of the routing for these kinds of endpoints is delegated to the server, which feels more in line with HATEOAS.
The path part in this case is an entire absolute URI, but we also support relative uris and have a default base uri. So in practice these two uris are equivalent (for our SPA):
https://spa.example/https://api.example/foo/bar
https://spa.example/foo/bar
We develop & use ketting / react-ketting to do most of the heavy lifting
I have a strange requirement. Since I have a 404 page on my angularjs app, I don't want to leave it unnoticed because it has a random joke API added to it.
Now my angular js application uses UI route provider for routing. I have a
$urlRouterProvider.otherwise("/home")
code in my angularjs configuration. I want the page to redirect to home if there isn't any path specified. E.g. https://mypage.com should route to https://mypage.com/#!/home but if someone types a wrong state name manually, it should redirect it to the 404 page.
My only question is since this requires two routings in otherwise statement, is it even possible? And if it is possible, then how?
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