Fork me on GitHub
Jakub Holý (HolyJak)12:07:47

Regarding - would it be perhaps possible to get Calva hook into the TypeScript support that VS Code has and show completions, type hints for native TS React components, just as Code does when writing TS?

👀 1

This would be great to explore some. I do think we should be able to bridge a lot of this friction. Maybe even create a better experience working with JS/TS libraries from ClojureScript than what TS provides. Related comment on Joyride discussions:

❤️ 1

Is a direction the calva team is interested in pursuing for portal integration?


I've been working on some which automatically sends evaluated values to portal. I'm wondering if there is an easy way to get it added to the middleware stack on jack-in. Might be pretty useful for beginners :thinking_face:


That branch/PR seems to hardcode a version of Portal -- is it a good idea to then always need an update to Calva any time a new version of Portal is released?

👍 1

@U1G869VNV Is that nREPL stuff in the latest Portal release? Is it ready for testing?


As you know, I've switched from Socket REPL to nREPL/CIDER (to take full advantage of Calva) so I'd be happy to try out this middleware 🙂


Everything except for the lastest shadow-cljs changes and preventing submits when portal is closed are part of the last release :thumbsup:


Any feedback would be awesome ❤️


OK, integrated it into my :dev/repl alias stuff and... it's a bit weird to use... First off, because it creates logging-like structures, instead of seeing maps and vectors expanded at their top-level, you have to manually go in and expand the "logged" item. Second, because I have quite a few custom commands that send code to the REPL which often tap> something, those now produce multiple rows: the tap>'d result and the log-like row for the result of that eval (which tends to be true -- the result of tap>).


In addition, it kind of breaks my custom commands that use Portal's eval-str to manipulate the Portal UI -- such as toggling expansion of various levels of data in Portal.


When I eval top-level expressions from Calva, they show up as user (although the line number is correct), regardless of which file I'm evaluating in. Some things show a pretty random line number (again, in user) that I can't figure out where that's coming from.


Oh, that "random" line number is coming from the output.calva-repl window which isn't terribly useful 🙂


I think just p/submit on the :result of the nREPL data structure -- without all the other stuff -- would be much more useful, along with a way to bypass that submit (having code that can return some special keyword that Portal's nREPL middleware knows about -- so you can eval code that manipulates Portal's UI without having Portal p/submit that result back into itself).

👍 1

I guess you could always provide two different wrap-portal functions: one that does what it does now -- producing log-like output of each eval -- and a minimal wrapper that just submits the :result value (with the datafied throwable stuff still), and also has a special keyword that suppresses the submit. Then folks could choose which variant they want to use.


I'd say that, yes, it is a direction I'd like to go. I paused the work with it when I couldn't get a consistent behaviour between Clojure and ClojureScript. Iirc, it was that that portal wouldn't run integrated with the latter.

👍 1

I have been intending to find some time to check the shadow-cljs integration improvements out. Because sounds very interesting!


@U04V70XH6 I've mainly tested the nrepl middleware with lein repl / cider, looks like calva is a little different :thinking_face: I like having the log viewer because I jump between clj/cljs repls and like using the goto definition command on repl result, but I see how it's annoying for your workflow. I do think having more customization around how repl results are submitted to portal is useful, just not sure how to make nrepl middleware customizable.


Calva already has ctrl+t t for tap current form/selection and ctrl+t space for tap top level form so I guess nREPL integration isn't as important...