Optionally set session data with a url parameter, and reference data with dot notation #705
Conversation
referencing of session data using dot notation instead of
array notation. This means you can be more consistent with way you
reference values in the template and in the app code (routes files).
eg. {{ data.participant.profile.name }}
Data in the session can now be set with a parameter passed in the
url, also using dot notation.
eg. /question?participant.profile.name=stef
This data will be added to the session data, or overwrite existing
values. You may not want to merge this data into the session data
but still access the values in the template. To do this, you can
use the data.query value in the template to access the url parameters.
Include the additional parameter '&persist=No' in the url. This will
prevent the values being merged into session.data, and subsequent
pages in the journey will not retain this value.
eg. /question?participant.profile.name=stef&persist=No
This would let you access the value in the template with:
{{ query.participant.profile.name }}
Add code to check for parameters passed in the query which have string
values wrapped in square brackets. It treats the comma as a delimiter
and turns the value into an array, attaching it to the session at the
path indicated by the parameter key. This is good for passing a
query in the url which contrains a list of checkboxes which should
be set when the page loads.
eg. /question?participant.profile.faveColors=[yellow,burgundy,pink]
|
Hi @gonogo This looks really useful! We would be happy to add this functionality but we will need to have tests to make sure that this functionality doesn’t break in the future. We are going to be adding more test coverage for some code related to session data, so you might want to consider waiting until #709 is completed first. We also would need to add some documentation to https://govuk-prototype-kit.herokuapp.com/docs/session to explain how this works. Let me know if you need any help doing this. Nick |
|
@NickColley How should we go about doing tests? What's the easiest way? Unit tests seem a bit too much for prototyping, perhaps the session data defaults should be seeded with some default data, and a series of pages under /views/tests which cover the scenarios of use and expected outcomes? This is a really useful feature so it would be nice to get it in. Happy to write docs. |
|
@chrisneale we are going to be adding more test coverage to this area of the code, so once that's done it'll be easier for you to add that test coverage. We may be able to do some of this for you, but it might take a bit of time before we get to it 👍 |
|
I like this change, however if it was added and I updated my prototype kit to the latest version it'd be a breaking change. I'm using URL parameters as a means of showing temporary flash messages. My preference is for the saving to data to match how you’d do it elsewhere, by prefixing params with |
|
Closing this, realistically there's no time left for me to do any more work on this as my contract finishes today. Might reopen this and get some work done on this next time I do some work on a GOV.UK project. |
|
I'd really like it if this / something similar could be introduced - i've got lots of data in nested objects and arrays, and being able to set them through query strings would be really useful. @fofr we don't prefix with Minor thing - should |
Update autoStoreData function to use Keypather library to allow
referencing of session data in templates using dot notation instead
of array notation. Array notation ['value']['value'] still works.
This means you can reference session data in the template and
in the app code (routes files) in the same way (using dot notation).
eg. {{ data.participant.profile.name }}
Data in the session can now be set with a parameter passed in the
url, also using dot notation.
eg. /question?participant.profile.name=stef
This data will be added to the session data, or overwrite existing
values. You may not want to merge this data into the session data
but still access the values in the template. To do this, you can
use the data.query value in the template to access the url parameters.
Include the additional parameter '&persist=No' in the url. This will
prevent the values being merged into session.data, and subsequent
pages in the journey will not retain this value.
eg. /question?participant.profile.name=stef&persist=No
This would let you access the value in the template with:
{{ query.participant.profile.name }}
Add code to check for parameters passed in the query which have string
values wrapped in square brackets. It treats the comma as a delimiter
and turns the value into an array, attaching it to the session at the
path indicated by the parameter key. This is good for passing a
query in the url which contains a list of checkboxes which should
be set when the page loads.
eg. /question?participant.profile.faveColors=[yellow,burgundy,pink]