-
Notifications
You must be signed in to change notification settings - Fork 120
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
LG-3427: Update doc auth ID support texts #4228
Conversation
|
||
describe('document-capture/context/service-provider', () => { | ||
it('defaults to undefined', () => { | ||
const { current } = renderHook(() => useContext(ServiceProviderContext)); |
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've been using @testing-library/react-hooks
in some side-projects, and it seems like it's a nicer way to get at the context values. I think it could be used to replace a few ad hoc approaches we've used thus far:
identity-idp/spec/javascripts/packages/document-capture/context/device-spec.jsx
Lines 6 to 12 in 9b37653
const ContextValue = () => JSON.stringify(useContext(DeviceContext)); | |
it('defaults to an object shape of device supports', () => { | |
const { container } = render(<ContextValue />); | |
expect(container.textContent).to.equal('{"isMobile":false}'); | |
}); |
identity-idp/spec/javascripts/packages/document-capture/context/acuant-spec.jsx
Lines 81 to 93 in 9b37653
render( | |
<AcuantContextProvider sdkSrc="about:blank"> | |
{createElement(() => { | |
const { isReady, isCameraSupported } = useContext(AcuantContext); | |
if (isReady) { | |
expect(isCameraSupported).to.be.true(); | |
} | |
return null; | |
})} | |
</AcuantContextProvider>, | |
); |
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.
Screenshots look good! 👍 I had ticketed this in LG-3521 in case it needed to be addressed separately - so we can either cancel or consider it completed.
Not following the technical side of this, but @amathews-fs previously worked on a bunch of logic for this screen and might be a good reviewer? Thanks!
<div class='mt2 mb2'> | ||
<p> | ||
<%= t('doc_auth.info.id_worn_html') %> | ||
<a href="/"><%= t('doc_auth.info.accepted_ids') %></a> |
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.
- Can we use the
link_to
helper? - Should we drop a comment or something to call it out since we don't have this URL yet? Rubocop gets mad at TODO so maybe something else?
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.
- Can we use the
link_to
helper?- Should we drop a comment or something to call it out since we don't have this URL yet? Rubocop gets mad at TODO so maybe something else?
Whoops, I totally overlooked this. It was (is) a work-in-progress, pending a relevant Slack question about where exactly this link should point to.
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.
Some more quick thoughts on this:
- Can we add a method in our MarketingSite class for it?
- Should we expose this URL as yet another data attribute to the React app to minimize duplication?
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.
Some more quick thoughts on this:
- Can we add a method in our MarketingSite class for it?
- Should we expose this URL as yet another data attribute to the React app to minimize duplication?
Yeah, I'd been waiting to see how exactly we wanted to approach this before coming to any decision on implementation. But if we're going to direct users to the marketing site, I agree it makes sense to add a method there. I'd also agree that it makes sense to expose it to the React app as a data-
attribute. I'm not quite as sure how best to actually make this data available to the component, aside from introducing yet another context provider, possibly mapping directly to this MarketingSite
class. It doesn't really fit well into any of the existing context values.
It's also got me thinking a bit about future re-use. The idea of a React context which captures some or all of the values from the MarketingSite
class seems clean enough and ripe for reuse, though unclear right now to what extent we want to go down this path (which methods? which package? or new package(s)? etc.)
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'm not quite as sure how best to actually make this data available to the component, aside from introducing yet another context provider, possibly mapping directly to this
MarketingSite
class. It doesn't really fit well into any of the existing context values.
Is it worth just collapsing all our existing contexts into "DocAuthContext" or something? We only have one React app/page today?
Is there any performance penalty to having too many small contexts?
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.
Is it worth just collapsing all our existing contexts into "DocAuthContext" or something? We only have one React app/page today?
We've finally found our way to the eternal debate of multiple contexts vs. global store (Redux) 😄 We could certainly have opted to just shove everything into a single global state object. At our current position, I'd personally still lean toward pushing forward and continuing to use distinct contexts. There's a bit more overhead with managing each one, but it forces us to be somewhat more intentional, and potentially opens up some options for reuse in the future.
Short-term, I imagine this would look like: MarketingSiteContext
in the same pattern as other contexts, likely only with a single property for the "Acceptable IDs" link.
Is there any performance penalty to having too many small contexts?
Not that I'm aware of, or at least not one I'd be particularly concerned about at our scale. Usually it's the opposite, where contexts have an advantage over global store approaches where global stores cause lots of unnecessary re-renders of components which ultimately aren't concerned with the change and won't have a changed rendered result (example).
{formatHTML(t('doc_auth.info.id_worn_html'), { | ||
strong: 'strong', | ||
})}{' '} | ||
<a href="/">{t('doc_auth.info.accepted_ids')}</a> |
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.
just wanted to highlight this as another pending URL we'll need to change
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.
@aduth following up on the "Full list of state-issued IDs" link - since this URL/content doesn't currently exist, we can omit it for now, and add it to this screen as an improvement when it's ready. Thanks!
Removed in bf68bee4f. |
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.
LGTM! hopefully we can get those "list of acceptable IDs" links working before we merge
139f078
to
af70499
Compare
**Why**: Improved reuse of strings between server-side and client-side
af70499
to
be8dac4
Compare
Pending the development of a "Full list of accepted IDs" resource, I've removed the link in be8dac4. |
(Partially addresses LG-3427 and LG-3521)
Why: As a user, I want to be informed of recommendations and options for ID usage in IAL2 proofing, so that I have the most chance of success.
Of the task described in LG-3427, the changes proposed here currently only update the desktop "Upload" and mobile introductory steps at the beginning of the proofing process to use updated texts. The remainder of the work will be implemented as separate pull request(s).
Screenshots:
Mobile:
Desktop: