V2

[jakobrosenberg]

With all the new features of the v1.4.x-beta, I think it might be time to move on to a new major release. 1.4 features listed below:

• CLI
• independence of Rollup
• code-splitting (added in previous version)
• HMR support
• realtime support for new page files (eh?)

I have some thoughts and ideas outlined below. Nothing is set in stone and all feedback welcome.

Ideas for v2

Name: Routify

I never liked the name svelte-filerouter much. It was just a quick name for an ad hoc project. The project has since grown and I think it deserves a "proper" name now.

Home: github.com/grottolabs (or something more svelt'ish?)

Helpers:
Make the url helper context aware to support relational routes based on current file. Can this be done through import without adding extra boilerplate? If not, restrict the url so it's only accessible as a prop -This would also sort circular dependency warnings.

Page props
We currently have route, routes, url, _routeOptions, scoped and components "poluting" every page. Should we combine them all in one object, prefix them or do both?

"scoped" prop
I'm not sure how I feel about this one. Should page props be passed as any other prop instead? Can it be done programmatically? Route.svelte I'm looking at you.

Separate rollup/webpack plugins
#18
Does Rollup/Webpack/Parcel still serve a purpose for this project?

Custom routes
There's technically nothing in the way of being able to pass custom routes to . Would this be a good feature though?

Query parameters in route object
#5

Hash based routing
#22
Since the file-router maps resources to paths like a traditional router, I don't see much point in hash based routing. However, it would be a nice feature to have for those who prefer.

EDIT: Added hash based routing suggestion.

That's for it now. What do you think?

[matthewrobb]

@jakobrosenberg

What are your thoughts on using svelte context api? Simply passing url() via props has a limitation for deeply nested components (non-"routed" components).

Having come from the React ecosystem I think one of the real productivity jump starters is the maturity of ReactRouter and it's status as a defacto standard there. I think it's useful to keep svelte in the name so long as it's the target for the project.

It seems reasonable to think of the project as a few different things:

1. Build time route config generator
2. History management lib
3. Svelte Router/Route/Link etc components (intended to consume route config, and history manager)
4. Specific build system plugins/loaders

A person should be able if they so choose to use the route config generator with a "bring your own router components" model. This project's components can gain an advantage through tighter integrations with the generated config which a person would have to build for themselves otherwise.

[jakobrosenberg]

@matthewrobb some good points there.

Context api
I've considered it before, but never thought of it for the helpers like url. Would be a great solution.

Only concern is, the context api isn't reactive and passing a store isn't an option with the current store/transition bug, so the question is: Do we need the context to be reactive? At the top of my head, no.

Name
My thoughts on this was to create a new github organization named something like sveltegear and scope the npm modules, so you'd have @sveltegear/routify.

My gripe with the current name isn't the Svelte prefix, but the filerouter. It sounds blunt, ambiguous and unappealing to me.

What do you think of svelte-routify? It's shorter, IMO more descriptive and sexier.

Build system
Would there be a point to maintain loaders for build systems, now that there's a CLI?
I've switched to the CLI in my current project.

The CLI functions the same was as sirv in the way that you simple add it in to the run-p command.

[matthewrobb]

@jakobrosenberg

Build system
For myself, already using rollup for a lot in my projects it is definitely simple/convenient to use a rollup plugin rather than configuring it seprately. With the changes already made it would likely be a very tiny plugin that deferred 95% of what it did back to the lib.

Name
I agree with svelte-routify is a very solid name

Context API
I don't believe there would be any need for reactivity, no. However there could easily be a non-svelte/store subscribe option which would effectively only trigger on history events and enable component-local reactivity where needed that way.

[jakobrosenberg]

One bit of reactivity that I missed. route. If you have a navigation menu styled to reflect the currently active page, you need reactivity.

Between passing route through all props and using a store, I think I'd prefer the store. Anything else would require too much boilerplate.

[jakobrosenberg]

Helpers

I Haven't found a silver bullets for helpers so far.
Since all pages are children of Router.svelte, which is a child of runtime/index.js, importing helpers from @sveltech/routify results in circular dependency warnings.

Option A) create core module
Abstract Router.svelte + dependencies into @sveltech/routify-core and use @sveltech/routify for everything else (helpers).

Option B) create helpers module
Bypass runtime/index.js and import directly from @sveltech/routify/helpers or create a helper module @sveltech/routify-helpers.

Option C) expose routes
...And import routes manually

example

<script>
  import { Router } from "@sveltech/routify";
  import { routes } from "@sveltech/routify/tmp/routes";
</script>

<Router {routes} />

Options D) Props
Expose helpers to all pages

Current obstacles.
Imports The getContext API is only available at component instantiation. Therefor certain helpers would require initialization if imported.
Props Props pollute and require manual passing to components.
Boilerplate In general I'm against added boilerplate, but I do like the idea of exposing the routes. I think it's helpful to anyone wanting a look under the hood.

[devhormiga]

Hello I have a problem.
I try to use the hash based routes.
the typical ones where we use an ID in a div and then in the <a href="#id"> tag

but it didn't work for me with routify

I have tried different things

in my app.svelte:
<Router config = {{useHash: true}} {routes} />
when I do it the links stop working, if I set it to false, they work.

then he left ne true and put the links like this

<a href={$url('que')} target="_self"> What is it? </a>
but this works in my local environment, but taking it to production doesn't work ...

some help?
Thank you so much