this is easy to see when there are a lot of objects on the screen. happens when the easy way to repro is when the ValueRenderer renders a deeply nested JSON response, everything slows down to a crawl.
talked with yew developers, and we should try the following steps to improve things:
- finish converting all UiToolkit
draw_* functions to build components instead of rendering HTML directly. yew is faster at comparing components which know if they need to rerender, rather than diffing their generated HTML.
- probably as follow-up, the callback->mutation structure may need to be revisited. Components will contain callbacks that "do the action", like for example a Button component would contain what to do when the button is clicked. there's no good way of comparing these callbacks.
options:
- Do we refactor the application to make these not be callbacks? (rather declarative data-packages containing request information about the mutation that needs to be done)
- or does that not end up mattering really? maybe we just treat all callbacks as "equal" (i.e., don't compare them when comparing the component)
this is easy to see when there are a lot of objects on the screen. happens when the easy way to repro is when the ValueRenderer renders a deeply nested JSON response, everything slows down to a crawl.
talked with yew developers, and we should try the following steps to improve things:
draw_*functions to build components instead of rendering HTML directly. yew is faster at comparing components which know if they need to rerender, rather than diffing their generated HTML.options: