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

Update React examples to not recreate renderers on each render cycle #294

Open
sissbruecker opened this issue Jan 16, 2025 · 0 comments
Open
Labels
documentation Improvements or additions to documentation

Comments

@sissbruecker
Copy link
Contributor

As identified in #283, Vaadin React components currently treat renderers as components. As such, creating a renderer function on each render cycle is equivalent to creating a new type of component for each render. That in turn causes React to fully replace the DOM, which results in issues such as losing DOM state (focus, input text) as well as decreased performance.

Until #283 is fixed, we should update our component documentation to demonstrate how to use renderers to safely avoid these issues. That means that any renderer should either be:

  • extracted from the main example component function into a separate component function
  • or memoized in the main example component function using useMemo or useCallback

Example - Before:

<Grid items={items.value}>
  <GridColumn header="Employee">
    {({ item }) => <span class="foo">{item.fullName}</span>}
  </GridColumn>

  ...
</Grid>

Example - After:

const employeeRenderer = useCallback(
  ({ item }) => <span class="foo">{item.fullName}</span>,
  []
);
    
<Grid items={items.value}>
  <GridColumn header="Employee">
    {employeeRenderer}
  </GridColumn>

  ...
</Grid>

Note that the dependency array for useMemo / useCallback must be empty, otherwise the renderer would be recreated again when a dependency changes, leading back to the original issue. If the renderer depends on state of the outer component, then signals should be used to access that state from the renderer (should already be the case in our docs).

@sissbruecker sissbruecker added the documentation Improvements or additions to documentation label Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant