Fork me on GitHub
#reveal
<
2021-01-05
>
phronmophobic19:01:44

now that I’ve found out that it’s easy to write reveal plugins, Im considering what kind of plugins I might find useful enough to write. Some examples: • a profiler • an exception explorer with tracing and instrumentation support • more visualizations Looking at the list and it seems like some of the ideas are tools typically provided by an IDE. Would these types of plugins be a good fit for reveal? Should I be considering other IDEs that might already provide these tools? I do think there’s value in having these dev tools in process. RDD has already primed me to like the idea of my repl starting up my IDE rather than the other way around. thoughts?

vlaaad19:01:03

Good initiative! I think all your examples are good things to do, given how everything can be connected and explored with popup-view the sum would be much more than the sum of the parts

vlaaad19:01:38

I also think it makes sense to look at IDE features because reveal is available in every IDE, so implementing an IDE feature there will make it available to the whole community instead of a subset of Clojure users that use that particular IDE.

vlaaad19:01:01

To be fair "the whole community" is not every Clojure user, but every Reveal user 😂 Still, I find Reveal — at least for myself — much more useful as a REPL than what I see built into other Clojure IDEs, so I would still say it's very useful because (a) it will make it easier to change IDEs without losing much in the process of transition and (b) reveal allows stitching tools together with it's action popup system, which is not something IDEs do.

phronmophobic20:01:30

I was thinking similarly, but wanted to check that it was philosophically aligned with reveal

phronmophobic20:01:14

additionally, the amount of code for each plugin that is specific to reveal is minimal so if I wanted to try these plugins out in another IDE, it should be theoretically possible (except I run my IDE in terminal).

vlaaad21:01:26

Made a little experiment that adds support for vega charts from vega-lite specs as plain clojure maps:

vlaaad21:01:29

It's hacky and unreliable and can't get back to data inside those charts (e.g. the view is a leaf), but it's a powerful visualization engine, so here is a snippet (you'll need clojure.data.json dependency):

(action/defaction ::view:vega [x]
  (when (or (and (:data x) (:mark x) (:encoding x))
            (and (:repeat x) (:spec x)))
    (fn []
      {:fx/type fx.ext.web-view/with-engine-props
       :props {:content (str "<head>\n  <script src=\"\"></script>\n  <script src=\"\"></script>\n  <script src=\"\"></script>\n</head>\n<body>\n  <div id=\"view\"></div>\n  <script>\n    vegaEmbed(\n      '#view',\n      "
                             (json/write-str x)
                             "\n    );\n  </script>\n</body>\n")}
       :desc {:fx/type :web-view}})))

vlaaad21:01:05

I only tried it on this sample data:

{:data {:values [{:category :a
                  :amount 10}
                 {:category :b
                  :amount 20}
                 {:category :c
                  :amount 15}]}
 :mark :bar
 :encoding {:x {:field :category
                :type :nominal}
            :y {:field :amount
                :type :quantitative}}}

phronmophobic21:01:04

I was going to ask if you were displaying it in a web view

Affan Salman14:01:53

This is cool, @U47G49KHQ! Adding to your point about the power of this visualization engine, the vega-lite high-level grammar is also nice and useful so good choice there. Thanks for sharing! Appreciate the note about the current limitations but this is really promising.