Skip to content

Force layout load invalidation server-side #7403

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

Closed
theetrain opened this issue Oct 26, 2022 · 3 comments
Closed

Force layout load invalidation server-side #7403

theetrain opened this issue Oct 26, 2022 · 3 comments

Comments

@theetrain
Copy link
Contributor

theetrain commented Oct 26, 2022

Describe the problem

In cases where a layout's load method is returning sensitive data such as a user's profile, it would be great to have a serverside means of invalidating the parent layout from within a page's load. That way we don't have to rely on client-side invalidateAll() if for whatever reason JS isn't working.

Sample layout load:

export const load: LayoutServerLoad = async ({ locals }) => {
    return {
        profile: locals.profile
    };
};

Describe the proposed solution

I noticed a few ideas floating around here:

  1. Proposal: Add Layout Guards #6912 (comment)
    Supply an ignore module to allow a load function to decide when to not re-run based on specific criteria.
  2. Extend the parent() function to force parent layout's to call their load method. It could be await parent({ force: true })
  3. Add a means for cookies or locals to act as a dependency so that if they change from within handle or a page down the load chain, it will invoke load for a parent layout

Alternatives considered

  1. Always call a parent load by making use of url.pathname
if (url.pathname === 'log-out')
  return { profile: '' }
}
  1. Redirect the user after a "log out" side effect so that locals can be re-populated:
import { redirect } from '@sveltejs/kit';
import type { PageServerLoad } from './$types';

export const load: PageServerLoad = ({ locals }) => {
 if (!locals.user) {
   throw redirect(307, '/login');
 }
}

Though I'm unsure if the layout's load will get called again after a redirect.

Importance

would make my life easier

Additional Information

Related discussions:

@theetrain theetrain changed the title Force layout load invalidation server-side Force layout load invalidation server-side Oct 26, 2022
@CanRau
Copy link

CanRau commented Nov 17, 2022

Not sure how relevant this is but I can't get a throw redirect working to reload everything.
It seems to just pushState updating the URL instead of doing an actual redirect/reload.
I mean in my case I'm trying to reload the current page after a form submission to refresh all data

@eltigerchino
Copy link
Member

eltigerchino commented Nov 17, 2022

Not sure how relevant this is but I can't get a throw redirect working to reload everything. It seems to just pushState updating the URL instead of doing an actual redirect/reload. I mean in my case I'm trying to reload the current page after a form submission to refresh all data

If you are using the form enhance action, you'll have to implement a custom callback that calls invalidateAll() after a redirect result. e.g.,

<form use:enhance={() => {
  return async ({result}) => {
    if (result.type === 'success' || result.type === 'redirect') {
      await invalidateAll();
    }
    // ... your applyAction(result) logic, etc.
  }
}}>

Currently, it will only invalidate for success responses (anything that doesn't throw error, invalid, or redirect). This isn't a problem if you aren't using the enhance action as the page will always reload.

Personally, I have struggled quite a bit with properly understanding the behaviour of update and applyCallback, but that might just be due to my slowness. My solution has been to repeatedly open up the kit/forms.js file whenever I'm dealing with forms, and read through the code for the fallback_callback function.

@dummdidumm
Copy link
Member

I'm not sure I understand the preamble of the issue. In case JavaScript is not available, the next request goes back to the server. The server is stateless, so all load functions are rerun. I'm therefore closing this as a duplicate of the linked issues/discussions.

@dummdidumm dummdidumm closed this as not planned Won't fix, can't repro, duplicate, stale Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants