🦋 Changeset detected

Latest commit: ecc109d

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

(Also: we might think this thing is too complex to have in a demo app, in which case I'm certainly open to alternatives. The code can probably get simplified a bit though, it was written under conference deadline conditions.)

One of my initial suggestions would be whether we can stick the word lists in some external package. That's a lot of stuff to ship with everyone using create-svelte whether or not they opt to use the Sverdle example.

counterpoint: it's easier to delete the entire sverdle directory than to do that and hunt around in package.json for unused packages. case in point: i forgot to remove the cookie and @lukeed/uuid packages even though they are surplus to requirements

counterpoint: it's easier to delete the entire sverdle directory than to do that and hunt around in package.json for unused packages. case in point: i forgot to remove the cookie and @lukeed/uuid packages even though they are surplus to requirements

Is the demo app supposed to be something people modify and build their own app upon? I had thought it was just something to learn from and then they would use the skeleton template when creating a new app.

How about downloading the words list from kit.svelte.dev/somewhere or raw.githubusercontent.... and then cache it on disk when it first runs? Could be done using an inline vite plugin or in create-svelte only if the demo template is selected, that way consumers of other templates wouldn't be affected.

TL;DR - Keep Sverdle as a demo application, introduce some middleway of a create-svelte-kit-app which creates all directories useful, add maybe readme's and maybe an advanced hello world.

The templates are now a skeleton, a library skeleton and the todo app. Maybe to have Sverdle as a 'template' is misleading as it is complex. However, this is an useful application to look at. It answers my questions I had when I started with SvelteKit.

I want to propose an enhanced create-svelte-app. Maybe with a bit more flexibility on the components to import. Implicitly this is just a simplified general template. For example, with the directories, and possible a README there? (or does that make it bloated?) So you have the structure of the full fledged SvelteKit app, but the cleanness of the skeleton.

Having more than two versions would be too much to choose as a newcomer ("what do I pick?") and maintain in my opinion. To be clear the Sverdle would replace the TODO example.

For me the question comes down to finding a good middle ground for the app that

• showcases most of the basic features
• is easy to dig into and understand
• is shiny, i.e. you like to browse it a few minutes, it's not just a "here's what you can do, look at the code, the app is boring"

The TODO application is so good that everyone understands its idea.

Sverdle - WTF? First I need to find out what it is. And then only check how it works in SK.

I agree with one thing: TODO in its current form should disappear.

BTW:

I miss an example of logging in, storing data in the session, connecting to the database, (group), [slug], REST-API ...

I suggest that there are 2 applications to choose from:

• very simple - where TODO would be replaced with the form: "Enter your name, enter 5 here" (to show error handling)

• advanced - showing all the possibilities of SK. (Eg.: shop: list products, guest favourite (cookie), login, add to chart)

  • We should "create" design patterns to avoid security issues with login: #6315, #6996.
  • "Deleting" the session made a lot of confusion. Suffice it to say that this mechanism is called differently in SK (and show how to use it)
  • You have to show that the database connection can be done in hooks (Before I accidentally found this solution, I was using Custom Server + second repo for API)
  • There should be an example for (group), [slug] and resetting layouts.
  • There should be an example for using server.js, and #6997

Is the demo app supposed to be something people modify and build their own app upon? I had thought it was just something to learn from and then they would use the skeleton template when creating a new app.

The latter, though a lot of people do use the 'default' template (which should probably be renamed to 'demo') when creating repros etc. (That's probably our fault, since we publish https://github.com/sveltejs/kit-template-default but not https://github.com/sveltejs/kit-template-skeleton.)

Sverdle - WTF? First I need to find out what it is. And then only check how it works in SK.

When it's finished it'll have instructions and a more self-explanatory UI, which will hopefully address that

I miss an example of logging in, storing data in the session, connecting to the database, (group), [slug], REST-API ...

I hear you, for sure. The trouble is that any not-completely-unrealistic demonstration of those features requires a back end, and then we're back at the same problem we had with /todo — we can either provide one for you a la api.svelte.dev, or we add a bunch of hoops you have to jump through if you want to actually deploy the thing. I definitely think there's a place for those sorts of examples (somewhere on learn.svelte.dev ideally, eventually) but it's probably not the demo app

Could we reduce the possible (allowed) words so the files aren't that huge? Also, what are the allowed words for? Why can't we just compare against the chosen word?

Not without making the game less fun to play! The allowed words are less common English words that are valid submissions, but won't ever be chosen as the answer.

I can't shake the feeling though (and I'm sorry, because you really put a lot of work into this) that it may be too much for a demo app. I think it's super impressive to see how to make this work without JavaScript, but actually understanding the code takes some time and much of it is unrelated to SvelteKit concepts - which may not be obvious and then people might think "oh SvelteKit is too complex for me".

Yeah, I get that. I've rewritten the app so that there's a single component with a single form. Even though we'd normally break something up into separate components to improve readability, in this case it had the opposite effect because (for example) the enter key inside Keyboard.svelte referenced the <form> in +page.svelte, but you'd only know that if you understood what the form and id attributes do in that context.

The new version is much easier to follow, if I do say so myself. The page is basically one screen's worth of script, another screen's worth of markup, then a bunch of styles. It's not quite as simple as /todos but it's a lot more fun/unique and the use of cookies as a datastore feels much more appropriate in this context, so I reckon we can get away with it!

I think that this game is nice for demo, but not for initial template(the dictionary file isn't suitable for example).

I suggest to have some classical game that the user plays against the server(a simple AI player), like tic-tac-toe or 4 in a line. It avoids the dictionary file issue, while I'm sure that a simple AI mechanism can be coded/copied.

Additionally, I also think that the simple TODO app (or anything alike) is essential for template, because it demonstrates the CRUD ability, so I suggest to like this page in the template, and only add new ones. Maybe a good idea for solving the remote latency feeling issue is to let the user decode, in some switch button, whether to use a local storage(e.g. by allowing the server to store the state in a cookie or by a in-memory storage) or a remote one.

BTW: It's always nice to have an indication for the user, that it's loading the result from server, e.g. by a simple loading line.

the dictionary file isn't suitable for example

It's fine! It's completely trivial compared to (for example) the contents of node_modules

tic-tac-toe or 4 in a line

the trouble is those games are really boring :)

it demonstrates the CRUD ability

I'm not sure what this means to be honest — SvelteKit doesn't have 'CRUD ability', it just has arbitrary actions. If we demonstrate CRUD we need a back end, which brings back the issue this PR was designed to address. A switchable back end adds complexity and makes the example sufficiently unrealistic that it starts to lose value.

always nice to have an indication for the user, that it's loading the result from server

yeah, we could add something. not sure what the best UI would be

the dictionary file isn't suitable for example

It's fine! It's completely trivial compared to (for example) the contents of node_modules

OK

tic-tac-toe or 4 in a line

the trouble is those games are really boring :)

🧐🤨🙄 OK, matter of test. I just thought it's easier and more classic for a startpoint, in the logic of that the normal user doesn't use svelte-create to generate a game he likes, he goes to official sveltekit demos for it😅. Not sure if we need a game at all for a startpoint templats though, although I really would like to see these stuffs on demos.

it demonstrates the CRUD ability

I'm not sure what this means to be honest — SvelteKit doesn't have 'CRUD ability', it just has arbitrary actions. If we demonstrate CRUD we need a back end, which brings back the issue this PR was designed to address. A switchable back end adds complexity and makes the example sufficiently unrealistic that it starts to lose value.

I'm not good at word choice here, I meant by "CRUD abilities" the meaning of "CRUD startpoint template", which is far more useful to the user. For example, I used this "TODO" generated route, for checking how Kit team chose to break the API everytime🤣. I believe that it will be useful, at least for me, to see "only the code I need to see" in the TODO route for remembering again the suggested CRUD structure in Kit.

Could we reduce the possible (allowed) words so the files aren't that huge? Also, what are the allowed words for? Why can't we just compare against the chosen word?

Not without making the game less fun to play! The allowed words are less common English words that are valid submissions, but won't ever be chosen as the answer.

I still don't get it. Why check against a list of allowed words? Why not do "ok you didn't hit any of the characters in this word -> wiggle"? Is it because you could have a valid word without any shared characters? How often does this happen? Is it worth keeping this for the additional thousands of words we need for that?

The new version is much easier to follow, if I do say so myself. The page is basically one screen's worth of script, another screen's worth of markup, then a bunch of styles. It's not quite as simple as /todos but it's a lot more fun/unique and the use of cookies as a datastore feels much more appropriate in this context, so I reckon we can get away with it!

Yeah it reads much better now (although the question stays if we are just too familiar already if it by now). Btw the "how to play" page needs some love 😄 Maybe a section on how it works under the hood would also be good, so that you can already grasp from a high level how it works without looking a the code. Something like "Under the hood this uses regular forms and cookies to implement the game. This means it even works without JavaScript!"

I still need to do an a11y pass on this, but I can make a follow-up issue for that.

I still don't get it. Why check against a list of allowed words? Why not do "ok you didn't hit any of the characters in this word -> wiggle"?

The wiggle happens if you enter an invalid word, not if you enter a wrong word