Skip to content

Fixing lint errors in dashboard #17156

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

Merged
merged 1 commit into from
Apr 11, 2023
Merged

Fixing lint errors in dashboard #17156

merged 1 commit into from
Apr 11, 2023

Conversation

selfcontained
Copy link
Contributor

@selfcontained selfcontained commented Apr 11, 2023

Description

Fixing a few lint errors. I left a couple of errors that need a slightly more in-depth solution, so didn't want to have this get too large.

Related Issue(s)

Relates to WEB-112

Risk

Low risk, this mostly adds comments to disable lint warnings in a few places, and adjusts some code in what should be a backwards compatible way.

How to test

Preview Env: https://bmh-lint-e194b820244.preview.gitpod-dev.com/workspaces

  • Visit the preview env, poke around a few screens.

Release Notes

NONE

Documentation

Build Options:

  • /werft with-werft
    Run the build with werft instead of GHA
  • leeway-no-cache
  • /werft no-test
    Run Leeway with --dont-test
Publish Options
  • /werft publish-to-npm
  • /werft publish-to-jb-marketplace
Installer Options
  • with-dedicated-emulation
  • with-ws-manager-mk2
  • workspace-feature-flags
    Add desired feature flags to the end of the line above, space separated

Preview Environment Options:

  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-large-vm
  • /werft with-gce-vm
    If enabled this will create the environment on GCE infra
  • with-integration-tests=all
    Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh

/hold

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-bmh-lint-errors-fixes.1 because the annotations in the pull request description changed
(with .werft/ from main)

@selfcontained selfcontained changed the title fixing lint errors Fixing lint errors in dashboard Apr 11, 2023
@selfcontained selfcontained marked this pull request as ready for review April 11, 2023 14:53
@selfcontained selfcontained requested a review from a team April 11, 2023 14:53
@selfcontained selfcontained requested a review from gtsiolis as a code owner April 11, 2023 14:53
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Apr 11, 2023
@@ -35,6 +35,7 @@ export default function ConfirmationModal(props: {
const buttonDisabled = useRef(props.buttonDisabled);
useEffect(() => {
buttonDisabled.current = props.buttonDisabled;
// eslint-disable-next-line react-hooks/exhaustive-deps
Copy link
Member

Choose a reason for hiding this comment

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

What's the reason the linter gets this one wrong so often? And if it's the case, can we tweak the rules/disable?

Copy link
Contributor Author

@selfcontained selfcontained Apr 11, 2023

Choose a reason for hiding this comment

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

I think it's more often overly-using or improperly using the useEffect() hook (from what I've bumped into so far). This linter rule makes sure you include any "dependencies" for your hook, cause if you miss some, it can behave unexpectedly (using stale variable values), so I think it's still preferred to keep the hook as is, and when we have an exception, it's called out with a disabled line like this. In many of these fixes I've opted for the safer approach of not changing existing behavior and disabling the warning vs. adjusting behavior to what might be more correct.

@selfcontained
Copy link
Contributor Author

/unhold

@roboquat roboquat merged commit 66f22e4 into main Apr 11, 2023
@roboquat roboquat deleted the bmh/lint-errors-fixes branch April 11, 2023 16:38
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Apr 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note-none size/M team: webapp Issue belongs to the WebApp team
Projects
Status: In Validation
Development

Successfully merging this pull request may close these issues.

3 participants