pixelmund / svemix

The Full-Stack addition to SvelteKit. Write your server code inside svelte files, handle sessions, forms and SEO easily.

Welcome to Svemix

Svemix is a somewhat different framework than you're probably used to. It can be seen as an full-stack addition to Svelte(SvelteKit). Svemix provides you with server scripts inside your Svelte components/routes, which will be transformed into endpoints. Loader functions and actions similar to remix, which also run only on the server, improved developer experience, SEO handling, easy to use forms, sessions and so much more.

For an still early example please look into this repo.

This repository contains the Svemix source code. This repo and project is a work in progress, so we appreciate your patience.

Documentation

For documentation about Svemix (which is missing a lot of things), please visit our website.

Contributing

If you're interested in contributing code and/or documentation, feel free to open an Pull Request. A Contributing Guide will follow in the Future.

svemix's Issues

Update to newest kit version

Kit got some recent breaking changes, we'll have to change some docs, endpoint handlers, session.

Optimistic ui

Future of svemix

Describe the bug

The new routing changes in kit will probably change the future of svemix.

I've just managed to avoid generating the page endpoints in #54 and i'm a little bit frustrated now because the new routing proposal would make svemix kinda obsolete. I love svemix because you can write your server code directly inside your svelte files.

I see a few ways to continue svemix

• Fork SvelteKit before the new routing changes and try to be up to date with any changes in kit unrelated to routing.
• Change svemix to use the new folder-based routing.
• Discontinue svemix

Your Example Website or App

Steps to Reproduce the Bug or Issue

Expected behavior

Screenshots or Videos

Platform

Additional context

No response

Help with documentation

I have created a documentation site, hosted on vercel with svemix. This documentation is really bad currently. I'm really not that good in explaining all the things svemix has to offer. If someone wants to help me out there, any help is much appreciated!

Handle file uploads

There could be a way to handle file uploads, unfortunately SvelteKit errors on multipart requests. Maybe we'll have to wait or find a way to solve this in Kit.

For reference #70

Small typo in svemix.com/docs/getting-started/data-loading

hi! there's a small typo in https://svemix.com/docs/getting-started/data-loading

I believe "you" should be "your" here:

"This enables us to import a database or any other stuff that should never reach the client directly inside you Svelte Routes."

Thanks for sharing the project!

Refactor into imported functions

Currently we're creating the endpoints with the same code over and over again, we could create functions inside svemix/server which we import and call instead. This will also be better for refactoring and working on those functions, because of Syntax Highlighting etc.

Create a logo

JS disabled forms loose state

Currently if javascript is disabled and a user fills out the form with an error, the errors and data entered will be lost. We would have to come up with a solution to save the form state somehow. I thought about using URLSearchParams but im not sure if this is the right way to do it. I have already began work here https://github.com/svemix/svemix/tree/better-js-disabled-form-handling.

Another solution would be to save the state in the session, but setting up sessions is not required currently, so this would not work for anyone.

Tests

Don't know how the tests could work in our case. But im sure there a vite plugins which are tested properly, should get some knowledge and then write a lot of tests..

Internal Server Error 500 If `kit.config.trailingSlash: "always"`

In SvelteKit one can configure whether routes should or should not have a trailing slash and this has relevance when it comes to relative urls. However, Svemix will throw an error if kit.config.trailingSlash: "always".

This config will work:

import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';
import svemix from 'svemix/plugin';


/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: preprocess(),
	kit: {
		adapter: adapter(),
		target: '#svelte',
		vite: 
		{
			plugins: [svemix()]
		}
	}
};

export default config;

But this will not:

import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';
import svemix from 'svemix/plugin';


/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: preprocess(),
	kit: {
		adapter: adapter(),
		target: '#svelte',
		vite: 
		{
			plugins: [svemix()]
		},
		trailingSlash: "always" // this line is the problem
	}
};

export default config;

To test this, remember to delete the $__svemix__ directories after changing the config.

The error that one gets is An unknown error occured, which originates from load.ts.

I do not know for sure why this happens, but I have two speculative theories:

1. There is some string.split("/") action going on somewhere.
2. The kit.config.trailingSlash option messes with the generated Svemix files. In other words, when kit.config.trailingSlash: "always" one should search for the appropriate endpoint from a different location. This has most likely something to do with the endpoint index.ts files.

Explanation number two seems more probable, but I do not know for sure.

Sveltekit prefetching is not working

Prefetching of routes using sveltekit:prefetch is not working on anchor elements <a sveltekit:prefetch href="/users">Users</a>

Finish the example

We should finish the example and write a tutorial, how we did it.

Prerendering might not work

I don't know If prerendering works right now. Because we're accessing the page query and it throws an error on prerendering. Maybe there is an work around for that.

Document Limitations of Svemix

Svemix is a great plugin, but it does have it's limitations. These limitations should be documented.

Some important limitations:

1. The loader responses are JSON serialized, which causes overhead.
2. The populated objects (e.g. export var book: Book) are not really of the specified type, but rather just JS data objects. This means that one can not call type functions, for example, book.getYearsSincePublication().
3. An extra request is made to the server.

Respect SvelteKit Config for `kit.files.routes`

The route directory can be changed with SvelteKit like this:

const config = 
{
    kit: 
    {
        files: 
        {
            routes: "src/web" // or whatever
        }
    }
}

However, this configuration will essentially disable Svemix, because the route directory is hardcoded as src/routes.

This can be fixed by amending the config like this:

const config = 
{
    svemix: 
    {
        routes: "src/web"
    },
    kit: 
    {
        files: 
        {
            routes: "src/web" // or whatever
        }
    }
}

However, the fix is not documented, nor is the property routes a part of Svemix_Config_Object. Although, the property routes is a part of the defaultConfig, which is why the problem can be fixed.

Still, the most sensible way to go about this would be just to respect the configuration of kit.files.routes.

Explore methods that don't generate magic endpoints

Currently every route that declares context="module ssr" generates a corresponding endpoint file under $svemix. I would really like to explore methods that doesnt need this behaviour, maybe we can use the handle hook for this. Or create the .svemix folder in the root of the project similar to SvelteKit, but then there would bei changes in kit needed for allowing multiple routes folders.

Better Documentation

Describe the bug

I've revamped the documentation / website, it's now really easy to edit docs because you just have to edit/create .md files under the documentation folder.

We can take a look at the remix docs or sveltekit to find the best way how to handle our docs correctly.

Your Example Website or App

--

Steps to Reproduce the Bug or Issue

--

Expected behavior

--

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

No response

Relative imports in ssr scripts are wrong

I've noticed that since we're writing the endpoints INSIDE the svemix folder, relative imports don't resolve correctly. I see three things to solve this problem:

• Keep it as is and teach users to use aliases e.g. $lib.
• Change the way it works currently by creating .json endpoints in the same directory as the route.
• Scan all relative imports and replace them accordingly, probably very error prone.

Update to newest kit version

There where some breaking changes inside kit which we will need to handle correctly. For reference:
sveltejs/kit#3124

Better Error-Handling

Describe the bug

Currently there is no easy way to throw errors inside loaders/actions. We should probably come up with an easy to use solution.

I have something like the following in my head:

<script context="module" ssr>
  import {  NotFoundError, HttpError } from "svemix/errors"
  export const loader = () => {
    throw new NotFoundError("User not found").
    throw new HttpError("Custom Error", { status: 401 });
   }
</script>

Which we could then make use of via instanceOf

Your Example Website or App

--

Steps to Reproduce the Bug or Issue

--

Expected behavior

--

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

Would make life easier

Svemix Can Not Be Used Together With Certain Preprocessors

Describe the bug

Svemix does not work with certain preprocessors. For example, enabling MDsveX so that Markdown can be used in component source files will stop Svemix from working.

I am not sure about what causes this. Maybe it is something that is specific to MDsveX and Svemix or maybe it is a more general issue.

The order in which preprocessors and plugins are executed could have some effect on the matter.

Your Example Website or App

https://github.com/Acmion/svemix-mdsvex-bug

Steps to Reproduce the Bug or Issue

See the readme of the linked repo.

Expected behavior

It should be possible to use preprocessors (e.g. MDsveX) and Svemix together.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Chrome
• Version: 99

Additional context

Maybe Svemix can be implemented as a preprocessor rather than a plugin to solve the issue? This should at least let us specify the order, however, I am not sure whether this would fix the issue or not.

Security Issue (Relatively Minor)

I detected a relatively minor security issue in Svemix, but I will not post it here. Could I contact you in some other way?

Examples

Describe the bug

We should write some examples and include best practices in there, the remix ones are kinda cool. Will probably take some time, so i don't know but this is definetly a must have for 1.0.

Your Example Website or App

--

Steps to Reproduce the Bug or Issue

--

Expected behavior

--

Screenshots or Videos

No response

Platform

Additional context

No response

Maybe avoid generating endpoints next to routes

Describe the bug

