Remove full reload of preview

[mlqn]

Description

The current preview fully reloads when we update something in a layout.

An easy solution to fix it could be to invalidate React queries in the preview to force it to retrieve the new layout.

Before

previewIframeRef.current?.contentWindow?.location.reload();

before.mov

After

await previewIframeRef.current?.contentWindow?.queryClient.invalidateQueries({queryKey:['formLayouts']});

after.mov

[framitdavid]

I believe that @olemartinorg from Team Apps had some thoughts on how we, together with them, could solve this issue. In any case, it's wise to coordinate how we can address this together with Team Apps to make it as seamless as possible. 🙌

[olemartinorg]

Yup, our issue on this is here:

• Adapt app-frontend-react to accept reload commands from Studio app-frontend-react#1088

[nkylstad]

@olemartinorg Any idea on the timeline on adapting app-frontend for Studio?

If we are talking weeks or months then we might as well implement the suggestion in this issue in the meantime - it looks and behaves a lot smoother than what we have today and looks like a relatively small fix for a big impact 😊 What do you thinkg @framitdavid?

[olemartinorg]

We haven't prioritized it in team apps yet, AFAIK. I've been thinking we should simply add some convenience functions for you to use so we have 'official' support for stuff like this. The implementation would go something like you've suggested here in this issue anyway, so this more direct approach may work just as well.

We do something similar in our Cypress tests to quickly change the layout while running an app: https://github.com/Altinn/app-frontend-react/blob/b4e3f6e17d89a68e859c0c96bdebe4de9f21bd5b/test/e2e/support/custom.ts#L455C23-L478

Beware that we actually also put the layoutSetId in the cache key. I'm not sure if invalidating queries directly also invalidates queries with more specific keys, so that's why we made this a bit more complex in the cypress code linked above.

[framitdavid]

@olemartinorg Any idea on the timeline on adapting app-frontend for Studio?

If we are talking weeks or months then we might as well implement the suggestion in this issue in the meantime - it looks and behaves a lot smoother than what we have today and looks like a relatively small fix for a big impact 😊 What do you thinkg @framitdavid?

@nkylstad I agree that we could adapt the suggestion in the issue description as the first version, but we need to verify that it works as expected due to layoutSetId @olemartinorg mentioned. Their Cypress implementation could be used as inspiration to solve the potential layoutSetId cache key issue. 🤔

[framitdavid]

@mlqn just saying, it is quite smart to use the query client on the Window object! 👏 I have never thought that was possible.

[mlqn]

I used formLayouts as the cache key in my tests, so I can confirm that it also work with queries that use a layoutSetId. I also checked the documentation just to be sure, and it says:

// Invalidate every query with a key that starts with todos
queryClient.invalidateQueries({ queryKey: ['todos'] })

https://tanstack.com/query/v4/docs/framework/react/guides/query-invalidation

But I used formLayouts just for simplicity. It would be better to include the layoutSetId to invalidate only the current layout and not all layouts.

[olemartinorg]

Sounds like we can simplify our cypress code as well, then.. 😉

just saying, it is quite smart to use the query client on the Window object!

Ditto! Although we primarily exposed if for Cypress testing purposes, and we didn't anticipate anyone using it for something else.. 🤔 I'll add a comment in our code to make sure we don't just remove it some day when rewriting something, as it will now be referenced outside our project.

[mlqn]

@framitdavid Thanks 🙌 I didn't think it was possible either lol. I just thought it would be cool if it were possible, and then I found a post where the object was available in the window object! 🤯

[mlqn]

@olemartinorg Oh I see, the object wasn't available by default, you added it in the window 🤔 So maybe it's not an ideal solution after all 🤔

[olemartinorg]

No, go ahead! I support this effort 100% - I'll just add a notice about that in our code. Not having to maintain functions that wrap this makes it a bit easier on our part. I trust you to figure out tanstack query.

[lassopicasso]

Tested in dev - OK :)