Skip to content

Migrate to SolidJS - #30

Merged
JackTench merged 14 commits into
LibreSplit:mainfrom
StarlitLuna:solid-refactor
Aug 20, 2026
Merged

Migrate to SolidJS#30
JackTench merged 14 commits into
LibreSplit:mainfrom
StarlitLuna:solid-refactor

Conversation

@StarlitLuna

@StarlitLuna StarlitLuna commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

I did a test deploy on my fork's github pages that you can view for the purposes of comparing this version using Solid to the current version using react. It's accessible here: https://lsorg.starlitluna.com/

For the most part; all visuals, functionality, behavior etc should be preserved and the migration should be relatively small with minimal changes.

Some bigger changes including using native methods of handling dom state, reactivity etc. Some bigger changes include using the Kobalte UI toolchain which is a first-party UI package for SolidJS that handles some common UI features.

Finally, I did also choose to make some changes that I felt made sense despite not strictly speaking being a proper port/migration. These are:

  1. The file upload component dropped multi-file support.
  • I felt trying to generalize this component prematurely when we really only need one file at a time since the change handler explicitly forces the file(s) to be immediately handled was unnecessary. If we ever actually need multi-file uploads, we can revisit this and add support as fits our needs instead.
  1. I removed the github button's fake anchor element programmatic click in favor of just using a real anchor for the button. This is the cleaner approach imo.
  • I also changed repoUrl to be required since it didn't really make sense for the github button not to have a repoUrl imo.
  1. Removed the AppLoading component in favor of using skeletons. When components are loading, a skeleton is the more common UI visual these days and it fits better with Solid native tags like Show/fallback and the Skeleton component comes with Kobalte. See video for example:
  2. Changed the github workflows to use npm ci which is the more appropriate dependency installation command for unattended setup. It requires a package-lock.json be present, performs a clean install of it, and guarantees it's using the versions specified in package-lock instead of installing new versions or something along those lines.
  3. Added some developer convenience settings/extension recommendations/launch configurations for developing/debugging with VSCode.
Screencast_20260819_181349.webm

Might be a thing or two I missed, but feel free to ask if you have any questions!

@StarlitLuna

Copy link
Copy Markdown
Contributor Author

@JackTench I also just migrated the project to OXFmt instead of prettier. The formatting rules set are very similar, but it allows for flexibility to configure as we like. Also added OXLint for linting more serious typescript issues and such. Then ran the linter and formatter.

@JackTench

Copy link
Copy Markdown
Member

Currently the components that live in src/compnents/ui are all from shadcn (or "addons" to shadcn). Is it a good idea to use the SolidJS port of shadcn, so new components can be added via the CLI when they are required?

If so, it may be better to use them now, instead of the hand ported components.

@StarlitLuna

Copy link
Copy Markdown
Contributor Author

Currently the components that live in src/compnents/ui are all from shadcn (or "addons" to shadcn). Is it a good idea to use the SolidJS port of shadcn, so new components can be added via the CLI when they are required?

If so, it may be better to use them now, instead of the hand ported components.

Ah interesting, I didn't know that's how those were added I'll take a look

@StarlitLuna

Copy link
Copy Markdown
Contributor Author

Currently the components that live in src/compnents/ui are all from shadcn (or "addons" to shadcn). Is it a good idea to use the SolidJS port of shadcn, so new components can be added via the CLI when they are required?

If so, it may be better to use them now, instead of the hand ported components.

So for something that works similar to this, the one you linked hasn't been maintained in almost a year and is currently broken. There's a much more active one over here: https://github.com/stefan-karger/solid-ui

But they are waiting on Solid v2 before updating Tailwind to v4. I think we should just accept the hand ported versions for now, then examine that project if we actually want to start importing more components and then have it rewrite the existing ones once Solid v2 is out. (currently in RC)

@JackTench

Copy link
Copy Markdown
Member

As you know solid better than me, I'll take your word for it.
Would be good to start using SolidUI when it's updated to Tailwind v4.

As for everything else, LGTM, happy to merge and go live.

@JackTench
JackTench merged commit 189a921 into LibreSplit:main Aug 20, 2026
2 checks passed
@StarlitLuna
StarlitLuna deleted the solid-refactor branch August 21, 2026 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants