Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Custom Value Editor Re-renders Entirely on Dropdown Option Change #889

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.

Sign up for GitHub

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

Jump to bottom
Open
krnithishkumar opened this issue May 2, 2025 · 3 comments
Open

Custom Value Editor Re-renders Entirely on Dropdown Option Change #889

krnithishkumar opened this issue May 2, 2025 · 3 comments
Labels
awaiting response

Comments

@krnithishkumar
Copy link

React Query Builder version

6.5.5

Platform

Chrome on macOS 15.4.1

Description

Hi,

When using a custom value editor with a select dropdown in the React Query Builder, the entire custom value editor re-renders whenever the props.handleOnChange function is triggered by selecting an option in the dropdown. This behaviour is causing performance issues and unnecessary API calls.

Reproduction

Steps to reproduce:

  1. Implement a custom value editor for the React Query Builder.
  2. Use a select dropdown as part of the custom value editor.
  3. Pass the props.handleOnChange function to the dropdown's onChange handler.
  4. Change the dropdown's selected option.

Expected behavior

The dropdown should update its value without re-rendering the entire custom value editor.
The parent component should not trigger unnecessary API calls or state updates unless the value has genuinely changed.

Additional information

The issue is likely caused by the props.handleOnChange function triggering a state update in the parent component, which propagates back to the custom value editor.
The dropdown options are dynamically generated, and the value is passed as a prop to the dropdown.

Sample code:

import React from 'react';
import { ValueEditorProps } from 'react-querybuilder';

const CustomValueEditor = ({ props }: { props: ValueEditorProps }) => {
  const options = [
    { value: 'option1', label: 'Option 1' },
    { value: 'option2', label: 'Option 2' },
  ];

  return (
    <select
      value={props.value}
      onChange={(e) => props.handleOnChange(e.target.value)}
    >
      {options.map((option) => (
        <option key={option.value} value={option.value}>
          {option.label}
        </option>
      ))}
    </select>
  );
};

export default CustomValueEditor;
@jakeboone02
Copy link
Member

Couple of things here:

For one, version 7 introduced a ton of performance improvements mainly related to memoization, so upgrading to the latest (currently v8.5.0) may resolve any perf issues you're encountering with v6.5.5.

Secondly, you say "The dropdown should update its value without re-rendering the entire custom value editor." I may be wrong, but I'm pretty sure that can only be the case with an uncontrolled component (and maybe not even then, at least it's not guaranteed). All sub-components (custom or not) are controlled components within QueyrBuilder, so a value change will necessarily cause a re-render. With v7/v8, the re-renders are granular to the rule level, but they still happen.

But I'm curious why it matters. Are you seeing issues due to too many re-renders of the value editor specifically? Now that I'm typing this out, I'm getting the feeling you're talking about re-renders of the entire query builder component and not just the value editor. If that's the case, then upgrading to the latest version should resolve the problem.

@krnithishkumar
Copy link
Author

Hi @jakeboone02,
Thanks for your reply.

Re-renders occur in the custom value editor due to API calls with no-cache, explicitly displaying the component in a loading state. To address this, we implemented cache logic to prevent redundant API calls.

I understand that handleOnChange is necessary to update the state of the rules, which triggers re-renders. However, the issue has been resolved through an alternative approach.

Thanks.

@jakeboone02
Copy link
Member

Ok now I'm curious about your actual code and the workaround you implemented. Any chance you could elaborate?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
awaiting response
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jakeboone02 @krnithishkumar