Skip to content
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

Open
jchavarri opened this issue Oct 16, 2020 · 5 comments
Open

Template for libraries / bindings #4

jchavarri opened this issue Oct 16, 2020 · 5 comments

Comments

@jchavarri
Copy link
Contributor

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?

@tmattio
Copy link
Collaborator

tmattio commented Oct 16, 2020

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 jsoo-react, it makes a lot of sense to me that you can give the template the direction you want, so I'm happy to give my opinion, but I certainly won't veto any addition 🙂

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.

@jchavarri
Copy link
Contributor Author

Thanks for the swift answer @tmattio !

I didn't know about inheritance, it looks super useful 👍 .

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?

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 executable or library stanza, depending on the case 🤔 What do you think?

@tmattio
Copy link
Collaborator

tmattio commented Oct 18, 2020

@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.

Mostly the dune file would either contain an executable or library stanza

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 library stanza? Or is it that you want to use the template to bootstrap new Jsoo bindings?

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.

@tmattio
Copy link
Collaborator

tmattio commented Oct 18, 2020

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:

  • General Jsoo applications (without any library)
  • Jsoo bindings with gen_js_api

So I'll be happy to help with the second one since that's something I wanted to work on also 🙂

@jchavarri
Copy link
Contributor Author

What would be the kind of Jsoo application where you'd want to only generate a library stanza? Or is it that you want to use the template to bootstrap new Jsoo bindings?

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 fetch functions, and this will imply having a single library stanza (in most cases).

I am not convinced this should be an official template anymore, but I think these ones should be

  • General Jsoo applications (without any library)
  • Jsoo bindings with gen_js_api

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 Incr_dom example could become a "custom" template, like this one?

So I'll be happy to help with the second one since that's something I wanted to work on also

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!

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

No branches or pull requests

2 participants