This will be everything that should be refactored in the front end of Bolt. Some of these will definitely be subjective, but I'll try to keep it as objective as possible. As I go through the app, I'll continue to add more to this list. As they get fixed, I'll check them off.
General Guidance:
[ ] Svelte Stores shouldn't be overused. Svelte generally handles reactivity for you, but there are cases when stores are helpful. Svelte 5 helps make this more clear, but we can work on upgrading everything after this PR.
[ ] Window events (onload, onunload) should be avoided. Svelte has its own lifecycle functions hooks
[ ] Duplicate Svelte code can be wrapped into components
[ ] State variables should be scoped to a component. For eg, keeping track if a modal is open can be handled by a Modal component, not globally across the app
[ ] Returning early can help readability and prevents unnecessary indentation
[ ] Type casting creates unsafe code in TS. Usually you want to avoid manually casting things, or use generics
[ ] It's very rare to use classic .querySelector or .getElementById code in Svelte. You can usually can bind the element to a variable and access it that way
Specific Changes
[x] Replace msg/err with a Logger utility class
[x] Replace Backdrop.svelte with a generic Modal.svelte that can handle its own open/close state
[ ] Todo: PluginMenu is broken? I couldn't figure out how to get it loaded, anyway
[ ] Todo: In app.svelte, the {#if} branches for the modals should go away. I started doing this, but other code needs to be refectored first
[ ] I think most of the stores in main.ts can be put somewhere else, and likely not be a store. Not sure on the details yet.
[ ] The majority of main.ts can be cleaned up and reorganized elsewhere. At first glance, we can probably create a BoltService.ts, and maybe an AuthService.ts
[x] Create a Dropdown.svelte, replace the dropdown code in Account.svelte with this new component
[ ] When using the select element, you can bind the value of an option to any type of variable. The on:change will then have that value in the event. Namely in Launch.svelte, this will remove the extra data-id code.
This is quite a bit, so it'll take me some time since I have a full time job - probably a week or two. Let me know if anyone has any problems with the proposed changes. @smithcol11 I'm not sure if you have any pending changes on your end, but this will likely break whatever you have going on. Let me know if we need to chat outside of github and we can.
This is not ready to merge.
This will be everything that should be refactored in the front end of Bolt. Some of these will definitely be subjective, but I'll try to keep it as objective as possible. As I go through the app, I'll continue to add more to this list. As they get fixed, I'll check them off.
General Guidance:
.querySelectoror.getElementByIdcode in Svelte. You can usually can bind the element to a variable and access it that waySpecific Changes
main.tscan be put somewhere else, and likely not be a store. Not sure on the details yet.data-idcode.This is quite a bit, so it'll take me some time since I have a full time job - probably a week or two. Let me know if anyone has any problems with the proposed changes. @smithcol11 I'm not sure if you have any pending changes on your end, but this will likely break whatever you have going on. Let me know if we need to chat outside of github and we can.