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

Faster save processing, reworking useNodeValidation() #2724

Merged
merged 11 commits into from
Nov 20, 2024

Conversation

olemartinorg
Copy link
Contributor

@olemartinorg olemartinorg commented Nov 19, 2024

Description

When form data is saved, we get new validations from the backend (when the app has implemented backend validation, at least). Previously, we saved the last processed validations pretty much everywhere (luckily only as a reference) so that we could make sure all StoreValidationsInNodeWorker components had done their job and stored new validations if needed. This caused lots of state updates on all nodes for every save operation, and worsened performance.

Now, the useNodeValidation() hook will instead subscribe to the validation store and will only re-run validation when that changes. It will then save which backend validations have been processed into the Registry, so that we can useWaitForNodesToValidate() to wait until they have processed their validations (or, at least, useNodeValidation() has run to completion).

This also means that NodesContext no longer has to store the latest validations, and also means that it can now only be 'ready' or 'not ready' (no longer 'processing the last save'). The node generator will now only become 'not ready' after a save if new components are introduced (typically if a row has been added).

In addition to this, a few minor changes. Either because they were tiny, or stuff I had to do because tests failed:

  • Getting rid of the renderPresentation flag in <Loader />, and figuring out if the Presentation component has rendered via a Context. I've seen glimpses of double-PresentationComponent rendering lately, and this should fix it.
  • Optimizing some routes. There's no need for a different route to <FormFirstPage /> as <Form /> will also detect that case and redirect you to the first page.
  • Fixing the navigate() call in the Subform component that broke on me. It somehow started to remove the main form page from the URL when navigating to a relative path (.../Task_1/mainPage navigating to the relative subFormComponentId/subFormDataElementId turned into .../Task_1/subFormComponentId/subFormDataElementId).

Related Issue(s)

Verification/QA

  • Manual functionality testing
    • I have tested these changes manually
    • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
    • No testing done/necessary
  • Automated tests
    • Unit test(s) have been added/updated
    • Cypress E2E test(s) have been added/updated
    • No automatic tests are needed here (no functional changes/additions)
    • I want someone to help me make some tests
  • UU/WCAG (follow these guidelines until we have our own)
    • I have tested with a screen reader/keyboard navigation/automated wcag validator
    • No testing done/necessary (no DOM/visual changes)
    • I want someone to help me perform accessibility testing
  • User documentation @ altinn-studio-docs
    • Has been added/updated
    • No functionality has been changed/added, so no documentation is needed
    • I will do that later/have created an issue
  • Support in Altinn Studio
    • Issue(s) created for support in Studio
    • This change/feature does not require any changes to Altinn Studio
  • Sprint board
    • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
    • I don't have permissions to do that, please help me out
  • Labels
    • I have added a kind/* label to this PR for proper release notes grouping
    • I don't have permissions to add labels, please help me out

…here. Making sure to not render the presentation stuff inside itself.

Ole Martin Handeland added 6 commits November 19, 2024 09:08
…here. Making sure to not render the presentation stuff inside itself.
…xt for each node. This should make the user experience around saving form data smoother.
…o longer marking state as not ready when processing save results, awaiting individual node validations in a separate function instead (waitForNodesToValidate). I had to make useWaitForState support async to make this work.
@olemartinorg olemartinorg added the kind/other Pull requests containing chores/repo structure/other changes label Nov 19, 2024
Ole Martin Handeland added 5 commits November 19, 2024 14:07
…tect if the Presentation component has rendered above.
…s properly. Somehow the subform component started messing this up by
…uld have known, that client-side validation means that the data model validations will update also when that changes, not only when backend validations change. This makes comparing previous runs to skip selecting data too complex, so it would no longer give performance benefits.
@olemartinorg olemartinorg marked this pull request as ready for review November 19, 2024 15:31
@olemartinorg olemartinorg self-assigned this Nov 19, 2024
Copy link
Member

@bjosttveit bjosttveit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice!

@olemartinorg olemartinorg merged commit c532f7d into main Nov 20, 2024
21 checks passed
@olemartinorg olemartinorg deleted the fix/performance-validation branch November 20, 2024 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/other Pull requests containing chores/repo structure/other changes
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants