I've binge-read the Svelte tutorials for the last few days and it's time to start writing some basic test projects to go beyond basic concepts.

I'll be posting progress and insights here as I go.

About

I found a basic dependency resolution algorithm Gist the other day and decided to use it as the basis for learning more about Svelte. Basically, an excuse to do something other than stay stuck in tutorial-mode.

Graph theory lies at the heart so many modern development paradigms that I thought it would make an excellent MacGuffin.

Project Code

• CodeSanbox
• Github

Features / To Do

👍 Convert current plain JavaScript CodeSandbox to Svelte.
👍 Format the execution order with an ordered list.
👍 User editable dependency lists that update in realtime. (add/remove items in left column)
🔘 Auto color-coding of dependencies.
🔘 Hovering an item highlights its use elsewhere (bi-directional item highlighting for legibility)
🔘 Add infinite nested levels of dependencies.
🔘 Revise language... 'before', 'after', 'subscribers', 'items', etc.
🔘 Toggle real-time mode.
🔘 CodeMirror for the dependencies editor
🔘 Undo/redo changes.
🔘 Read a package.json or other dependency configuration and display its resolution. Upload or via URL / fetch.
🔘 Save to localStorage
🔘 Save state to json / file download
🔘 Authenticated users
🔘 Basic CRUD interface for user lists
🔘 Sharing dependency lists
🔘 Visualization of dependency graph
🔘 API - DRaaS (Dependency Resolution as a Service)

Svelte Concepts to incorporate

• Reactivity
• Fetch, Async/Await
• Props
• Slots
• Binding
• Lifecycles
• Stores
• Motion and Transitions
• State management
  • Basic w/out library
  • XState
  • Overmind
• Authentication (oAuth 2.0)
  • Firebase (w/ Cloudflare Workers KV)
• User storage
  • Cloudflare Workers KV
  • Explore Durable Objects as an option
  • Basic CRUD interface for dependency maps
• API

Progress

Oct 21, 2020

I turned the dependencies and execution order sections into Svelte components that update automatically on user input by adding a resolution store and auto-subscribing to it.

I'm planning on adding CodeMirror which I'm assuming would be best implemented with a Svelte module.

I found some old libraries that shoe-horned CodeMirror into Svelte, but they were from Svelte 1.x, no longer work and are no longer maintained. Just as well, though, since it will provide an excuse to learn more about Svelte modules and lifecycles.

Oct 22, 2020

To be honest, now that I've worked with some of the basic fundamentals of Svelte, I'm more interested in its utility as an authenticated app. Which is the way I'll be using it. In other words, an app that you can sign-in to, do stuff (CRUD, etc), and log out of.

So now I want to try Firebase authentication with a router. And for that I have two options in mind that I'd like to explore...

1. Traditional - A node server w/ authenticated routes and apis. In which case, Sapper.

2. Edgy (literally) - Achieve the same effect with higher performance and scalability with Cloudflare Workers, KV and HTMLRewriter stream injection.

I've recently read through a couple of great tutorials by Ilia Mikhailov that walk through using firebase auth w/ Svelte either directly or w/ XState.

I'll skip XState for now and focus on the more immediate task of evaluating Sapper, Cloudflare, and service workers.

Oct 25, 2020

It looks like running Sapper on Cloudflare is certainly possible. There is a GitHub repo that demonstrates it.

$ git clone https://github.com/lukeed/svelte-ssr-worker
$ cd svelte-ssr-worker
$ npm install

I also found an interesting svelte/firebase/cloudflare project on Svelt's subreddit: https://www.reddit.com/r/sveltejs/comments/gt16s8/new_side_project_saas_built_with_svelte_open_demo/

Oct 27, 2020

Sidetracked with a project, but managed to install Sapper locally and get acquainted. Beyond the basics, one idiosyncrasy that I found with Sapper vs Svelte is the difference between the Client and Server Component APIs.

Focusing an input on component mount doesn't work in Sapper

Let's say you have a text input that you want to receive focus on DOM ready.

In Svelte (w/out Sapper) you simply add an onMount method and focus the element after having bound it to a variable with bind:this={inputElement}. See example (not mine)

In Sapper, this doesn't work because, as the Sapper API explains:

Unlike client-side components, server-side components don't have a lifespan after you render them — their whole job is to create some HTML and CSS. For that reason, the API is somewhat different.

I've yet to work out how to use this insight to accomplish the focus-input-onmount effect.

My initial inquest was to create a separate button that calls a handleFocus component handler on:click and that works. When you click the button the element is focused. But we want automatic focus onMount.

So now it's a matter of how to do it within a Sapper app.

My two initial thoughts on strategy are:

1. The Svelte Way™ (unknown atm)
2. A traditional DOM event listener of some sort shoe-horned into the Sapper paradigm. (the least desirable option)

I don't really need this for anything at the moment, but I don't like the idea of leaving it unsolved as it provides some important insights into the fundamental differences between client and server-side Svelte components.

I'll post with more when I have it.

Update: Mystery Solved (a cup of coffee later)

.focus() doesn't work onMount on purpose for a11y reasons. Here's an explanation from Rich:

Comment for #619

Rich-Harris commented on Apr 07, 2019

This is for a11y — when navigating, the focus is supposed to reset (which is also the reason that the autofocus attribute is discouraged): https://github.com/sveltejs/sapper/blob/master/runtime/src/app/app.ts#L154

The focus reset happens after navigation, so setting the focus in onMount will have no effect. If you really need to focus the input then the setTimeout is necessary, but ideally I'd try and see if there's an alternative that doesn't break a11y guidelines.

View on GitHub

                                          Thanks for the cup of obvious.