This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-27
Channels
- # announcements (14)
- # aws (2)
- # babashka (12)
- # beginners (23)
- # calva (71)
- # cider (37)
- # clj-kondo (47)
- # cljs-dev (3)
- # clojure (55)
- # clojure-brasil (1)
- # clojure-europe (51)
- # clojure-nl (1)
- # clojure-norway (63)
- # clojure-poland (1)
- # clojure-seattle (1)
- # clojure-uk (3)
- # clojurescript (10)
- # conjure (3)
- # cursive (23)
- # data-science (5)
- # emacs (16)
- # events (1)
- # hoplon (16)
- # hyperfiddle (19)
- # introduce-yourself (1)
- # kaocha (5)
- # nyc (1)
- # portal (31)
- # practicalli (2)
- # reitit (3)
- # releases (4)
- # sci (28)
- # slack-help (13)
- # sql (4)
- # squint (40)
- # tools-build (25)
- # tools-deps (10)
Here's the custom viewer:
(ns data-viewer
(:require [portal.ui.api :as p]))
(defn data?
[v]
(and (map? v)
(contains? v :duration)))
(defn view-data []
(fn [data]
[:<>
[:h1 "Duration"]
[:portal.viewer/inspector
{:portal.viewer/default :portal.viewer/duration-ms}
(:duration data)]]))
(p/register-viewer!
{:name ::viewer
:predicate data?
:component view-data})
When I tap this:
(tap> (with-meta {:duration 39847} {:portal.viewer/default :data-viewer/viewer}))
Ohh, yeah, when migrating hiccup to reagent, the viewers do need to be resolved manually.
You can pull in [portal.ui.inspector :as ins]
and wrap the value with the ins/inspector
component.
related issue, I tried to require portal.viewer
in my custom viewer and it threw Could not resolve symbol: implements?
when I ran (p/eval-str (slurp "data_viewer.cljs"))
https://github.com/djblue/portal/blob/master/src/portal/ui/sci/libs.cljs#L62 if you want to edit it locally
diff --git a/src/portal/ui/sci/libs.cljs b/src/portal/ui/sci/libs.cljs
index a4c7e77..12d2bf3 100644
--- a/src/portal/ui/sci/libs.cljs
+++ b/src/portal/ui/sci/libs.cljs
@@ -96,6 +96,7 @@ (def namespaces
portal.ui.viewer.vega-lite)
(sci-import/import
cljs.core/random-uuid
+ cljs.core/implements?
cljs.core/tap>
cljs.reader/read-string)
{'reagent.core
hm, didn't seem to like that:
❯ clojure -X:build prep
=> Generating docs
=> clojure -M:cljs:shadow -m shadow.cljs.devtools.cli release client
[:client] Compiling ...
------ ERROR ------------------------------------------------------------------- File: /home/nate/projects/portal/src/portal/ui/sci/libs.cljs:98:4
--------------------------------------------------------------------------------
95 | portal.ui.viewer.tree
96 | portal.ui.viewer.vega
97 | portal.ui.viewer.vega-lite)
98 | (sci-import/import
----------^---------------------------------------------------------------------
null
Unable to resolve var: implements? in this context at line 98 portal/ui/sci/libs.cljs
--------------------------------------------------------------------------------
99 | cljs.core/random-uuid
100 | cljs.core/implements?
101 | cljs.core/tap>
102 | cljs.reader/read-string)
--------------------------------------------------------------------------------
-> 17.783 seconds (exit: 1)
Execution error (ExceptionInfo) at tasks.tools/sh* (tools.clj:58).
Non-zero exit code: clojure -M:cljs:shadow -m shadow.cljs.devtools.cli release client
Full report at:
/tmp/clojure-17926749571961529956.edn
perhaps because it's a macro?When working with portal and devcontainers, I keep running into issues with the config file missing. (vs-code.edn file). But it seems to be complicated by the difference between normal operation and working in a devcontainer, and it seems to be intermittent. Has anyone else run into this?
Yes, and Chris showed me how to solve it... just a sec...
https://github.com/seancorfield/vscode-calva-setup/blob/develop/joyride/src/remote_repl.cljs -- this is how I connect to QA/production REPLs -- in particular, see https://github.com/seancorfield/vscode-calva-setup/blob/develop/joyride/src/remote_repl.cljs#L33 which takes the current Portal config (host/port etc) and sends it to the server to write out locally so that you can open Portal (in my case, into my local VS Code)
Thank you. I'll take another look. This seems to be a slightly different issue, I want to say the container creation process is copying the directory, but not the contents. It is certainly related, though. I think I'll have to set up a controlled experiment to narrow down what's going wrong.
Oh, in my repo, someone accidentally merged a change that set portal to an old version. That'll probably be it. Sorry for the confusion.