-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist and retrieve rtn-req set up session values #814
Persist and retrieve rtn-req set up session values #814
Conversation
https://eaflood.atlassian.net/browse/WATER-4384 This PR will allow the application to persist data through the 'return-requirements' journey. The data will persist in the session until it is cleared by another part of the application. The data will be used to populate controls and fields so that the user can edit or review, and also for UI updates.
2c8d44a
to
ced8c2f
Compare
19f9014
to
2d238fc
Compare
…up-session-values
…up-session-values
This PR also includes minor amends to pages that were worked on in this PR, namely changing UI control names from Also where appropriate, the tests are also split into the respective journeys, either 'no-returns-required' or 'returns-required'. This is because the same view/presenter/service is used, but the output is different when presented on the "Check your Answers" page or the next page in the respective journey. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cleary, I've just got a head full of NITs!
Awesome work. Ping me if any issues or when updated and I'll jump straight back on and ✅ !
app/presenters/return-requirements/check-your-answers.presenter.js
Outdated
Show resolved
Hide resolved
@@ -2,7 +2,7 @@ | |||
|
|||
/** | |||
* Formats data for the `/return-requirements/{sessionId}/start-date` page | |||
* @module StartDatedPresenter | |||
* @module StartDatePresenter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔍 👍
test/services/return-requirements/submit-purpose.service.test.js
Outdated
Show resolved
Hide resolved
} | ||
}) | ||
}) | ||
|
||
describe('when called', () => { | ||
describe('with a valid payload', () => { | ||
describe('with a valid payload for currentStartDate', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we mean currentStartDate
? Or should this be licenceStartDate
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch, I changed the test but forgot to update that to licenceStartDate
@@ -47,29 +69,21 @@ describe('Submit Start Date service', () => { | |||
} | |||
}) | |||
|
|||
it('fetches the current setup session record', async () => { | |||
const result = await SubmitStartDateService.go(session.id, payload) | |||
it('saves the submitted value', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT
it('saves the submitted value', async () => { | |
it('saves the submitted values', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏽
} | ||
}) | ||
|
||
it('saves the submitted value', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT
it('saves the submitted value', async () => { | |
it('saves the selected option', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏽
…r.js Co-authored-by: Alan Cruikshanks <[email protected]>
…r.js Co-authored-by: Alan Cruikshanks <[email protected]>
Co-authored-by: Alan Cruikshanks <[email protected]>
…rvice.js Co-authored-by: Alan Cruikshanks <[email protected]>
Co-authored-by: Alan Cruikshanks <[email protected]>
Co-authored-by: Alan Cruikshanks <[email protected]>
Co-authored-by: Alan Cruikshanks <[email protected]>
…up-session-values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having properly clocked the context where journey
rather than view
was being used ( 🤦 ) I think the only thing I have left is about splitting the check your answers tests at the top level; we can get the same result without splitting things at the very top level for the presenter.
test/services/return-requirements/submit-purpose.service.test.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment still applies here
I 💯 agree it's going to make things easier to manage if we test 'check your answers' separately depending on the journey. But I believe we can do this with the same tools and not break a convention. For example
describe('Check Your Answers presenter', () => {
describe("when the 'no returns required' journey was selected", () => {
// ...
})
describe("when the 'returns required' journey was selected", () => {
// ...
})
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amended this
6d5bdd5
to
52d4c20
Compare
@@ -12,17 +12,17 @@ const CheckYourAnswersPresenter = require('../../../app/presenters/return-requir | |||
|
|||
describe('Check Your Answers presenter - No Returns Required', () => { | |||
let session | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is whitespace we would normally leave in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
restored the whitespace
await _save(session, payload) | ||
return { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one still doesn't look to be resolved.
test/presenters/return-requirements/check-your-answers.presenter.test.js
Outdated
Show resolved
Hide resolved
Happy to ignore the SonarCloud duplication issue for now. Once we have the journeys complete we can take a more informed view as to what refactoring needs doing. |
…er.test.js Co-authored-by: Alan Cruikshanks <[email protected]>
…up-session-values
…up-session-values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://eaflood.atlassian.net/browse/WATER-4384
This PR will allow the application to persist data through the 'return-requirements' journey.
The data will persist in the session until it is cleared by another part of the application.
The data will be used to populate controls and fields so that the user can edit or review, and also for UI updates.