The situation is a bit tricky, we're currently using/generating SvelteKit Endpoints next to the files, but this can quickly sum up to a lot of files. I don't know if there is a way to avoid generating them while still using the functionality. This should probably belong to Kit, but i'm not sure what a solution in Kit would look like.

• I've already tried using different techniques with the handle hook, but all seem wrong.
• I've also experimented and looked into if we could solve this with our vite plugin.
• Maybe allowing multiple route paths in Kit would help with this issue?

We could also leave it the way it is currently.

Your Example Website or App

Steps to Reproduce the Bug or Issue

Expected behavior

We shouldn't create the endpoints visible to the user.

Screenshots or Videos

Platform

Additional context

Duplicate question mark in querystring

Not sure if this is the culprit, but it think it might be. https://github.com/svemix/svemix/blob/78e9a62d79a59ff58237e44949125bd1f7b71b05/dist/plugin/pipeline/transformers/ssr.js#L38

# Traefik reverse proxy in front of application
http-traefik-1  | 172.27.0.1 - - [24/Jan/2022:05:53:26 +0000] "GET /signup?flow=170de342-0b56-4ea7-8908-151a6efc6325 HTTP/2.0" 303 0 "-" "-" 2268 "iam-frontend@docker" "http://172.27.0.6:3000" 48ms

# Within sveltekit + svemix application
http://hostname/$__svemix__/signup??flow=170de342-0b56-4ea7-8908-151a6efc6325 
URLSearchParams { '?flow' => '170de342-0b56-4ea7-8908-151a6efc6325' }

query.has("flow") # false
query.has("?flow") # true

Endpoint Layouts

There is an proposal for shared shadow endpoints which svemix can make use of via __layouts, these layouts would generate a __middleware.js or whatever it's called.

sveltejs/kit#3735

This might also open up the shadow endpoints for stuff which can get passed down from middlewares to shadow endpoints.

Once something goes into kit this would be a great addition to svemix

Prerendering any content

Hi,

I am currently discovering the Svelte ecosystem after a long and deep dive into Next.js, especially it's pre-rendering capabilities.

I am not yet totally convinced, because I feel like SvelteKit is closer to create-react-app, with no server for the pages, than Next.js, that is fully exploiting the fact that the app runs with a Node server, with features such as getServerSideProps (edit: there is an equivalent in SvelteKit though, but I mean things like Image component).

I mean specifically the server that process the request to UI page, not API routes or endpoints. In Next.js this server is usually hidden (you can setup your own but it's not recommended). In SvelteKit it seems to be done via the concept of adapter?

I've designed a pattern that let's you pre-render any kind of data, including private, paid and custom content. However, it requires to have a micro-server in front of the pages, which Next.js have recently introduced with middlewares. As far as I can tell there is no equivalent in SvelteKit, except maybe via a custom adapter (at this point I've only read the doc, not much played with the tool so it's theoretical).
Here is the article describing this pattern : https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde

Remix takes a slightly different road by relying a lot on HTTP caching. It's kinda equivalent in terms of number of renders, but I am not sure it can be configured to achieve an optimal number of rendering yet.

Is it something that would interest you in the context of Svemix?

Leverage SvelteKit's `stuff`?

Hi, thanks for sharing some great ideas in Svemix! metadata support is something we've long wanted to add to SvelteKit and we've now enhanced stuff such that it can be used for those purposes. Would it make sense for Svemix to leverage it?

E.g. there's an example in the Svemix docs:

<script context="module" lang="ts" ssr>
	export const loader: Loader<Props, Locals> = async function ({ params }) {
		try {
			const post = await db.post.findUnique({
				where: { slug: params.slug },
				rejectOnNotFound: false
			});

			if (!post) {
				return {
					status: 404,
					error: 'Post not found'
				};
			}

			return {
				props: {
					post
				}
			};
		} catch (error) {
			return {
				status: 500,
				error
			};
		}
	};

	export const metadata: MetaFunction<Props> = (props) => ({
		title: props?.post.title,
		description: props?.post?.content
	});
</script>

This could be written using SvelteKit's stuff as:

<script context="module" lang="ts" ssr>
	export const loader: Loader<Props, Locals> = async function ({ params }) {
		try {
			const post = await db.post.findUnique({
				where: { slug: params.slug },
				rejectOnNotFound: false
			});

			if (!post) {
				return {
					status: 404,
					error: 'Post not found'
				};
			}

			return {
				props: {
					post
				},
				stuff: {
					metadata: {
						title: post.title,
						description: post.content
					}
				}
			};
		} catch (error) {
			return {
				status: 500,
				error
			};
		}
	};
</script>