-
-
Notifications
You must be signed in to change notification settings - Fork 669
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
Make modals/forms more reactive #5897
Make modals/forms more reactive #5897
Conversation
✅ Deploy Preview for inventree-web-pui-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
# Conflicts: # src/frontend/src/components/forms/ApiForm.tsx # src/frontend/src/pages/Index/Playground.tsx
@SchrodingersGat Please let me know what you think about this implementation, how you feel the performance of the new form on your side compared to latest master. And if we need to improve performance in this PR. In my testing it feels like the latest master has more performance problems than this when running both in dev mode. Trying the production/preview build seems like it is working not really noticeable that there are some lags. |
@wolflu05 nice, I'll check this out next week - I am away for the weekend :) |
@wolflu05 very nice - I like the demo example in the "playground" area :) |
Thank you @SchrodingersGat that you like it. The reactive approach (where the active switch disables the keyword input) with the inline form without a modal can also be used the same way for the modal form with the hook. What do you suggest for going forward with this PR? Do you see some performance issues compared to the old implementation? (Make sure to only compare a dev version with a dev version and a build with a build, they have huge differences in my tests.) |
I did not see any performance issues, I have not profiled each implementation. Do you have a set of features you still want to implement here? |
No, I have nothing else planned for this PR. Was just not sure if there is some more work required regarding performance. But if you say it's fine, then refactoring the field component to not rerender everytime would be another task. What is your plan on using the new hook syntax? Should we refactor and remove the old implementation? Or should we just use the new hook implementation for the new forms, or only the ones require reactivity? |
Would you be willing to take on this one? I think that you have a better idea where to look than I do.
Can you please submit a PR with an example of refactoring one of the existing forms? I would rather do them all "properly" and refactor what we have now, before we build out a lot more forms. If you are happy with this, please mark as ready and I will merge |
I tried to eliminate unnecessary dependencies in my last PR, but it seems like the useForm hook from mantine has some issues, see this discussion. The best way to fix this issue and improve performance would be like they recommend in the discussion to switch to another form state library like
Sure, I can refactor the old forms in a followup PR if you want. |
I now committed a first draft of switching to the react-hook-form lib. In my tests the performance now has drastically improved. I already planned the code so that the integration of the Performance comparisonOldBildschirmaufnahme.2023-11-15.um.21.46.48.movNewBildschirmaufnahme.2023-11-15.um.21.47.28.mov |
@wolflu05 looking very nice :) |
…orm is not 'dirty'
@SchrodingersGat This would be ready for review now. I decided to implement the dependent field not yet, as 1. the diff is already large enough and 2. it would be better to build the print label dialog first. That would be the easiest think to test the dependent field then while implementing it. But that is a too big task for here. I now switched to the already mentioned I also implemented nested object fields now and added the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing work; works very well on my laptop and iPad!
const oldFormSuccess = props.onFormSuccess; | ||
props.onFormSuccess = (data) => { | ||
oldFormSuccess?.(data); | ||
modals.close(modalId); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SchrodingersGat To continue this conversation here. This is just a name, because I need to wrap the onFormSuccess
function so that I can do something else and also call the callback provided in props. If I wouldn't save this in a variable, and just call it from inside, I would have an endless recursion.
This PR aims to make the modals and forms framework more reactive.
This is already working, but it is a bit slow. I think this is caused by multiple reasons. The biggest is, that Form fields get passed every form state as props. That means they rerender on every change. But actually that is not needed. Because e.g. changing the value of a text input should not rerender the part category select input. The part category select input should only rerender if its definition changes. (This can be easily seen by placing
console.log("Rerender", definition.label)
inside of the ApiFormField)EDIT: I now discovered, that the preview production build doesn't has that much of performance issues, and checking out the latest master in development has even more performance problems on my side.
Todo
onValueChange
issuenested object
fieldimplement(Printing dialog needs to be implemented first)dependent field
field