LG-12824: camera perm msg

[dawei-nava]

🎫 Ticket

Link to the relevant ticket:
LG-12824

🛠 Summary of changes

Update the camera permission message.

Refactor form step error message processing(Alert), add a messageProcessor to format/process the configured message.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Step 1: Login with or without selfie on mobile
• Step 2: Proceed to document capture/upload
• Step 3: Deny camera access
• Step 4: Verify the error message

👀 Screenshots

If relevant, include a screenshot or screen capture of the changes.

After:

En	Es	Fr	Zh

[kellular]

Cross-referenced with the DOS translations. LGTM!

Also confirming that I included screenshots from this PR in the LQA doc for DOS to review. Thanks Dawei!

[charleyf]

I'm approving because this does work. I'm including some changes I think will improve future readability in comments. I think we should avoid passing messagProcessor and use a pattern more like InPersonOutageAlert.

[charleyf]

I'd expect this component to look more like InPersonOutageAlert and HybridDocCaptureWarning. Practically, that would look like removeing the messageProcessor argument from form-error and instead moving the transformation code inline like this (this code may not work as is).

export function StepErrorAlert({ error }: { error: Error }) {
  const { message } = error;
  const messageProcessor = formatHTML(message, {
    strong: ({ children }) => <strong>{children}</strong>,
    span: ({ children }) => <span className="display-block margin-top-1em">{children}</span>,
  });
  const transformedMessage = messageProcessor(message);

  return (
    <Alert key={message} type="error" className="margin-bottom-4">
      { !!transformedMessage ? transformedMessage : message }
    </Alert>
  );
}

[dawei-nava]

@charleyf , unfortunately, this is a shared component form-steps, most of cases, this transformation not needed.

[charleyf]

Ah, I missed how this component is shared. I do think this code could be changed (or commented) so that it's clearer that we only need and expect the messageProcessor for the single type of error it's needed for (a CameraAccessDeclinedError with this.isDetail === true), but it works as is too.

[dawei-nava]

@charleyf, since we do the transformation logic in form-steps, maybe it is more natural to add it in form-error other than CameraAccessDeclinedError.

[charleyf]

That could help. What about in CameraAccessDeclinedError also do the message processing. This allows us to make no changes in either form-error or form-steps. So something like this:

    return this.isDetail
      ? messageProcessor(t('doc_auth.errors.camera.blocked_detail_html', {
          app_name: getConfigValue('appName'),
        }))

[dawei-nava]

@charleyf , i believe that's the first thing i tried? For some reason if you pass a html string to the <Alert> component as Error.message(which has type of a string), it's not rendering as html, but as a string as is. There are may be some small tweak can be done to it. What's your thought?

[charleyf]

I think that this does the same thing, but without modifying any of the more general files:
https://github.com/18F/identity-idp/compare/charley/suggestions-for-camera-perms

[dawei-nava]

Again this try format message every time which mostly not true or have different styling requirements?

{stepErrors.map((error) => {
        const formattedMessage = formatMessage(error.message);
  return (
    <Alert key={error.message} type="error" className="margin-bottom-4">
      {formattedMessage || error.message}
    </Alert>
  );
})}

I am wondering what is the clean way to render error.message correctly in Alert if it contains html fragment.

[charleyf]

what is the clean way to render error.message correctly in Alert if it contains html fragment

I'm not sure there is a good way to do this. You're trying to detect when something is a string vs when it has HTML tags, which seems like a hard problem.

I'm proposing that instead of trying to detect HTML vs strings, make the HTML formatter function work with either. That avoids a lot of complexity.