Static route configs
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 20.8k
- Forks
- 2.3k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 156
Description
Describe the problem
Named layouts and pattern matching are amazing new features that are adding a ton of value to SvelteKit, and I'm very excited about them in general! However, the filesystem is starting to get a bit crowded overall:
/[id=integer]@blank.svelte
/[username=string]/update@modal.svelte
/profile@blank.svelte
It is unlikely that many apps will start to have this level of complexity very quickly, but I could see this becoming pretty difficult to manage in time. It also has the downside that any change to one of the configuration values will probably mess with the git history a decent amount, and if we ever want to add additional configuration options here... well, we're pretty much at the limit syntax-wise as is IMO.
Describe the proposed solution
I'm not sure if this has been thought about or suggested, but I couldn't find it in my (brief) search through issues.
As I understand it, the main reason that filenames are being used over a config within the file itself is that the contents of the file are not static - they must be executed to figure out what they actually are. So in order to build the app, we would need to run the app, which doesn't really work out 😅
An alternative way this could be solved is by adding a new top level script context. This context would use a static language, such as JSON, so that the contents would be fully statically known ahead of time:
<script lang="json" context="route">
{
"layout": "blank",
"pattern": "integer"
}
</script>
This context could be parsed out independently from the rest of the file, solving the static analysis problem. It could also potentially be accessible at runtime somehow, but then it would be both a SvelteKit and a Svelte concern (though it might already be one, tbh).
This could be added in the future, as an alternative to the filename syntax. It's fully additive, and given the complexity of adding a parsing step and figuring all of the details of that out, it may make sense to hold off and focus on other concerns first.
Alternatives considered
- Keep the existing filename based solution.
- Add the syntax/feature to Svelte first instead of SvelteKit (would still need a separate parse step for SvelteKit even if it had runtime semantics, since the whole point is to not run the rest of the file).
- Have a global config, or adjacent
jsonfiles. Seems like a worse solution overall, it would mean having to keep multiple files in sync when they are ultimately related.
Importance
would make my life easier
Additional Information
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review SvelteKit's existing filename-based named-layout and pattern-matching route configuration, using the examples in the issue as the starting point. Define how a top-level JSON route context would be parsed independently and how it would coexist with the existing syntax; the issue does not identify files, tests, or a settled completion criterion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100