Conversation
ab401d0 to
f935271
Compare
| const { setParentErrorState, parentErrorState, letterRenderErrorState } = | ||
| useLetterRenderError(); | ||
|
|
||
| useEffect(() => { |
There was a problem hiding this comment.
why does this need to be in a useEffect? also seen elsewhere
There was a problem hiding this comment.
React will throw complaining that we're updating one component whilst rendering another if called directly, because we're bridging between NHSNotifyFormProvider and LetterRenderErrorProvider.
I could potentially get rid of some useEffects by making it more of a one-way thing from the letter render component and handling it in the page, but clearing one form's errors when the other triggers was tricky, and I found it much easier to pick through what was going on when I broke it out into the separate provider, plus it feels more easily reusable if we end up genning renders anywhere else
| customSection: { | ||
| heading: 'Custom personalisation fields', | ||
| error: { | ||
| required: `Enter example data for {{field}}`, |
There was a problem hiding this comment.
| required: `Enter example data for {{field}}`, | |
| required: 'Enter example data for {{field}}', |
| ...props | ||
| }: Omit<HTMLProps<HTMLInputElement>, 'type'>) { | ||
| }: Omit<HTMLProps<HTMLInputElement>, 'type'> & { id: string; name: string }) { | ||
| const [state] = useNHSNotifyForm(); |
There was a problem hiding this comment.
Just wondering if it would be worth moving this or wrapping this in the NHSNotifyForm directory. We have a few "connected" components in there and exposed like NHSNotifyForm.Input, NHSNotifyForm.RadioInput etc. Since this now has to be rendered inside an NHSNotifyForm provider, then it might be better to move it into that mini module.
There was a problem hiding this comment.
Updated, and got rid of the full div, since it was only used in the pdf upload so is going away anyway
0a016e6 to
549b0f1
Compare
| this.errorSummary = page.locator('[class="nhsuk-error-summary"]'); | ||
| this.errorSummaryLinks = this.errorSummary.locator('a'); |
There was a problem hiding this comment.
I feel like errorSummary exists on the base page so probs dont need this one?
and might be good idea to add the links locator there too, what do you think?
| getInlineError: (fieldId: string): Locator => | ||
| panel | ||
| .locator(`[id="${fieldId}"]`) | ||
| .locator('xpath=..') |
There was a problem hiding this comment.
what you doing with this?
There was a problem hiding this comment.
it steps up to the parent div in order to find the correct sibling .nhsuk-error-message. Though now you ask it, I can't recall why I ended up doing it this way rather than just giving the error messages IDs 🤷♀️ will give the latter a try in the morning
1d94c65 to
b64137a
Compare
| await expect(shortErrorLink).toBeHidden(); | ||
| }); | ||
|
|
||
| test('shows both short and long example errors when personalised renders have failed', async ({ |
There was a problem hiding this comment.
I'm confused about this one - if the render has failed, will "Enter short example data" fix it?
There was a problem hiding this comment.
It has when I've done this scenario manually, but that's because there was nothing wrong with the ability to render and I'd manually edited in ddb to recreate it. No idea what could cause a genuine failure here so hard to say what we should be advising - if it were a transient carbone glitch or aws issue then rerender would be appropriate, but I suppose either way the message isn't accurate.
There was a problem hiding this comment.
Chatted with Lee about it, I'm thinking any scenario where a render is FAILED, either it will be resolved by a rerender, or we're in servicenow territory anyway (some system issue or eg the original docx has vanished from s3). Either way its not normal operations, so it's probably not worth giving it special handling, as long as we're pointing them at trying the render again (which will presumably be displaying 'No preview available' so it'll be obvious there's a problem), and blocking them from approving the template?
| test('activates the hidden tab and focuses the field when its error link is clicked', async () => { | ||
| renderTabsWithError('hidden-tab-field'); | ||
|
|
||
| const rafSpy = jest |
There was a problem hiding this comment.
My main thought here is "is there a way to test this without all of this mocking?"
So e.g.
const field = document.querySelector('#hidden-tab-field');
expect(field).toHaveFocus()const field = document.querySelector('#hidden-tab-field');
expect(focusMock).toHaveBeenCalledTimes(1);
expect(focusMock.mock.instances[0]).toBe(field);
userEvent tends to be a better option than fireEvent, I don't know if that'd help?
There was a problem hiding this comment.
Or can it be covered in playwright on the relevant pages?
There was a problem hiding this comment.
I think this is an improvement? 😵 and added a playwright test
|
|
||
| /** | ||
| * Handles clicks on error summary links that point to form fields inside unselected NHS UK tab panels. | ||
| * Iff the target field is inside a hidden tab panel (`nhsuk-tabs__panel--hidden`), the default |
There was a problem hiding this comment.
| * Iff the target field is inside a hidden tab panel (`nhsuk-tabs__panel--hidden`), the default | |
| * If the target field is inside a hidden tab panel (`nhsuk-tabs__panel--hidden`), the default |
There was a problem hiding this comment.
Was actually intentional (if and only if), but fair 😅
e215de9 to
b49897e
Compare
cc47125 to
f9300b9
Compare
| ); | ||
|
|
||
| expect(container.asFragment()).toMatchSnapshot(); | ||
| expect(focusMock).toHaveBeenCalled(); |
There was a problem hiding this comment.
are we still testing this somewhere else?
| 'Choose example recipient' | ||
| ); | ||
|
|
||
| const summaryLink = previewPage.errorSummaryLinks.filter({ |
There was a problem hiding this comment.
are we clicking these links anywhere?
Description
Context
Type of changes
Checklist
Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.