Add referrer (request source) to global context #486
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-4155 In our working building the new bill page we are required to add a 'back' link. One of the things we have to deal with though as that you can come to the page from 3 different sources - bill run summary - billing account summary - billing account all bills The previous team solved this by using a bit of JavaScript. Simply set `javascript:history.back()` as the `href` and job done. Can't blame them for this one as it's a solution a number of digital services use. But it's a bit of cheat. For a start, we're supposed to support users accessing a service with JavaScript disabled. That immediately breaks all your back links. Plus, if you've ever found your journey through a site go a bit screwy, for example you find yourself going in a loop, chances are it's because of back links implemented this way. Ideally, the request you generate would tell the handler where to go back to if there is more than one possibility. But as we're dealing with request from the legacy app that's not really feasible. Fortunately, either the browser or Hapi is coming to the rescue (I'm not sure who so both get credit). The headers in the request normally include [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) (yes that's a misspelling - see [Wikipedia](https://en.wikipedia.org/wiki/HTTP_referer#Etymology)). Hapi provides this in [request.info.referrer](https://hapi.dev/api/?v=21.3.2#-requestinfo). If we have that, we have our 'back' link address. This change tweaks the global context in our `ViewsPlugin` to include this value so it is available to all pages. We also add a new `back-link.njk` which shows how we can use it to generate our back links. > Note - yes, we also fall back to the JavaScript hack if the value is not available. No ones perfect!
Jozzey
approved these changes
Oct 27, 2023
Beckyrose200
approved these changes
Oct 27, 2023
Cruikshanks
added a commit
that referenced
this pull request
Nov 7, 2023
The initial requirement for the story was that however a user comes to the new bill view page the back link should take them to where they came from. This could be 1 of 3 places currently - bill run summary - billing account summary - billing account all bills When you first come to the view bill page we use [referrer](#486) to generate the back link. At this point we can get you back to where you came from. But that list is incomplete with the addition of the view bill-licence page (see WATER-4156 ). So, you come to the view bill page, then click through to the view bill-licence page and then go back, now `referrer` is the view bill-licence. This results in the user being stuck in a loop. ``` [source] --> [view bill ] --> [view bill-licence] --> [view bill ] [back = source] [back = view bill ] [back = view bill-licence] ``` Having discussed this with our designer, we both agree having the back link attempt to recreate what the back button does is an anti-pattern. Back links we build into the pages should help a user navigate through a _planned_ journey. Essentially, if you come from, for example billing account summary, you have jumped from the licence summary journey to the bill runs journey. As such when you go back, you should go back through the bill runs journey. There are relevant points that allow the user to switch back, for example clicking the Billing account link in the view bill page. If the user wants back button behaviour then the button is always there.
Cruikshanks
added a commit
that referenced
this pull request
Nov 7, 2023
https://eaflood.atlassian.net/browse/WATER-4155 https://eaflood.atlassian.net/browse/WATER-4156 After a first pass of the new view bill and bill-licence pages we've built some issues have been spotted. This change resolves *** Broken screen reader text in 'View transactions link'** We overlooked updating the context property being referenced in a refactor. *** Fix undefined in view bill licence We were only setting, for example, the `additionalChargesDetail` variable in the template if there were additional charges. But we were then referencing `additionalChargesDetail` when setting `detailChargeInfo`. ```nunjucks {% set detailChargeInfo = detailChargeInfo + additionalChargesDetail + adjustmentsDetail + '</p>' + elementDetail %} ``` This is why the template was showing `undefinedundefined` when a transaction had no additional charges or adjustments. By flipping the logic, i.e. always instantiating a variable but only populating it when something exists we avoid Nunjucks thinking `additionalChargesDetail` or `adjustmentsDetail` are ever undefined. *** Use set address for view bill backlink The initial requirement for the story was that however a user came to the view bill page the backlink should take them to where they came from. This could be 1 of 3 places - bill run summary - billing account summary - billing account all bills When you first come to the view bill page we use [referrer](#486) to generate the backlink. At this point we can get you back to where you came from. But that list is incomplete with the addition of the view bill-licence page (see WATER-4156 ). So, you come to the view bill page, then click through to the view bill-licence page and then go back, now `referrer` is the view bill-licence. This results in the user being stuck in a loop. ``` [source] --> [view bill ] --> [view bill-licence] --> [view bill ] [back = source] [back = view bill ] [back = view bill-licence] ``` Having discussed this with our designer, it was agreed having the backlink attempt to recreate what the back button does is a type of anti-pattern. Backlinks we build into the pages should help a user navigate through a _planned_ journey. Essentially, if you come from, for example, billing account summary, you have jumped from the licence summary journey to the bill runs journey. As such when you go back, you should go back through the bill runs journey. *** Better backlink text Following on from our decision to always have backlinks take you to a specific point in a _planned_ journey we also agreed we'd make it clearer where the backlink will take you in the UI. We're using the [advice in the design system for back links](https://design-system.service.gov.uk/components/back-link/) to use different link text. > For more complex user journeys, consider using different link text, like ‘Go back to [page]’. For example, in an admin system with many different areas. In this case, if you used ‘Back’, it might not be clear to users what they are going back to. We've applied this advice to both the view bill and view bill-licence pages.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-4155
In our work building the new bill page, we are required to add a 'back' link. One of the things we have to deal with though is that you can come to the page from 3 different sources
The previous team solved this by using a bit of JavaScript. Simply set
javascript:history.back()as thehrefand job done. We can't blame them for this one as it's a solution a number of digital services use.But it's a bit of a cheat. For a start, we're supposed to support users accessing a service with JavaScript disabled. That immediately breaks all your backlinks. Plus, if you've ever found your journey through a site go a bit screwy, for example, you find yourself going in a loop, chances are it's because of backlinks implemented this way.
Ideally, the request you generate would tell the handler where to go back to if there is more than one possibility. But as we're dealing with requests from the legacy app that's not really feasible.
Fortunately, either the browser or Hapi is coming to the rescue (I'm not sure who so both get credit). The headers in the request normally include Referer (yes that's a misspelling - see Wikipedia).
Hapi provides this in request.info.referrer. If we have that, we have our 'back' link address.
This change tweaks the global context in our
ViewsPluginto include this value so it is available to all pages. We also add a newback-link.njkwhich shows how we can use it to generate our backlinks.