pietroppeter / nimib

nimib 🐳 - nim 👑 driven ⛵ publishing ✍
https://pietroppeter.github.io/nimib/
MIT License
175 stars 10 forks source link

possibility to output a non temporary js file #166

Open pietroppeter opened 1 year ago

pietroppeter commented 1 year ago

our default behaviour of Js blocks is to write a nim file, compile to js, then read the js file, incroporate in html and delete it. I think this is the correct approach but in some cases you might want to generate a js file that you want to keep as a static asset. the standard use case would be a multi page site where in one notebook you generate (and "discuss/document") a js library and in other pages you just use it.

we would need to think about an api.

HugoGranstrom commented 1 year ago

This "should" be as easy as creating a new block/adding a filename to the context of the current nbJs block. As for the API, something like this maybe?

nbJsFromCodeStatic("assets/file.js", captureVar1, captureVar2):
  code here
pietroppeter commented 1 year ago

What if instead we target an api where we just add at the top:

nbJsStatic("mylib")

With that config the Js collected at the end is compiled to a "mylib.js" (you could actually omit the name and it would take the filename).

I have briefly reviewed the code and we collect all js stuff at the end and create a nbJsFromCodeOwnFile block. We could add to this block a field staticJs = true (with optional field of filename), in case it sees the nbJsStatic is executed (which adds itself the same fields to doc context). Then we would need to modify the compileNimToJs to check for staticJs context and in that case change destination folder and filename and skip removal of js and adding it to js.

This basically makes any JsCodeOwnFile (including karax blocks) a block that you can customize to make it write a static js.

Actually probably nbJsStatic should add a staticGlobal field that is checked by nimCollectAllJs so that we do not run into risks if we inherit block context from doc context (which at the moment I do not recall if we do, but it is something we could decide to do at some point).

HugoGranstrom commented 1 year ago

I think I had a different use-case in mind then. What you propose is a nimib file that is exclusively for showing the creation of a js file that can be used as a library by other files? My idea was that you should be able to both export and use the library in the same file. So the library is created from the nbJsStatic blocks, and then you import it and the ordinary nbJs blocks are using the functions exported from the library. Other files can also access it, but doing as you propose would restrict us from using the code in the same file.

But one complication with this is: how do we easily access the library functions? We have to use {.importjs.} for all symbols we want to use from the exported file. So we will have to solve that problem as well, maybe generating a wrapper.nim file with all the imports which can be imported in the Nim code? Or should you have to manually define all the wrappers manually? Any input on this?

pietroppeter commented 1 year ago

What you propose is a nimib file that is exclusively for showing the creation of a js file that can be used as a library by other files?

Yes, this is the use case I was thinking of, but now you put all sorts of doubts in what I thought :)

I will try think about it more and come up with a better explanation/use case

HugoGranstrom commented 1 year ago

Hehe 😅

Yes concrete examples are always the best. I don't have any either atm, but it just felt limiting to have it either no nbJs or all nbJs is compiled to a static file.