This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-29
Channels
- # announcements (4)
- # babashka (38)
- # beginners (66)
- # calva (35)
- # cider (3)
- # clj-on-windows (19)
- # cljs-dev (2)
- # clojure (29)
- # clojure-europe (15)
- # clojure-norway (2)
- # clojurescript (43)
- # clr (7)
- # community-development (6)
- # events (3)
- # hoplon (5)
- # lsp (23)
- # malli (7)
- # matrix (9)
- # nbb (53)
- # off-topic (5)
- # overtone (1)
- # practicalli (2)
- # re-frame (6)
- # reagent (17)
- # reitit (11)
- # specter (5)
- # tools-build (7)
- # xtdb (22)
Anyone used or tried nbb with a nest.js project? I have tried doing it same way as express.js/cljs integration however didn’t work. Tried following things:
• created a simple nest.js service ( nest new project-name
)
• ran with npm run start
and it worked fine
• created hello.cljs file and tried using this in app.service.ts file, it failed to load
• tried converting to type: module and ran it failed with another error.
Anyone ever tried this combination nest.js + nbb clojure module? Idea to plug some new clojure code into some running nest.js repo/service.
"it didn't work" is not very informative without elaborate error output or a repro that I could run locally
yes, nbb is an ES6 project, your project should also be compiled as an ES6 project, but it's compiled as CJS project
right, i am trying to build with “cjs” type for nest.js however no success. will try few more things and add more details.
async function loadNbbFile(file) {
const nbb = await import('nbb');
await nbb.loadFile(file);
}
(async () => await loadNbbFile('hello.cljs'))();
that will be one way, i am trying now. https://dev.to/wolfejw86/the-commonjs-vs-es-modules-war-is-taxing-for-us-regular-folks-out-here-one-way-to-interop-55e tried this one and for some weird reason getting argument mismatch error even when it correct ( trying this further).
I don't think the const DynamicImport has any benefits over using dynamic import directly?
yes simple await will work, i was overlooking and missed the change in app.service.ts (that’s where argument count mismatch).
there is no default export in nbb, you need to use .loadString
or whatever directly.
that also didn’t work... however it moved 1 step ahead and now control reached nestjs framework level and that threw same exception. Will try out few more things, if this works it will be great fun and easy migration to clojure stack :)
tried removing it earlier (later only got that to pull the type) - retrying without that fully (it will require some change in app.service.ts constructor (i.e., line number 7)
not sure, trying few combinations. Wouldn’t it be helpful if we add a default export to nbb package it self?
default exports aren't mandatory and I would say even an anti-pattern. there is no single thing that is "default" about the nbb API
never liked js eco-system (long live Java eco-system) and now this is adding more reasons to it.
perhaps typescript is trying to be clever and rewrites (await import('nbb').loadFile)
to a top level import which then gets compiled as require
. To work around this can you write:
async function myLoadFile(file) {
const nbb = await import('nbb');
return nbb.loadFile(file);
}
and then pass myLoadFile
?If that doesn't work, perhaps then I get why they used Function
in the earlier example
The const dynamicImport
one I mean, perhaps TS is too clever and tries to optimize it when you don't write it using that
this time server started, one more step forward. however failing to load cljs while accessing the endpoint (locahost:3000).
ah yes, that's it:
For what it's worth, if we were in regular Javascript land this would work by itself, but wouldn't you know it, TypeScript has it's own problems with this one - it's actually rewriting that dynamic import as a require statement 😢. It's even sadder to realize that there's no way around this without hiding your dynamic import from the TypeScript compiler with a hackier method.
from that article you linked (https://dev.to/wolfejw86/the-commonjs-vs-es-modules-war-is-taxing-for-us-regular-folks-out-here-one-way-to-interop-55e)
yes, please use the const dynamicImport
you head earlier, TS is rewriting dynamic import
this is 1 more step forward. now no error in module loading however data from cljs file is not returned in the api response.
can’t use .js
as want to migrate some existing service with nestjs(typescript) to clj.
(ns hello)
;; variation 1 tried
;; (defn someData []
;; "Hi, please show up in api response")
;; variation 2 tried
(defn someData []
{:a "Hi, please show up in api response"})
#js {:someData someData}
got this from the nbb docs.> however data from cljs file is not returned in the api response
where are you calling the someData
function then?
in the app.controller.ts the getHello function is getting called which is injected in the app.service.ts
changing (removed the promise, and made it only string) the return type of the getHello also didn’t help.
you are returning a JS object from the loadFile call (async, so you might want to add an await in there)
What I mean is:
getHello(): Promise<string> {
const loadFileResult = await this.loadFile("...");
const { someData } = loadFileResult;
const result = someData();
console.log(result);
return result;
}
The result of someData is not a string, but a CLJS map in your code, but hopefully you get the idea
yes, this piece of code worked for me. Thanks so much, you are awesome @U04V15CAJ .
Just relooking at organising it now for better usage.