petegriffith
commented
2 years ago Hey hey! Not digging into this at all but one thing I think we need to consider is how to render markdown - functionally the center of the app.
Open wiru opened 2 years ago
petegriffith
commented
2 years ago Hey hey! Not digging into this at all but one thing I think we need to consider is how to render markdown - functionally the center of the app.
petegriffith
commented
2 years ago This is great! Really well thought out and the flow is natural. I'm super psyched to try vitest, I've heard it's crazy fast (also great for CI/CD pipeline speed). Nice work digging into some of the subscription stuff, that's really interesting.
One thing is that I might suggest proofreading. There are a couple of grammar/punctuation mistakes.
Nice one!
wiru
commented
2 years ago Thanks Pete!
Yeah… Julie mentioned that too.. I really must start proof reading. For some reason I’ve always disliked doing that. But I’ll make the effort for the next one. I tend to 95% research and 5% slapping it down in a document.
I’ll aim to improve it on this in the future for sure. Thanks again for the kind feedback.
On Aug 31, 2022, at 20:28, Pete Griffith @.***> wrote:
This is great! Really well thought out and the flow is natural. I'm super psyched to try vitest, I've heard it's crazy fast (also great for CI/CD pipeline speed). Nice work digging into some of the subscription stuff, that's really interesting.
One thing is that I might suggest proofreading. There are a couple of grammar/punctuation mistakes.
Nice one!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
File structure
The file structure I believe will look something like this. Tauri will exist within its own folder and search for static files from Svelte. Svelte will need to both create static files, as well as an SSR ready web app. Larger components covering areas of a viewport such as headers, sidebars etc, will be organised within a templates folder. Individual components smaller and smaller components will be comprised of modular “bricks” to make everything as reusable as possible. Unit/component tests will reside in the same location as the file that they are testing. E2e tests will reside in their own folder and be organized by page and purpose.
my-project/ ├ src-tauri/ │ ├ icons/ │ │ └ someIcons │ ├ src/ │ │ └ main.rs │ ├ cargo.toml/ │ ├ build.rs/ │ ├ tauri.conf.json/ ├ src/ │ ├ lib/ │ │ └ Components │ │ │ └ Templates │ │ │ │ └ Header │ │ │ │ └ Body │ │ │ │ └ Footer │ │ │ │ └ Sidebar │ │ │ └ Button │ │ │ │ └ Smallest possible assortment required │ │ │ │ └ someButton.test.js │ │ │ └ Modal │ │ │ └ Form │ │ │ └ Icon │ │ │ └ Table │ │ │ └ Etc │ ├ params/ │ ├ routes/ │ ├ app.html ├ playwright/ │ ├ index.ts │ ├ index.html ├ static/ ├ tests/ ← Playwright tests here │ ├ testexample.ts ├ package.json ├ svelte.config.js ├ tsconfig.json ├ playwright.config.ts └ vite.config.js
Architecture
Component layout
A series of folders and subfolders within the svelte src/lib folder. Organized by type. The objective would be to keep the number of components to a bare minimum. They would be created to be flexible and accept variables / atomic sass to change their appearance where needed. But the overall consistency of the UI would be such that there should not be an excessive amount of customization needed, in order to maintain a solid look and feel for UIUX. The components would be bespoke to avoid using a library. The downside to this approach is potentially increased development time. However, the long term benefits of controlling our own UI components library completely should become apparent over time. State management Using the subscribe function in Svelte we can create stores to access data within any component it is required, whilst being able to keep it more organized. We must be careful to avoid memory leaks however, for example if a component subscribes, but does not unsubscribe from some reactive data before being destroyed and recreated. Svelte also has a relatively clean way to do this with the $ symbol, which will help to keep code length more reasonable and readable.
Application flow
The user will first come to our Auth server to receive a validation token via an API request. They will then be able move to our resource server to make API requests and to access the logged in experience of the app. API calls whilst using the desktop app through Tauri/Sveltekit or the web app Sveltekit, will be routed directly the Go back-end. Whilst we could use Tauri as an intermediary for desktop, I do not see any value taking the time to do this for only one platform.
UI implementation
The UI will be made purely in svelte where possible. With only specific or complex components using a library in order to save on development time. For this reason we will need to choose a markdown editor/compile. We can use ByteMD here as it is made in Svelte and built for speed. Other benefits of ByteMD include SSR support and XSS attack vector blocking.
With regards error handling, we can handle errors in a standard fashion of try/catching. One point of note here is that an error should crash the whole app experience. Whilst there are possibilities to isolate a particular component without the entire app breaking such as using svelte-error-boundary. Such errors are usually the result of a failed await operator, in which case we should be correctly implementing a robust try catch to account for this possibility instead of relying on a crutch.
Testing
Whilst Jest the current most popular testing framework, there is a strong argument that its use with Vite is problematic. This is due to the fact there is a significant amount of duplicate work occuring, and can be a rather fragile pairing to maintain. For this reason, Vitest will be a better choice. The drawback here is that it is relatively new. But the benefit of having a much more secure coupling and more performant testing framework designed for Vite is worth this trade off. Benefits include a watch mode that understands Vite and performs “almost like HMR” according to the vitest team, able to retest only changed files. Vitest also uses c8 which provides native code coverage for node.js’ v8 engine. Regarding e2e testing, once again, one would gravitate toward Cypress as the natural option in this area. However, the Sveltekit team recommend using a newer option in Playwright. Some of the benefits of Playwright are Webkit support and parallelisation. Also, as we are using Sveltekit, which will provide SSR as standard, there maybe instances where Cypress is “too fast” and attempts to interact with elements that have not been hydrated, whereas Playwright is guaranteed to wait for elements to be actionable.
Deployment
To deploy the front end we would:
Dependencies
ByteMD appears to be a functional markdown editor made in (Svelte). A demo is viewable here, but it is bare-bones and will require some additional styling for our desktop/web app. As Tauri looks for static files to display in its webview, we will also need to use Svelte https://sveltejs/adapter-static@next.