You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 12, 2020. It is now read-only.
So I've spent a little bit of time trying to see if I could make ssg work like Gatsby for page creation (with the createPage node API hook).
My approach is currently
Fetch data from my CMS in createIndex and cache it
Use this.ssgData in the preload function of my [slug].svelte component
The main problem with this approach is that the route matching is dependent on file structure. My [slug].svelte component can only match routes at level 1. If I want sub-pages I need to create a component at [one]/[two].svelte. The problem is I would like to be able to create an indefinite number of nested routes on my external CMS without having to worry about how many sub-folders I created in the source code.
Another problem (arguably) that is obvious with the way Sapper create files on export is it only creates files for routes that can be crawled from the index page. We cannot create 'hidden' pages or landing pages for example.
Is it something you are interested to handle with ssg @sw-yx ?
For now, ssg seems to be focused on having your data along with your source code. If we want to enable programmable page creation it seems we are going to diverge from Sapper's core principles in major ways.
The text was updated successfully, but these errors were encountered:
About the second problem, I just discovered the (new?) --entryoption that I think allows us to specify entry points for our app to be crawled from.
If we implement programmatic routes creation, we could use this option to specify all created routes...
hey! yes. my intention is to depart from Sapper sooner or later. Quite frankly i have been dragging my feet because it will be a lot of work. but yeah a programmatic createPages api makes sense.
if you have a way to implement it in this project and need it to get your stuff done, be my guest. i can't promise i'll get to the ssg rewrite soon since it is just a hobby project
Sure! I understand.
To be honest I wouldn't know where to begin to do that with Sapper.
I have a feeling that a new svelte ssg implementation might be around the corner with your recent experiments and the guys active on the svelvet projet (for reference).
If I get to the point where I really need this, I think I will just hack around it with nested folders like I mention above for now.
yes, exactly. too early to do this now. it would actually NOT be that hard, if you read the Sapper source code you can figure out where to insert it but it takes time and energy haha. lets just make sure we have this api when we do the rewrite
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
So I've spent a little bit of time trying to see if I could make ssg work like Gatsby for page creation (with the
createPage
node API hook).My approach is currently
createIndex
and cache itthis.ssgData
in thepreload
function of my[slug].svelte
componentThe main problem with this approach is that the route matching is dependent on file structure. My
[slug].svelte
component can only match routes at level 1. If I want sub-pages I need to create a component at[one]/[two].svelte
. The problem is I would like to be able to create an indefinite number of nested routes on my external CMS without having to worry about how many sub-folders I created in the source code.Another problem (arguably) that is obvious with the way Sapper create files on
export
is it only creates files for routes that can be crawled from the index page. We cannot create 'hidden' pages or landing pages for example.Is it something you are interested to handle with ssg @sw-yx ?
For now, ssg seems to be focused on having your data along with your source code. If we want to enable programmable page creation it seems we are going to diverge from Sapper's core principles in major ways.
The text was updated successfully, but these errors were encountered: