Skip to content

Conversation

@serikjensen
Copy link
Member

@serikjensen serikjensen commented Nov 6, 2025

This is the first iteration of UI prototyping exploration.

Approach

  • Implements a provider component that is completely separated from the UI
  • Exposes a hook for the consumer to get the values fetched in the provider component (core data)
  • Also passes the onSubmit handler through the hook
  • Configures onSubmit to have a return value of the API response so consumers can get the data as they update it
  • Exposes the validation schema to the partner for form configuration
  • Does not include any form utilities other than the validation and submission handler
  • Sets a message constant on the validation schema so partners can provide custom translations
  • Splits BaseComponent into BaseComponentProvider and BaseUIComponent so provider can handle non UI concerns and BaseUIComponent can be used to centralize the base UI concerns (fade in, error alerts, etc) across our components
  • Implements this approach for Contractor address update because it is a relatively small and straightforward component that is easy to move around. We'll still need to stress test this against the other edge cases

import { contractorEvents } from '@/shared/constants'
import { renderWithProviders } from '@/test-utils/renderWithProviders'

describe('Contractor/Address', () => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file just has the original unit test copied over to test for regressions

Comment on lines +52 to +58
const composedDefaultValues = {
street1: formDefaultValues.street1 || defaultValues?.street1,
street2: formDefaultValues.street2 || defaultValues?.street2,
city: formDefaultValues.city || defaultValues?.city,
state: formDefaultValues.state || defaultValues?.state,
zip: formDefaultValues.zip || defaultValues?.zip,
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's ultimately worth it to have the hook supply the default values and merge them here via props. Only thought was, sometimes composing the default values gets complicated

Comment on lines +91 to 92
error,
fieldErrors,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We provide both the error and fieldErrors via context. They only get our UI alerts if they use the BaseUIComponent below.

Still need to figure out how to navigate this with fieldErrors that need to be applied to the form fields. Do we just leave it to the partner to wire those up? Or do we find a way to normalize all form related errors so they aren't getting them from both the validation schema and the fieldErrors

Additionally, we need to investigate more how to help this be more ergonomic so they're not forced to respect both error and fieldErrors

Copy link
Contributor

@jeffredodd jeffredodd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note or two

return (
<FadeIn>
{(error || fieldErrors) && (
<Components.Alert label={t('status.errorEncountered')} status="error">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just leaving notes here as I go so MAYBE i'm missing something. But have we thought about how they might re-locate or reposition this inside their app?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants