Do we consider migrating to sveltekit

[Sparrow0hawk]

As we start to think about supporting a backend, should we consider looking in detail at something like sveltekit as a framework we could use?

Particularly interested @dabreegster your thoughts, did you look at this initially?

[dabreegster]

I've read through the SvelteKit docs and don't understand what it would buy us. But I also haven't done web dev in over a decade, so maybe I'm just stuck on the frontend / backend / database architecture.

https://kit.svelte.dev/docs/introduction#sveltekit-vs-svelte talks about intercepting links and making multiple URLs/pages be implemented without navigating away. Right now, we've only got 3 pages (homepage to choose an area, an internal-focused browse scheme page, and the main editor). I don't understand the purpose of swapping out part of the page, instead of using all the browser-native handling of multiple pages. (aka, I don't think we really care about being a "Single Page App")

Offline support and prerendering part of the page server-side also don't sound relevant. If we wanted ATIP to work offline, we're pretty close to that -- would need #45 to remove the dependency on remote map tiles. Our pages are quite simple DOM-wise; prerendering anything on a server has no purpose I can see.

To me it kind of sounds like SvelteKit mixes the frontend/backend code in a kind of confusing way. Do we even want to write the backend in TS?

Alternatives

I propose spinning this question around and starting from what we want the authenticated version of ATIP to do. I started some user stories for different groups of users in #229. From that we can figure out how to evolve the Svelte app. Very roughly, I would picture some stuff like:

• a new page for login / account management, mostly using fetch with a backend
• something to plumb around logged-in state, like cookies / sessions; I'm kind of assuming the GDS auth layer provides this, but I haven't dug into it yet
• Some new pages and regular Svelte UI components to show a scheme's timeline, manage feedback, upload files, etc. Most of these would call an API.

[robinlovelace-ate]

New page for login sounds good, that can be navigated to from link/button on open version presumably. Slightly off topic but the UI will change depending on logged-in status, right? I was thinking of a placeholder button in the open version that does nothing or says "Authenticated version in progress" or something. Alex and I discussed this yesterday and I now realise that the changes for the authenticated version will take a lot of work and that we should start on that soon.

I don't have an opinion about the choice of technology, SvelteKit or otherwise, just want the codebase to be easy to develop and deploy in other places so the generalisability of the solution should be a factor also, would it be easy to spin-up an authenticated version in Scotland, for example?

[dabreegster]

Alex and I discussed this yesterday and I now realise that the changes for the authenticated version will take a lot of work and that we should start on that soon.

Could we sketch out what the important parts are to get working in the short-term? In the backend PR doc, I proposed stuff like feedback and a timeline view that could take longer to build. If the real MVP is just auth, a way to upload new versions of files for LAs, and a way to browse all schemes, this is probably something we could prototype much faster.

[robinlovelace-ate]

Could we sketch out what the important parts are to get working in the short-term?

@Sparrow0hawk on the case, please send us stuff for review, maybe the demand doc covers some of it? Would be good to get your comments on that Dustin if you've not looked over yet.

[robinlovelace-ate]

There are open questions around what the priorities are for authentication, however. My view, given that dashboard by @becfleming-ate covers much of the key scheme level info, is that it should be for local government staff first and foremost with key features including:

• [ ] Auto upload of schemes
• [ ] Ability to view schemes in your authority, we'll need to have per-authority authentication
• [ ] Edit capabilities and everything that entails including history etc, fine as dataset volumes and velocities will be low and easily handles by a Postgres DB for the kind of n. users we're talking about in authenticated version. I don't see that as MVP though.
• [ ] New contextual layers available in dropdown menus, e.g. from OS's NGD API

The dashboard stuff that is more internal facing already covered by Bec's work largely but longer term will be amazing to have ATE level overview of all schemes for "ATE authentication" which could just be a group with access to schemes from all authorities.

[robinlovelace-ate]

Thoughts @Sparrow0hawk ?

[Sparrow0hawk]

This has slightly meandered away from the topic of this issue (sveltekit) and onto more specific ATE priorities so going to migrate to internal issue

[Pete-Y-CS]

I think we have a slightly bigger question than should we use sveltekit: How do we want to organise our front end code. Svelte kit is one answer but it might come some at costs in terms of being restrictive to how we host on github currently.

I personally think we need a task to assess and then present some options for how we want to refactor the existing front end code, if at all.

My 2 cents are that we need some more separation between logic and view. Something like MVC or MVVM altough to be honest I don't remember the exact implication of those two paradigms. Beyond that I don't know if we want a pre-existing opinionated framework, our own guidelines, or what. I think SvelteKit could be a good answer but we need someone to go away and come back with some proposals imo.

Some of these questions will inevitably play into our backend infrastructure question. I think they're separate questions but we gotta be mindful of our backend options when deciding about this.

[Pete-Y-CS]

Happy to have a crack at this after the event cleanup or to handover event stuff (https://github.com/acteng/atip/issues/228). The latter might be preferable because it could be good to have a fresh pair of eyes on the event stuff.

May also be that depending on our architecture the event handling stuff wants to change significantly anyway, I suppose.

[Pete-Y-CS]

On a point discussed in person but not in this thread.

Adopting svelte kit would not preclude us hosting on github pages: https://kit.svelte.dev/docs/adapter-static. This means we can use it with the current dev deployment method without issue. If we decide it's a nice sane way of helping us organise our code it's an option.

[Pete-Y-CS]

I've a little look into this today. I haven't found much in the way of strong recommendations or discussions of best practices for Svelte but I think I've found an uncontroversial starting point:

https://kim-jangwook.medium.com/best-practices-for-organizing-and-structuring-svelte-applications-5f85a3d5a6f5#:~:text=When%20building%20a%20Svelte%20application%2C%20it's%20important%20to%20use%20consistent,more%20easily%20readable%20and%20maintainable.

I think it would be worth reorganising our App in this way:

1. Reorganise our Svelte code into into components, pages, and store, and then see what remains outside these groups and think where we'd logically wanna put it.
2. Each Svelte component or page exists in its own directory where it has at least, maybe at most, two files: component-name.svelte and componentName.ts. Additionally I would like it if we tried to have as little actual logic in component-name.svelte files, maybe a hardline rule that all that can be called in those are named functions imported from componentName.ts?

I think this might be a nice starting point for separating our code, and would leave us pretty close to Svelte Kit view of the world so we could more easily adopt it later if we decided we wanted to.

I do see an issue of timing, though. This is going to be a hefty refactor so doing this whilst any other work is going on might be quite tricky.

[Pete-Y-CS]

Just gonna ping @dabreegster @Sparrow0hawk @markhobson in case you don't get notified by default, any thoughts on the above?

[markhobson]

I agree it'll be a lot of work, so probably best to wait until we have a clear direction. I think trying out SvelteKit as a standalone spike would be an interesting knowledge gathering exercise if you were interested.

[dabreegster]

For all of these questions, https://discord.com/invite/svelte could be a great place to ask. I've asked some questions there before and gotten great answers -- sometimes even example code! And for the questions we're asking, I reckon there's some existing threads.

Reorganise our Svelte code into into components, pages, and store

I've struggled to find best practices or good examples of how to structure stuff. Today, we're not terribly far from this -- components/ is called lib/, and there's an attempt at further organization in there. We have pages/ as well, but it's unclear to me what the conventions are for defining separate components that only belong to one page. A subdirectory per page could work.

Additionally I would like it if we tried to have as little actual logic in component-name.svelte files, maybe a hardline rule that all that can be called in those are named functions imported from componentName.ts?

Hmm, where is this recommended? I don't think I've seen example projects structured this way. The Medium article makes some odd recommendations about having a separate .js and .css file per page. I think it goes against https://svelte.dev/tutorial/styling, right? Scoping CSS to one component means much simpler selectors, often not even needing to come up with class names. I guess we'd still have this with a separate .css per page, but I don't understand the benefit.

This is going to be a hefty refactor so doing this whilst any other work is going on might be quite tricky.

I think we could do it pretty quickly. Let's agree here (or before writing lots of code) what the structure/renaming should look like, then just do it. I've got a few bigger PRs in progress, but I don't mind handling merge conflicts.

[dabreegster]

What would it look like if we try and spin around the question a bit? Rather than figure out if SvelteKit does something useful for us, let's think about likely things we want to do soon, and spend a bit of time investigating how we might do that.

Integrate with gov.uk styling

https://frontend.design-system.service.gov.uk/

I think (not sure) GDS requirements will ask us to use these design standards. I helped/watched Will add this to https://github.com/ADD-William-WaltersDavis/dft_hackathon a few months ago, and I think it required configuring one of those CSS preprocessors. We could experimentally cutover current ATIP to this design system to figure out any integration challenges. There's existing code we can refer to of that integration with Svelte, and Will to ask for help if we get stuck.

Integrate with One Login

I haven't started looking into https://www.sign-in.service.gov.uk/ yet. We could see what it'll take to integrate with a static Svelte app (or discover that it needs some backend that isn't gov-run, and prototype that).

[Pete-Y-CS]

@dabreegster

I think we could do it pretty quickly. Let's agree here (or before writing lots of code) what the structure/renaming should look like, then just do it. I've got a few bigger PRs in progress, but I don't mind handling merge conflicts.

I agree, I mostly wanted to flag that we would want to be mindful of other ongoing work ideally

Additionally I would like it if we tried to have as little actual logic in component-name.svelte files, maybe a hardline rule that all that can be called in those are named functions imported from componentName.ts?

Hmm, where is this recommended? I don't think I've seen example projects structured this way. The Medium article makes some odd recommendations about having a separate .js and .css file per page. I think it goes against https://svelte.dev/tutorial/styling, right? Scoping CSS to one component means much simpler selectors, often not even needing to come up with class names. I guess we'd still have this with a separate .css per page, but I don't understand the benefit.

It's not explicitly recommended but as a principle from most frameworks of writing a GUI that I've worked with, and when thinking about things being modular: it has generally been recommended and good to separate the code that describes the visuals from the logic operating on the data. It's implied by that medium article by the naming conventions but I haven't found somewhere recommending specifically this. Maybe I'm missing some reason it makes sense in SvelteLand to have the more entangled but it doesn't feel like good practice. Feels like a code smell to me.

[dabreegster]

Old issue that turned into a few conversations. We're using Express today as our backend, and sticking with Svelte for the frontend