pixelmund / svemix Goto Github PK
View Code? Open in Web Editor NEWThe Full-Stack addition to SvelteKit. Write your server code inside svelte files, handle sessions, forms and SEO easily.
Home Page: https://svemix.com
License: MIT License
The Full-Stack addition to SvelteKit. Write your server code inside svelte files, handle sessions, forms and SEO easily.
Home Page: https://svemix.com
License: MIT License
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?
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.
We could also leave it the way it is currently.
We shouldn't create the endpoints visible to the user.
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
Prefetching of routes using sveltekit:prefetch
is not working on anchor elements <a sveltekit:prefetch href="/users">Users</a>
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
.
--
--
--
No response
No response
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.
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
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>
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.
--
--
--
No response
No response
Kit got some recent breaking changes, we'll have to change some docs, endpoint handlers, session.
We should finish the example and write a tutorial, how we did it.
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..
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.
Svemix is a great plugin, but it does have it's limitations. These limitations should be documented.
Some important limitations:
loader
responses are JSON serialized, which causes overhead.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()
.There where some breaking changes inside kit which we will need to handle correctly. For reference:
sveltejs/kit#3124
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:
$lib
.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
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:
string.split("/")
action going on somewhere.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.
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.
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.
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
.
I detected a relatively minor security issue in Svemix, but I will not post it here. Could I contact you in some other way?
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.
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
--
--
--
No response
Would make life easier
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!
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.
No response
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!
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.
https://github.com/Acmion/svemix-mdsvex-bug
See the readme of the linked repo.
It should be possible to use preprocessors (e.g. MDsveX) and Svemix together.
No response
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.