scottbedard/sveltober

Cybernetically enhanced October applications

Project status

This project is a starting point for applications using Svelte and October CMS. It also comes with support for Tailwind CSS, as this framework pairs beautifully with Svelte.

Click here for a live demo!

Notice: This is still experimental, be careful before taking it to production. In the future, we hope to provide deployment guides for the Laravel ecosystem with Forge and Envoyer.

Getting started

The first step to creating a Sveltober theme is to clone this repository into October's /themes directory.

git clone [email protected]:scottbedard/sveltober.git

Once this is done, run a yarn install from your new theme directory. After doing this, the following commands will be available.

# start webpack dev server
yarn dev

# build production assets
yarn build

Server side rendering and routing

This theme uses server side rendering, and as such requires a Node environment. With Laravel Homestead, and many other environments, it should already installed for you. All routes are pointed at the compiled index.htm, which feeds the request into our Svelte application. Our client-side application then hydates the DOM, and things behave as a SPA from then on.

If you'd like to opt-out of server side rendering, this can be achieved with the following steps.

1. Remove the server config from webpack.config.js.
2. In the client webpack config, set hydratable to false, and in /src/main.js set hydrate to false.
3. Delete ssr.js, and the onStart and interpolation content from src/index.htm.

Routing is currently being handled by svelte-routing, see their readme for documentation. Out of the box, a few routes have are scaffolded for you to demonstrate the basic ideas. If you're using SSR, be aware that the order of your routes matter.

sveltober's Issues

Feature wishlist

I'm opening this issue mainly as a place to brainstorm features I'd like Sveltober to have. None of this is guaranteed to be implemented, I'm just thinking out loud.

Demonstrate code splitting

For non-trivial applications, we'll want to bundle split each route. The starter template should demonstrate how to do this.

Server side rendering

Update: We now have server side rendering. It is currently causing some issues with hot reloading which we'll need to look into. For now it can be fixed with a page refresh.

We should be able to use this package to perform server side rendering. The problem here is that themes (as far as I'm aware) cannot have their own composer dependencies. I need to look into this further, if it's not possible for themes we might have to be upgrade to a plugin. Being a plugin wouldn't be the end of the world though, and might even be a good idea since most applications will need their own plugin anyway.

Ideally we should make this easily configurable as well. If users want to opt-out of SSR for whatever reason, we should keep that available.

Testing utilities

We need to make it easy to do some every day testing tasks like rendering and interacting with components. Ideally we can get this all wired up with circleci and codecov and provide a handful of example tests that also get us to perfect coverage.

SSR with async data

I'm opening this issue as a place to brainstorm where to go with SSR. We're running into an issue where unnecessary XHR requests would need to be fired to fetch initial data. Imagine the following route...

/blog/:slug

Ideally, the server would be able to respond with the entirety of that page, including the content of the blog post. This will be good for both SEO purposes, as well as allowing the page to work in non-javascript environments.

Currently, the server will respond with the layout, and on mount that page would then have to fetch the underlying blog post. The reason for that, is because SSR rendering is synchronous. There is an open issue discussing an async renderer, but it looks like not much has come of it (sveltejs/svelte#958). To get around this, we'll need to perform our data fetching before rendering the application, and then feeding the state in.

Because of this, I'm starting to think that it's time to promote this project from a theme, to a plugin. Along with be able to fetch data more easily, we could also make our app feel more like a traditional Laravel app by providing correct status codes, caching the SSR results, and more.

On first thought, something like a specialized controller might do what we need. Each endpoint method would return some initial data, and our single page application would be able to fetch that data either during SSR, or in a page component's onMount hook.

use RainLab\Blog\Models\Blog;
use Sveltober\SSRController;

class BlogController extends SSRController
{
    public function show($slug)
    {
        return Blog::whereSlug($slug)->findOrFail();
    }
}

The underlying SSR controller would always return our main entry point, and feed into it the results of this query. From the client, we could then send a special request to the url we're currently on to get the results from this endpoint as JSON. We'll also have to tell the controller where our build App.js is. We'll have to give this some more thought, but perhaps a static property on the model or some hook in the plugin's boot method would work.

One downside to this technique though, is we can't use Svelte's await blocks...

{#await expression}
    <!-- loading -->
{:then name}
    <!-- ready -->
{/await}

As soon as the SSR compilation hits the async block, it's going to spit out the loading state and move on. To get around this, data that overlaps with SSR would have to do something more like this...

{#if loading}
    <!-- loading -->
{:else}
    <!-- ready -->
{/if}

This isn't the biggest problem in the world, but might be something we need to think about further.

Update: For anyone following this, I've decided to start experimenting with a plugin API. We should be able to use https://github.com/spatie/server-side-rendering to build the response, as well as feed in any initial state it needs. Once things start to stabilize, we'll probably make this it's own plugin that sveltober applications can then rely on.

[Question] Server Sided Rendering

My question to this is is it generating static pages for server sided rendering like how nuxtjs does it or would you need a node server underneath. Because for the node server (and vuetober/nuxtober) you can get SSR easily with the node server, but not so easily if you're only utilizing static pages, in which case comes my second question.

Have you tested generating static pages with ids and such?

Demonstrate 404 page

We should probably demonstrate how to return a 404 page, but it looks like we're a bit roadblocked by this issue. We'll implement this once svelte-routing finalizes some more of these decisions.

EmilTholin/svelte-routing#18

Assets

Ignore this issue, it's just a place to upload static assets.