-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[No QA] Add lint rule for functional component declaration style #20724
Conversation
Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers! |
@parasharrajat @marcochavezf One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
I'm removing the C+ review from this PR because we can't really reasonably test it beyond basic smoke tests. It will be subject to regression testing on staging, and ultimately seems very unlikely to introduce any bugs. |
insets={insets} | ||
/> | ||
); | ||
function WithSafeAreaInsets(props) { |
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.
Are we also changing the nested functions? Logically this is a component.
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.
Not sure I understand ... the outer function withSafeAreaInsets
is a plain function, and the inner on WithSafeAreaInsets
is a functional component (because it returns a JSX element).
So the inner functional component should follow our functional component style.
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.
So the inner functions that returns JSX
should also be using function
keyboard.
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 can't think of why we'd make an exception here. This change looks good to me.
How should this be written using
|
@parasharrajat I think we are only concerned about named functions and not anonymous functions. Anonymous functions should always use the arrow function syntax. |
Ok, Thanks. But my general question is that
|
Reviewer Checklist
Screenshots/VideosWebMobile Web - ChromeMobile Web - SafariiOSAndroid |
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 scanned all the files quickly, and the changes LGTM. Also did some smoke tests and looks good.
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
@parasharrajat My inclination would be that we do this: function EmojiPicker() {
...
}
export default React.forwardRef((props, ref) => (
<EmojiPicker
// eslint-disable-next-line react/jsx-props-no-spreading
{...props}
innerRef={ref}
/>
)); But I think technically either can be valid. As @marcaaron said, anonymous function components like the one passed as an argument to |
@parasharrajat my 2 cents are that |
🚀 Deployed to staging by https://github.com/marcochavezf in version: 1.3.28-0 🚀
|
🚀 Deployed to production by https://github.com/AndrewGable in version: 1.3.28-5 🚀
|
Details
This really should have no effect beyond enforcing code style. Very little of this was done manually. All I did here was:
Then I ran
npm run lint
again, and noticed that manyeslint-ignore
comments were removed:Logs from second run of `npm run lint`
So I manually added back those eslint-ignore comments in 053e8a2, then lint was passing.
Fixed Issues
$ #20643
PROPOSAL: https://expensify.slack.com/archives/C02NK2DQWUX/p1686574009182619
Tests
This touches too many files to reasonably test them individually. We should run basic smoke tests here to see that the app runs and works as expected, but we need to have some faith that the eslint rules' auto-fixer works.
Offline tests
n/a
QA Steps
None. This should be covered by regression testing.
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
this
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Web
Mobile Web - Chrome
Mobile Web - Safari
Desktop
iOS
Android