removes FooterProvider in favor of just useQuery

[cammiida]

Description

Since footerLayout is server data, it can just be kept in Tanstack 👌 I might be very wrong with regards to the stale time, tho, so happy to receive any feedback 😄

Related Issue(s)

• closes #{issue number}

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

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[adamhaeger]

Really like this approach! Nice simplifaction and I think this approach might help with performance as well as context is known to rerender a lot of its children. The only thing that might be a problem is data fetching between route transitions, is this a problem @olemartinorg or @bjosttveit ?

[olemartinorg]

Nice simplifaction and I think this approach might help with performance as well as context is known to rerender a lot of its children.

That only happens when the data in the context changes, which for the footer, never does.

The only thing that might be a problem is data fetching between route transitions.

I believe the footer is static across all app tasks (or at least the footer layout is statically defined across them all), so no, I don't think that's a problem.

We (@cammiida, @bjosttveit and me) talked a bit about this on Slack last week, and while this looks good in principle the only drawback I can see with this is that it introduces a slightly different way of doing things than the providers we're currently using for pretty much everything else.

[adamhaeger]

Nice simplifaction and I think this approach might help with performance as well as context is known to rerender a lot of its children.

That only happens when the data in the context changes, which for the footer, never does.

The only thing that might be a problem is data fetching between route transitions.

I believe the footer is static across all app tasks (or at least the footer layout is statically defined across them all), so no, I don't think that's a problem.

We (@cammiida, @bjosttveit and me) talked a bit about this on Slack last week, and while this looks good in principle the only drawback I can see with this is that it introduces a slightly different way of doing things than the providers we're currently using for pretty much everything else.

So my performance comment was not aimed at this implementation, but the pattern in general. I think it might be a good direction to go in, and away from the provider pattern. But that probably warrants a longer discussion in the team :)

[adamhaeger]

@cammiida @olemartinorg so what do we want to do with this one and #2124 ?

[olemartinorg]

I think this one is fine - as mentioned before, FooterProvider is probably one of the few that didn't have to be blocking. If we go ahead doing this with the other simpler query providers, we'd have to make adjustments to ReadyForPrint as well (or do something more fundamental with the PDF generator first, as discussed in Altinn/app-template-dotnet#214 and here on Slack).

As for #2124, that's riskier, and would need some additional work for me to be comfortable merging it, at least. After a cursory look, it was clear that PDF generation could run without that query being loaded, and error handling was missing a few places - and when errors were handled, they were handled incorrectly and would lead to rendering the <DisplayError> component instead of the organization logo, which would look pretty bad.

[bjosttveit]

🙌

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud