Improve performance of context components re-rendering #3066

T4rk1n · 2024-11-07T20:48:08Z

Fix #3057

Refactor setProps reducer to partially updates the layout instead of returning a new layout object.
New rendering component, DashWrapper replace TreeContainer.
Remove DashContext, the state is now handled in react-redux selectors.

Gif showing only the clicked button is re-rendered:

T4rk1n · 2024-11-07T22:07:59Z

The test_redraw shows failure with 5 redraw instead of 2.

There is two cases of additional redraw that need to be fixed in this pr:

the loading_state selector get triggered. Adding +2 redraw.
While the props is the same when returning, the equality check fails for props since it's a new object. Adding +1 redraw.
- Checking all the props all the time is too expensive.
- Shallow check will fail for objects that might be simple or complex.

gvwilson · 2024-11-11T14:56:15Z

dash/dash-renderer/src/APIController.react.js

                {Array.isArray(layout) ? (
                    layout.map((c, i) =>
                        isSimpleComponent(c) ? (
                            c
                        ) : (
-                            <TreeContainer
+                            <DashWrapper


OK, new component - is this going to break any legacy code?

No, it shouldn't as this is an internal component.

gvwilson · 2024-11-11T14:57:10Z

dash/dash-renderer/src/config.ts

@@ -1,4 +1,4 @@
-type Config = {
+export type DashConfig = {


👍 for the name change - why does it have to be exported?

It is used in the new DashWrapper.tsx.

gvwilson · 2024-11-11T14:58:37Z

dash/dash-renderer/src/reducers/reducer.js

@@ -26,6 +26,18 @@ export const apiRequests = [
    'loginRequest'
 ];

+function callbackNum(state = 0, action) {
+    // With the refactor of TreeContainer to DashWrapper


thank you for the explanation

gvwilson · 2024-11-11T14:59:37Z

dash/dash-renderer/src/wrapper/DashWrapper.tsx

@@ -0,0 +1,425 @@
+import React, {useMemo, useCallback} from 'react';


OK, I'm going to trust you on this - I don't know enough of Dash and TypeScript to review something this large. @emilykl can you please have a look? (who else might be a good reviewer?)

T4rk1n · 2024-11-11T15:29:56Z

I think for the additional redraw might be coming from the new path, before it was JSON.stringify(path) and had a memo on that. Think it might need to be back like that or with an additional equalityFn on the memo for the path where it does JSON.stringify to compare the paths.

NOTMEE12 · 2024-11-28T17:56:09Z

Hi. Are there any updates on this?

AnnMarieW · 2024-12-09T17:33:58Z

@T4rk1n

I ran the dmc-docs using this branch, and it's much faster! Thanks so much for doing this PR. This will make large apps using DMC perform much better.

On the dev branch this app works fine, but on this branch, a component sent to the icon prop throws errors.

import dash_mantine_components as dmc
from dash import Dash, _dash_renderer
_dash_renderer._set_react_version("18.2.0")
from dash_iconify import DashIconify
app = Dash(external_stylesheets=dmc.styles.ALL)



app.layout = dmc.MantineProvider(
    dmc.Checkbox(
            label="Custom checked icon",
            checked=True,
            icon=DashIconify(icon="ion:bag-check-sharp"),
            size="lg",
        )
)

if __name__ == "__main__":
    app.run(debug=True)

Here's one of the error messages (There are a few more as well)

Uncaught TypeError: Cannot read properties of undefined (reading 'props')
    at n.47474.s.default.createElement.r.icon (dash_mantine_components.v0_15_1m1733503561.js:2:1076461)
    at renderWithHooks ([email protected]_18_2m1733760928.2.0.js:16315:20)
    at mountIndeterminateComponent ([email protected]_18_2m1733760928.2.0.js:20084:15)
    at beginWork ([email protected]_18_2m1733760928.2.0.js:21597:18)
    at HTMLUnknownElement.callCallback ([email protected]_18_2m1733760928.2.0.js:4151:16)
    at Object.invokeGuardedCallbackDev ([email protected]_18_2m1733760928.2.0.js:4200:18)
    at invokeGuardedCallback ([email protected]_18_2m1733760928.2.0.js:4264:33)
    at beginWork$1 ([email protected]_18_2m1733760928.2.0.js:27461:9)
    at performUnitOfWork ([email protected]_18_2m1733760928.2.0.js:26567:14)
    at workLoopSync ([email protected]_18_2m1733760928.2.0.js:26476:7)

Update

It's not just the DashIconify library. It's not possible to pass any components to the icon prop:

import dash_mantine_components as dmc
from dash import Dash, _dash_renderer, html
_dash_renderer._set_react_version("18.2.0")

FONT_AWESOME = "https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/css/all.min.css"

app = Dash(external_stylesheets=[FONT_AWESOME])

app.layout = dmc.MantineProvider([
    html.I(className="fa-solid fa-bag-shopping fa-3x"),
    dmc.Checkbox(
            label="Custom checked icon",
            checked=True,
            icon=html.I(className="fa-solid fa-bag-shopping fa-3x"),
            size="lg",
        )
])


if __name__ == "__main__":
    app.run(debug=True)

T4rk1n · 2024-12-09T18:54:28Z

@AnnMarieW I removed the _dashprivate_layout from the given props, it's a "private" props and shouldn't have been used outside of the renderer.

https://github.com/snehilvj/dash-mantine-components/blob/529231820bc2ca25db396cb35d637618b6df62cc/src/ts/components/core/checkbox/Checkbox.tsx#L66

AnnMarieW · 2024-12-09T19:13:10Z

@T4rk1n Thanks for your speedy response. I updated to use React.cloneElement instead and it works fine 🎉

Update: Actually it doesn't work 😢 It doesn't throw errors, but it doesn't render correctly 🤔

alexcjohnson · 2024-12-10T06:26:08Z

There's one other user of _dashprivate_layout in this repo (dcc.ConfirmDialogProvider), and it's also used by both DDK and DBE https://github.com/search?q=org%3Aplotly+_dashprivate_layout&type=code, in addition to DBC and as @AnnMarieW points out DMC. @T4rk1n is removing this necessary to the performance improvements? If not, it seems like we really shouldn't tamper with it. But if it is necessary, we'll need to come up with an alternate pattern that will work for our own uses of it, and then give these other libraries time and assistance to adopt the pattern as well.

T4rk1n · 2024-12-10T14:01:23Z

I removed the _dashprivate props because it was not necessary anymore in the wrapper props, still think it was a mistake to include them in given props with a name like that when it should be part of the API. While the performance impact isn't that much to add it back, it does contains the whole layout starting from the component, duplicated for each components the memory footprint is non-negligible for just a few usecases.

The proper way to handle this kind of pattern (send data up/down stream the component tree) in react is with context components, which this PR fixes their performance.

AnnMarieW · 2024-12-10T16:10:25Z

@T4rk1n

Thanks for the suggestion of using context instead. We are using the dashprivate props in multiple components in DMC, so this will take a while to update.

You make a good point here:

contains the whole layout starting from the component, duplicated for each components the memory footprint is non-negligible for just a few usecases.

Given that this PR substantially increases performance, would you consider keeping the dashprivate props for now, and removing in a future update?

T4rk1n · 2024-12-10T17:39:31Z

Given that this PR substantially increases performance, would you consider keeping the dashprivate props for now, and removing in a future update?

Yes, I'll put it back since it's used everywhere. There could be an alternative get_props on the clientside that would return the raw props in a future update before deprecating and removing this dashprivate api.

AnnMarieW · 2024-12-10T18:34:24Z

This would be awesome:

There could be an alternative get_props on the clientside that would return the raw props in a future update before deprecating and removing this dashprivate api.

❤️ ❤️

T4rk1n · 2024-12-11T16:25:29Z

Not sure I can add back those props in the way it was, there was another component in between the TreeContainer and the library component that is not longer the case. Might need to refactor the new Wrapper to have a middle component but that changes the order of renders and is not as optimal as a single component since it add overhead.

T4rk1n · 2024-12-11T16:37:20Z

And I think now with this to access the child props the new path would be just without a level and the _dashprivate_layout.props.
So instead of child.props._dashprivate_layout.props you would use child.props directly.

T4rk1n · 2024-12-11T17:08:40Z

And I think now with this to access the child props the new path would be just without a level and the _dashprivate_layout.props. So instead of child.props._dashprivate_layout.props you would use child.props directly.

Actually, the props are not there anymore in the wrapper, they are now gotten from the selector, so the old hack cannot work anymore with this solution.

AnnMarieW · 2024-12-11T17:19:44Z

so the old hack cannot work anymore with this solution.

Is there a "new hack" that might be easier than using context?

T4rk1n · 2024-12-11T18:24:56Z

so the old hack cannot work anymore with this solution.

Is there a "new hack" that might be easier than using context?

A Context solution might only be valid in some cases, for the mantine checkbox case, it want to add extra props to the component.

I see a couple solution for those cases:

Could add extraProps to DashWrapper props that would be merged with the component props from the store, this would make React.cloneElement(child, {extraProps: {selected: true}}) to work.
change the clientside set_props to accept a path instead of an id. Then you can use children[0]._dashprivate_path to add new props to the components.

For accessing the props (dcc.Tabs cases), a new get_props(path) could be added or refactor the components to use a context.

insistence · 2025-01-10T00:53:01Z

@AnnMarieW I added all three solutions from the last post.

Added extras prop to DashWrapper component, think this one could replace dmc checkbox:
const iconFunc = ({ indeterminate, ...others }) => {
    const selected: any = indeterminate ? indeterminateIcon : icon;
    return React.cloneElement(selected, {extras: others});
};
set_props can take a dash path instead of id.

Added get_props(pathOrId), to get the props of a component. The path is available in children[0].props.componentPath.

Let me know if that work.

I have a question about the Added extras prop to DashWrapper component. If the third-party React component itself uses React.cloneElement but does not pass the extras property, will the current change not be able to pass additional parameters to child components? Previous related PR #2819 #2831 .

T4rk1n · 2025-01-10T14:40:37Z

@insistence

I have a question about the Added extras prop to DashWrapper component.

I added the extras as an alternative to dashprivate api's, I refactored the test you added a couple months ago yesterday to use the new extras instead and it felt kinda wrong. I think I can do ...restProps instead of the extras prop that would be better so I'll change that.

T4rk1n · 2025-01-24T15:50:36Z

@AnnMarieW This will be ready for merge, I'd like to get the api right before and I am thinking of one last minute change. Putting window.dash_clientside.get_layout(path) on window.dash_component_api.get_layout() instead. This way would be more separated between what should be used in clientside callbacks and inside dash components. What do you think?

AnnMarieW · 2025-01-24T16:07:40Z

Putting window.dash_clientside.get_layout(path) on window.dash_component_api.get_layout() instead. This way would be more separated between what should be used in clientside callbacks and inside dash components.

I agree - it would be more consistent. Is there any use-case for the get_layout being included in dash_clientside ? Would people use it in clientside callbacks?

AnnMarieW · 2025-01-24T16:10:29Z

components/dash-core-components/src/components/Textarea.react.js

@@ -73,6 +73,11 @@ const Textarea = ({
    );
 };

+Textarea.dashPersistence = {


Is this the recommended way of setting default for persistence?
It will only work in Dash >=3 ?

Yes, only for dash>=3 for support of the persistence props that was previously in defaultProps in functional components and react 18.

Does it work in dash< 3 to have the default for persistence set in the function signature? If not, we should check if Dash 3.0 is being use and if not use defaultProps? Is the best way to check for Dash 3.0 by seeing if window.dash_component_api exists?

I also I get an error when trying to set default props in the function signature when the prop is a required prop by Mantine. This might be a separate issue, but do you know how to handle that case?
This is the error, it's like the prop is not getting passed to Mantine, even though it's defined with a default in the function:

"TypeError: Required argument opened was not specified."

Does it work in dash< 3 to have the default for persistence set in the function signature?

No it doesn't work since the check is explicit on the defaultProps.

Is the best way to check for Dash 3.0 by seeing if window.dash_component_api exists?

Yes that is the quickest check.

"TypeError: Required argument opened was not specified."

This an error on the Python side of the component, it should have a check if a required prop has a default in the metadata. If you built the components on this branch before I merged 3.0 yesterday might just need to rebuild with the latest changes.

T4rk1n · 2025-01-24T16:39:55Z

Would people use it in clientside callbacks?

I don't think so, it requires the componentPath which is not something the clientside callbacks would really know about.

Improve performance of context components re-rendering

8a5ab9a

T4rk1n requested review from alexcjohnson, ndrezn, gvwilson and emilykl as code owners November 7, 2024 20:48

Fix list as layout

378fec3

AnnMarieW mentioned this pull request Nov 8, 2024

Performance issues snehilvj/dash-mantine-components#390

Open

gvwilson added performance something is slow feature something new labels Nov 11, 2024

gvwilson assigned T4rk1n Nov 11, 2024

gvwilson approved these changes Nov 11, 2024

View reviewed changes

AnnMarieW mentioned this pull request Dec 10, 2024

Stop using dashprivate props which will be removed in Dash 3.0 snehilvj/dash-mantine-components#453

Open

memo wrapper, merge loading state selector, add back _dashprivate_layout

65ffabd

Add get_props, extras to wrapper, set_props takes path

011ded9

T4rk1n added 5 commits January 8, 2025 10:07

Fix multioutput loading

9cc9627

fix rdarp001

d5dddff

Fix clipboard context

61b8ea6

Fix confirm dialog provider

e616001

Fix loading target selector

9954a2a

T4rk1n added 10 commits January 10, 2025 10:21

Takes extras props directly from DashWrapper rest props

e023e4f

Refactor wrapper selectors to use path sums as equality comparator

232c3c0

fix cbmo002

5a68ecd

Refactor TextArea to functional + new loading

2bcb14d

Refactor upload to LoadingElement

f0b4908

Remove leftover loading_state from graph.

fbdd794

Fix table loading.

c520a82

Fix missing export for Textarea.

5dce073

Fix table.

71e70c3

Merge branch 'dev' into fix/wrapper

b00668e

T4rk1n changed the base branch from dev to dash-3.0 January 22, 2025 14:55

T4rk1n added 7 commits January 22, 2025 09:56

Merge branch 'dash-3.0' into fix/wrapper

a1f6b5e

Take persistence from dashPersistence on element

6af9973

Remove defaultProps from internal DataTable.

8b3c153

Mock dash_component_api in table tests.

9874f8a

build

51dfddf

Merge branch 'dash-3.0' into fix/wrapper

eb65854

Fix tab new loading

664e6dd

AnnMarieW reviewed Jan 24, 2025

View reviewed changes

Move getLayout to dash_component_api

5194e18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve performance of context components re-rendering #3066

Improve performance of context components re-rendering #3066

T4rk1n commented Nov 7, 2024

T4rk1n commented Nov 7, 2024

gvwilson Nov 11, 2024

T4rk1n Nov 11, 2024

gvwilson Nov 11, 2024

T4rk1n Nov 11, 2024

gvwilson Nov 11, 2024

gvwilson Nov 11, 2024

T4rk1n commented Nov 11, 2024

NOTMEE12 commented Nov 28, 2024

AnnMarieW commented Dec 9, 2024 •

edited

Loading

T4rk1n commented Dec 9, 2024

AnnMarieW commented Dec 9, 2024 •

edited

Loading

alexcjohnson commented Dec 10, 2024

T4rk1n commented Dec 10, 2024

AnnMarieW commented Dec 10, 2024

T4rk1n commented Dec 10, 2024

AnnMarieW commented Dec 10, 2024

T4rk1n commented Dec 11, 2024 •

edited

Loading

T4rk1n commented Dec 11, 2024 •

edited

Loading

T4rk1n commented Dec 11, 2024

AnnMarieW commented Dec 11, 2024

T4rk1n commented Dec 11, 2024 •

edited

Loading

insistence commented Jan 10, 2025

T4rk1n commented Jan 10, 2025

T4rk1n commented Jan 24, 2025

AnnMarieW commented Jan 24, 2025 •

edited

Loading

AnnMarieW Jan 24, 2025

T4rk1n Jan 24, 2025

AnnMarieW Jan 24, 2025 •

edited

Loading

T4rk1n Jan 24, 2025

T4rk1n commented Jan 24, 2025

		@@ -0,0 +1,425 @@
		import React, {useMemo, useCallback} from 'react';

Improve performance of context components re-rendering #3066

Are you sure you want to change the base?

Improve performance of context components re-rendering #3066

Conversation

T4rk1n commented Nov 7, 2024

T4rk1n commented Nov 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

T4rk1n commented Nov 11, 2024

NOTMEE12 commented Nov 28, 2024

AnnMarieW commented Dec 9, 2024 • edited Loading

Update

T4rk1n commented Dec 9, 2024

AnnMarieW commented Dec 9, 2024 • edited Loading

alexcjohnson commented Dec 10, 2024

T4rk1n commented Dec 10, 2024

AnnMarieW commented Dec 10, 2024

T4rk1n commented Dec 10, 2024

AnnMarieW commented Dec 10, 2024

T4rk1n commented Dec 11, 2024 • edited Loading

T4rk1n commented Dec 11, 2024 • edited Loading

T4rk1n commented Dec 11, 2024

AnnMarieW commented Dec 11, 2024

T4rk1n commented Dec 11, 2024 • edited Loading

insistence commented Jan 10, 2025

T4rk1n commented Jan 10, 2025

T4rk1n commented Jan 24, 2025

AnnMarieW commented Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnnMarieW Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

T4rk1n commented Jan 24, 2025

AnnMarieW commented Dec 9, 2024 •

edited

Loading

AnnMarieW commented Dec 9, 2024 •

edited

Loading

T4rk1n commented Dec 11, 2024 •

edited

Loading

T4rk1n commented Dec 11, 2024 •

edited

Loading

T4rk1n commented Dec 11, 2024 •

edited

Loading

AnnMarieW commented Jan 24, 2025 •

edited

Loading

AnnMarieW Jan 24, 2025 •

edited

Loading