Fetch user before pass it to the restricted function

[wesleybl]

It may not be in the Redux store yet when we try to pass it in. So we dispatch if it's not in the store.

[netlify]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	bd5c4cc
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/66f459dc81d2b60008afd328

[davisagli]

Thanks!

[pnicolli]

I am not sure I understand what problem we are trying to solve here. Aren't the components getting an update (rerender triggered by useSelector) when the user is finally fetched, even if it's not there when these components are first rendered? In other words, does it break somehow, or what is the issue here?
I'm trying to understand if we are firing an extra query to the backend that is worth firing or if it can be avoided. Moreover, would it be possible, if we have a use case for fetching user data here, to just do it during SSR instead? This way we could potentially avoid any issue from the beginning.

[davisagli]

@pnicolli Consider the case where the user is logged out, then they log in and edit the page. Then we have to dispatch getUser, because the user isn't in the store yet. In this scenario there is no SSR request at a point in time when the user is logged in.

[sneridagh]

@pnicolli this is related to #6271, as a continuation, if the user info is not in the store, this PR makes sure it's in there, so we can use it in a restrict key in the block config.

It LGTM.

[pnicolli]

@pnicolli Consider the case where the user is logged out, then they log in and edit the page. Then we have to dispatch getUser, because the user isn't in the store yet. In this scenario there is no SSR request at a point in time when the user is logged in.

I thought the user should get into the store eventually when the user logs into the portal, but I trust you to have done more research than I did on the subject 😁 👍

[sneridagh]

@pnicolli not the case, but it's a good point. @davisagli thoughts?

[pnicolli]

Well I was thinking... maybe we should consider for Volto 19 to move the user info to an expander we get with the content? Would it be worth it? I don't want to clutter anybody's notifications though, so maybe I could give this a little more thought and discuss it at a Volto Team meeting

[davisagli]

I also had the idea of fetching the user info when the user logs in, but it doesn't avoid the need for what we have in this PR, because sometimes the user loads the page from the server while already logged in.

I don't think user info belongs in an expander because it's information that does not depend on which content item is being fetched. It would also make it hard to cache content responses in a way that is shared between multiple users with the same roles.