search

orbitinghail / sqlsync

SQLSync is a collaborative offline-first wrapper around SQLite. It is designed to synchronize web application state between users, devices, and the edge.
https://sqlsync.dev
Apache License 2.0
2.19k stars 28 forks source link

solid js library #37

Closed matthewgapp closed 6 months ago

matthewgapp commented 6 months ago

Port of the React library for Soild JS. Have it working with a downstream demo app, which is also a port of the React SQLSync demo.

Todo

carlsverre commented 6 months ago

Wow Matt! This looks awesome. I agree, I think that a ton of code needs to be refactored out into a shared js lib for the different frameworks. I didn't realize how similar the react and solid implementations would be - that's good to know! Appreciate the work here, will get back to this PR asap once I have a chance to play around with it and think about how I want to refactor things.

matthewgapp commented 6 months ago

Wow Matt! This looks awesome. I agree, I think that a ton of code needs to be refactored out into a shared js lib for the different frameworks. I didn't realize how similar the react and solid implementations would be - that's good to know! Appreciate the work here, will get back to this PR asap once I have a chance to play around with it and think about how I want to refactor things.

Thanks! Yeah, Solid JS and React APIs are very similar. I have a bit of cleanup to do and will mark as ready for review. I should get around to it this afternoon.

matthewgapp commented 6 months ago

Wow Matt! This looks awesome. I agree, I think that a ton of code needs to be refactored out into a shared js lib for the different frameworks. I didn't realize how similar the react and solid implementations would be - that's good to know! Appreciate the work here, will get back to this PR asap once I have a chance to play around with it and think about how I want to refactor things.

Thanks! Yeah, Solid JS and React APIs are very similar. I have a bit of cleanup to do and will mark as ready for review. I should get around to it this afternoon.

@carlsverre should be ready for a review. As noted in the description, I didn't run the test locally. Not sure how I should go about building and running the sanity test without investing more effort. I can confirm that it's woking in my downstream demo application. I'm about to fold it into my production application so will let you know if I run into any issues there.

matthewgapp commented 6 months ago

As an aside, I'm excited to use and contribute to this project. The first two items on my mind are pluggable auth and storage but I don't know the specifics around what I need just yet. I should know more soon as I start to integrate it into my application.

carlsverre commented 6 months ago

@matthewgapp No worries on testing, I'll do that as part of integrating this.

One thought I had is whether merging all the framework libraries into one would be better? With modern JS build systems, the unused library code should be ignored pretty well. That way I just have different imports for each framework but it would be easier to share code that's similar.

The other option is what you said above, which would be to refactor out the core SQLSync client class into a standalone library that each framework library depends on. I think that's probably the right approach, but curious what you think.

matthewgapp commented 6 months ago

@matthewgapp No worries on testing, I'll do that as part of integrating this.

One thought I had is whether merging all the framework libraries into one would be better? With modern JS build systems, the unused library code should be ignored pretty well. That way I just have different imports for each framework but it would be easier to share code that's similar.

The other option is what you said above, which would be to refactor out the core SQLSync client class into a standalone library that each framework library depends on. I think that's probably the right approach, but curious what you think.

I think it would depend on what your JS users would expect. I'm no expert on managing the all-so-tiring JS ecosystem but I'd err on the side of simplicity, both for authors and users. I think a thick JS core library and thin framework-specific wrapper approach aligns best against the goal of keeping things simple on the user side IMO. I'm not sure if a single library would be easier or worse for authors. However, separating the JS core from the framework libraries does ensure that the wrappers stay thin and decoupled, helping new framework authors get started without extensive knowledge of the JS core lib.

carlsverre commented 6 months ago

@matthewgapp I just landed the react refactor. Can you rebase this on the main branch? For some reason the current git state of this branch also includes all my changes.

carlsverre commented 6 months ago

also for testing, can you make a solidjs version of guestbook-react? you can also just re-use the existing reducer that's also in the examples directory.

matthewgapp commented 6 months ago

also for testing, can you make a solidjs version of guestbook-react? you can also just re-use the existing reducer that's also in the examples directory.

@carlsverre implemented the guestbook and seems to be working. I noticed that you moved away from vite and to rollup for react library. How come? And would you like the solid js moved over to rollup too?

carlsverre commented 6 months ago

It's not strictly needed, but I moved over for consistency. Since I moved the example out of sqlsync-react and into examples, it no longer seemed that vite was as needed. Rollup is slightly easier to control for libraries whereas vite seems better when you are shipping web apps.

matthewgapp commented 6 months ago

@carlsverre think i've addressed your comments. I moved the build from vite to rollup. Also fixed formatting but might not have caught everything. CI seems to be failing on unrelated LLVM stuff.