-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template for libraries / bindings #4
Comments
Hey @jchavarri! I guess it would depend on the binding/library. If it's a general use case, such as a CSS library (e.g. emotion), I think it makes sense to have it in the options of the template. If it's a specific use case (e.g. apollo client), it might be better to add the option in a new template, or as a generator (I think the templates should use the generators more btw, I've implemented it with the web template in mind, but I'm sure other templates would benefit from it). The line between a general use case and a specific use case can be subjective, so maybe we can discuss it on a per-library basis? That being said, as the creator of As a side note, Spin supports template inheritance, so one can generally create a template for a specific use case based on a general template just by having a few files in the new template (see https://github.com/tmattio/spin/blob/master/template/lib/spin), so the maintenance cost of having multiple templates should not be very high. |
Thanks for the swift answer @tmattio ! I didn't know about inheritance, it looks super useful 👍 .
The first 2 libraries that I'm thinking about migrating are https://github.com/reasonml-community/bs-fetch (cc @glennsl) and https://github.com/reasonml-labs/bs-css. The first one is more bindings-like, while the second are mostly pure type definitions (but also have some bindings to Emotion functions). I guess the changes from the current template are not that large. Mostly the dune file would either contain an |
@jchavarri That's great that you want to work on these, it's definitely going to make developing Js_of_ocaml applications easier! FWIW, I needed bindings for the Fetch API recently and ended up using the newly released Brr library, which provides bindings for a large portion of JS and Browser APIs.
I am not sure I understand. As it is now, the template is used to build react apps, so you'll always have an executable. What would be the kind of Jsoo application where you'd want to only generate a If you're thinking of the latter, I think it could live in another template since building bindings and applications are very different use cases. Actually, a Jsoo bindings template would be general and conventional enough that it could even be an official Spin template 🤔 EDIT: Re-reading the initial description of the issue, I understand better. So yeah, I think React applications and JS bindings could be different templates, as they are rather different use cases. |
We already have an official Jsoo template to build single page applications with Incr_dom. With the work I've been doing with Jsoo lately, I am not convinced this should be an official template anymore, but I think these ones should be:
So I'll be happy to help with the second one since that's something I wanted to work on also 🙂 |
Right, it was not an application, but I library, so maybe my proposal was kind of a stretch for this template. 😁 To clarify, what I want is to bootstrap new jsoo bindings like the ones to
This sounds great. The case for generic jsoo applications is strong, as one can create applications targeting Node.js as well, with zero dependencies on the DOM / browsers. Maybe
I'm definitely very interested in the case for bindings with gen_js_api, as mentioned. I'm not sure yet when I will be able to work on it, but I can ping you when I start. Otherwise, I'll check the repos if you get to it earlier. 👍 Thanks again! |
Hey @tmattio
I am thinking to create in the future a few libraries / bindings for jsoo. Of course I could tweak a bit the output from this template, but I wondered if it'd make sense to have some "flavour" for the template that allows users to choose which one to produce, either application or library/bindings.
Would this be better implemented as an option of this template? Or it's easier to just create a new fresh template with that use case in mind?
The text was updated successfully, but these errors were encountered: