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

[BUG FIX] fix bug where form didn't include off Switches #41

Merged
merged 1 commit into from
Jun 10, 2024

Conversation

eriktaubeneck
Copy link
Member

@eriktaubeneck eriktaubeneck commented Jun 10, 2024

turns out the Switch element by default sets the value to "on" if it's on, and removes it entirely from the form if it's off. The API expects a bool, so we override it here.

as an aside, this makes a good case for adding tests, even for some of the front end flows. moving it up my prioritization list.

Summary by CodeRabbit

  • New Features
    • Added hidden input fields for stall_detection, multi_threading, and disable_metrics to ensure these settings are always included in the form data.

Copy link

vercel bot commented Jun 10, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
draft ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 10, 2024 9:34pm

Copy link
Contributor

coderabbitai bot commented Jun 10, 2024

Walkthrough

The recent changes primarily focus on enhancing the IPAForm function within server/app/query/create/page.tsx. This enhancement involves adding hidden input fields for stall_detection, multi_threading, and disable_metrics, which are dynamically set based on the state of specific switches. These hidden fields ensure that the respective configuration values are always included in the form data.

Changes

Files Change Summary
server/app/query/create/page.tsx Added hidden input fields (stall_detection, multi_threading, disable_metrics) in IPAForm function.

Poem

In the code where queries spin,
Hidden fields now tucked within,
Stall detection, threads that run,
Metrics off, the work is done.
Form enhanced with stealthy grace,
Query magic finds its place.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

Outside diff range and nitpick comments (2)
server/app/query/create/page.tsx (2)

Line range hint 217-222: Add keyboard event handlers for accessibility.

The onClick events should be paired with keyboard event handlers (onKeyUp, onKeyDown, or onKeyPress) to ensure accessibility for users who rely on keyboard navigation.

+ onKeyUp={handleKeyUp}
+ onKeyDown={handleKeyDown}
+ onKeyPress={handleKeyPress}

Please add these handlers to the elements at lines 217-222 and 242-250.

Also applies to: 242-250


Line range hint 232-238: Specify button type to prevent unintended form submissions.

The button inside the form does not have an explicit type defined, which can lead to unintended form submissions. Specify the type as 'button' if it is not meant to submit the form.

- <button
+ <button type="button"
Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 031145d and 4ce79da.

Files selected for processing (1)
  • server/app/query/create/page.tsx (6 hunks)
Additional context used
Biome
server/app/query/create/page.tsx

[error] 217-222: Enforce to have the onClick mouse event with the onKeyUp, the onKeyDown, or the onKeyPress keyboard event. (lint/a11y/useKeyWithClickEvents)

Actions triggered using mouse events should have corresponding keyboard events to account for keyboard-only navigation.


[error] 242-250: Enforce to have the onClick mouse event with the onKeyUp, the onKeyDown, or the onKeyPress keyboard event. (lint/a11y/useKeyWithClickEvents)

Actions triggered using mouse events should have corresponding keyboard events to account for keyboard-only navigation.


[error] 232-238: Provide an explicit type prop for the button element. (lint/a11y/useButtonType)

The default type of a button is submit, which causes the submission of a form when placed inside a form element. This is likely not the behaviour that you want inside a React application.
Allowed button types are: submit, button or reset

Additional comments not posted (2)
server/app/query/create/page.tsx (2)

362-367: Ensure consistent form data submission with hidden inputs.

The addition of hidden inputs for stall_detection, multi_threading, and disable_metrics ensures that these values are always included in the form data, aligning with the API's expectations for boolean values. This is a robust solution for the issue described in the PR.

Also applies to: 389-393, 415-419


Line range hint 1-419: Overall structure and logic are well-implemented.

The file is well-organized with clear separation of concerns among components. The logic for handling form submissions and state management is effectively implemented, ensuring a smooth user experience.

Copy link
Collaborator

@akoshelev akoshelev left a comment

Choose a reason for hiding this comment

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

Lets ship it to unblock the service, but maybe UI is not the right place to do it. If it is possible to do server-side translation and set flags to false, if the element is missing, then we can support more cases like this

@eriktaubeneck
Copy link
Member Author

A few thoughts on doing it server side:

  1. It seems that the default in browsers is to not include unchecked checkboxes at all (and the Switch is acting like a checkbox), but that link suggests this approach as an alternative if you'd like to include it.
  2. It seems cleaner to capture the full state of the form (e.g. include disable_metric: false, multithreading: true, ... instead of just multithreading: on. This allows us to capture it, store it, display it, etc without assumptions about the state of the form in the past.
  3. We could also add defaults on the server, however at this point I'm assuming tight coupling between the client (frontend) and server (sidecar/controller). Maintaining backwards compatibility is simply out of scope at this point, as the whole thing is not at all mature enough.
  4. This flow will soon change, as the queries will be started from a queue, and not directly from a form. There is an opportunity to change this (e.g., we read the params from the DB, populate defaults, submit to controllers), if we have a strong opinion.

@eriktaubeneck eriktaubeneck merged commit 1ec016b into main Jun 10, 2024
3 checks passed
@eriktaubeneck eriktaubeneck deleted the form-bugfix branch June 10, 2024 22:15
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.

2 participants