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

RFC: add an ignore option to the must-colocate-fragment-spreads rule #149

Open
rbalicki2 opened this issue Feb 13, 2024 · 0 comments
Open

Comments

@rbalicki2
Copy link

Why

We encounter the following pattern:

  • There is a parent component, UserList, that defines a callback onSelectUser, which accepts an @inline fragment named UserList_onSelectUser_user.
  • This callback is passed to a UserDetail component as props.onSelectUser, to which a user is passed where ...UserList_onSelectUser_user is spread.
  • This eslint rule is not happy, and there is no sane way to work around this restriction, as far as I can tell. (One would have to import UserList from the child component, which is just silly!)
  • We do not want to allow users to suppress this rule, as in 99% of cases, this is a rule we don't want to let users suppress! We're still adopting Relay, so being forceful with respect to best practices is important to us.

We anticipate that this pattern will occur somewhat frequently for us.

What we would like feedback on

  • Would an ignore: RegExp parameter to the rule be an accepted addition? Namely, we would like to opt out of this lint rule by having certain inline fragments contain _inline_ in their name. (We would pair this with an additional rule, probably Pinterest-only, that enforced that only @inline fragments can contain _inline_ in their name.)
@rbalicki2 rbalicki2 changed the title RFC: add an ignore option to this eslint plugin RFC: add an ignore option to the must-colocate-fragment-spreads rule Feb 13, 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

No branches or pull requests

1 participant