Skip to content
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

Remove Lint Exceptions: Prop Type Exceptions #10521

Closed
wants to merge 15 commits into from

Conversation

charleyf
Copy link
Contributor

No description provided.

.eslintrc Show resolved Hide resolved
@charleyf charleyf changed the title Charley/remove react lint prop type exceptions Remove React Lint Prop Type Exceptions Apr 30, 2024
@charleyf charleyf changed the title Remove React Lint Prop Type Exceptions Remove Lint Exceptions: Prop Type Exceptions Apr 30, 2024
@charleyf charleyf marked this pull request as ready for review April 30, 2024 18:20
Comment on lines 39 to 44
// eslint-disable-next-line @typescript-eslint/no-unused-vars
const defaultRegisterField = (string) => undefined;
const DEFAULT_PROPS = {
toPreviousStep() {},
onChange() {},
registerField() {},
registerField: defaultRegisterField,
Copy link
Member

Choose a reason for hiding this comment

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

Could we instead update registerField to support void as a supported return type?

) => undefined | RefCallback<HTMLElement>;

➡️

) => undefined | void | RefCallback<HTMLElement>;

Copy link
Contributor Author

@charleyf charleyf May 1, 2024

Choose a reason for hiding this comment

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

I removed the inline exceptions, but adding void didn't seem to work.

Unfortunately adding void as a return type causes more type issues than it solves. An example:

// `app/javascript/packages/address-search/components/address-input.tsx`
        <TextInput
          required
          ref={registerField('address')} // This is either undefined or `ForwardedRef<HTMLInputElement>` adding 'void' here seems like a bad idea.

Copy link
Member

Choose a reason for hiding this comment

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

Oof. Okay, in that case, maybe we could at least inline the default?

  registerField: () => undefined,

Copy link
Contributor Author

@charleyf charleyf May 1, 2024

Choose a reason for hiding this comment

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

Much better. For some reason I couldn't get the inline function to work before, but now it works. 👍

Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

Couple minor comments, but LGTM 👍 Glad to be starting to chip away away at some of these exceptions!

import BackButton from './back-button';
import AnalyticsContext from '../context/analytics';
import { InPersonContext } from '../context';
import UploadContext from '../context/upload';

function InPersonLocationPostOfficeSearchStep({ onChange, toPreviousStep, registerField }) {
interface InPersonLocationPostOfficeSearchStepProps {
Copy link
Member

Choose a reason for hiding this comment

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

Elsewhere we extend an interface exposed by FormSteps which helps avoid repeating the type signatures, and also surfaces additional props that are available. Maybe we should do the same here and in InPersonPrepareStep and InPersonLocationFullAddressEntryPostOfficeSearchStep?

interface ReviewIssuesStepProps extends FormStepComponentProps<ReviewIssuesStepValue> {

@@ -39,7 +39,7 @@ const USPS_RESPONSE = [
const DEFAULT_PROPS = {
toPreviousStep() {},
onChange() {},
registerField() {},
registerField: (_string) => undefined,
Copy link
Member

Choose a reason for hiding this comment

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

If we're going to list the unused argument, I'd think we should name it the same as it's named in the original type signature (field). There's also technically an options parameter as well if we wanted to be exhaustive.

Personally, I don't think it matters much to list the arguments, which is why I left it out in my previous recommendations.

field: string,
options?: Partial<FormStepRegisterFieldOptions>,

@charleyf charleyf closed this May 22, 2024
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.

None yet

2 participants