Don't create page endpoints!

.github/workflows/ci.yml

@@ -17,7 +17,7 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v2
         with:
-          node-version: '14'
+          node-version: '16'
       - run: npm install
       - run: npm run check
   Tests:
@@ -26,7 +26,7 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v2
         with:
-          node-version: '14'
+          node-version: '16'
 
       - name: Cache node modules
         id: playwright-cache

documentation/docs/00-introduction.md

@@ -12,7 +12,7 @@ Svemix is a somewhat different framework than you're probably used to. It can be
 
 ### How does it work?
 
-Svemix Vite-Plugin replaces all code inside `<script context="module" ssr>` and generates the corresponding [SvelteKit-Endpoint](https://kit.svelte.dev/docs/routing#endpoints) next to the file for you, this means for `src/routes/todos.svelte` it will generate `src/routes/todos.{js|ts}`. SvelteKit will then make sure to run your loader on the server and for client side navigations it fetches the data required by the page.
+Svemix Vite-Plugin replaces all code inside `<script context="module" ssr>` and simulates the corresponding [SvelteKit-Endpoint](https://kit.svelte.dev/docs/routing#endpoints). SvelteKit will then make sure to run your loader on the server and for client side navigations it fetches the data required by the page.
 - This enables us to import a database or any other stuff that should never reach the client directly inside your Svelte Routes.
 
 ### Getting started
@@ -29,25 +29,18 @@ npm run dev
 
 If you already have an existing SvelteKit project setup, that's fine you can just use `npm install svemix`.
 
-Once you have the required dependency installed, you should add `svemix/plugin` inside your `svelte.config.js` file under `vite.plugins`
+Once you have the required dependency installed, you should add `svemix/plugin` inside your `vite.config.js` file under `plugins`, before `sveltekit`
 
 ```js
 /// file: svelte.config.js
 import svemix from 'svemix/plugin';
+// @errors: 2307
+import { sveltekit } from '@sveltejs/kit/vite';
 
-/** @type {import('svemix').SvemixConfig} */
+/** @type {import('vite').UserConfig} */
 const config = {
-	// ...
-	kit: {
-		// ...
-		vite: {
-			plugins: [svemix()]
-			/// ...
-		}
-	},
-	svemix: {
-		// ...
-	}
+	// @errors: 2307
+	plugins: [svemix(), sveltekit()]
 };
 
 export default config;

documentation/docs/01-loading-data.md

@@ -77,12 +77,11 @@ This can be really useful if you have some kind of nested component wich needs a
 ```svelte
 /// file: src/lib/User.svelte
 <script>
-	import { getLoaderData } from 'svemix';
-	const data = getLoaderData();
+	export let data;
 </script>
 
 <div>
-	<p>Username: {$data?.user.username}</p>
+	<p>Username: {data?.user.username}</p>
 </div>
 ```
 

documentation/docs/04-sessions.md

@@ -29,10 +29,9 @@ export const handle = handleSession(
 		getSession
 	},
 	// Optional own handle function can be passed here
-	function ({ event, resolve }) {
+	async function ({ event, resolve }) {
 		// event.locals is populated with the session `event.locals.session` and `event.locals.cookies`;
-		const response = resolve(event);
-
+		const response = await resolve(event);
 		return response;
 	}
 );
@@ -93,7 +92,7 @@ If you're updating or destroying the session inside one of your `actions`, the `
 
 If the session already exists, the data get's updated but the expiration time stays the same
 
-The only way to set the session is setting the locals.session.data to an object
+There are two ways to update the session via: `session.update` and via `session.set`;
 
 ```svelte
 /// file: src/routes/auth/login.svelte
@@ -108,7 +107,7 @@ The only way to set the session is setting the locals.session.data to an object
 		password?: string;
 	}
 
-	export const action: Action<ActionData> = async function ({ request }) {
+	export const action: Action<ActionData> = async function ({ request, locals }) {
 		// @ts-ignore
 		const body = await request.formData();
 
@@ -128,7 +127,7 @@ The only way to set the session is setting the locals.session.data to an object
 				};
 			}
 
-			locals.session.data = { isLoggedIn: true, user };
+			await locals.session.set({ isLoggedIn: true, user })
 
 			return redirect('/', 302);
 		} catch (error) {
@@ -148,7 +147,7 @@ The only way to set the session is setting the locals.session.data to an object
 ### Accessing The Session
 
 
-After initializing the session, your locals will be filled with a session JS Proxy, this Proxy automatically sets the cookie if you set the locals.session.data to something and receive the current data via locals.session.data only. To see this in action add a console.log(locals.session) it will be empty. Only if you add an console.log(locals.session.data) and access the data it will output the current data. So if you wonder why is my session not filled, this is why.
+After initializing the session, your locals will be filled with a session JS Proxy, this Proxy automatically sets the cookie if you use `locals.session.set` or `locals.session.update` and receive the current data via locals.session.data only.
 
 ```svelte
 /// file: src/routes/auth/login.svelte
@@ -185,7 +184,7 @@ After initializing the session, your locals will be filled with a session JS Pro
 		const _action = body.get('_action');
 
 		if (_action === 'logout') {
-			locals.session.destroy();
+			await locals.session.destroy();
 		}
 
 		return {};

documentation/docs/05-configuration.md

@@ -8,7 +8,6 @@ title: Configuration
 
 ```js
 /// file: svelte.config.js
-import svemix from 'svemix/plugin';
 
 /** @type {import('svemix').SvemixConfig} */
 const config = {

documentation/docs/08-drawbacks.md

@@ -4,11 +4,7 @@ title: Drawbacks
 
 ### Limitations
 
-Svemix has some limitations, the current approach uses a vite plugin which is responsible for generating the corresponding endpoint for you. This files are still public and can be queried by anyone. So you have to make sure to secure your loaders/actions accordingly. For example you should check if the user is logged-in/admin to avoid unwanted people hitting your generated api endpoints.
-
-### Too many files
-
-Since svemix generates endpoints next to your `.svelte` files, this can quickly sum up to a lot of files. There is an open Discussion on the SvelteKit Respository which i'm following for any ways to avoid this. I would really like to have some hidden folder somewhere while enjoying the functionality of shadow-endpoints.
+Svemix has some limitations, the current approach uses a vite plugin which is responsible for simulating the corresponding endpoint for you. This files are still public and can be queried by anyone. So you have to make sure to secure your loaders/actions accordingly. For example you should check if the user is logged-in/admin to avoid unwanted people hitting your endpoints.
 
 ### Other drawbacks