This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-13
Channels
- # announcements (4)
- # babashka (1)
- # beginners (124)
- # calva (5)
- # cider (3)
- # clara (3)
- # clerk (5)
- # clj-commons (14)
- # cljdoc (12)
- # cljs-dev (14)
- # clojure (43)
- # clojure-austin (23)
- # clojure-europe (55)
- # clojure-nl (1)
- # clojure-norway (11)
- # clojure-uk (2)
- # clojurescript (34)
- # conjure (1)
- # cursive (1)
- # data-science (28)
- # datomic (3)
- # fulcro (20)
- # gratitude (2)
- # hyperfiddle (6)
- # introduce-yourself (1)
- # jobs (5)
- # lsp (56)
- # malli (5)
- # membrane (7)
- # mount (5)
- # off-topic (16)
- # polylith (39)
- # portal (38)
- # practicalli (1)
- # rdf (1)
- # re-frame (8)
- # releases (8)
- # remote-jobs (4)
- # shadow-cljs (49)
- # sql (1)
- # xtdb (36)
Not currently, although this question does come up from time to time. What expectations would you have if portal supported that metadata? Portal does have the ability to https://github.com/djblue/portal/blob/master/src/portal/ui/theme.cljs#L19 but it isn't exposed to users yet.
Another option that has been mentioned previously is allowing toggle expand recursively
I would love to see an option to either pass in the max depth (like you pass in the theme) option to p/open or be able to pass it as metadata (eg. The depth it will render the items children to)
re. toggle expand universally, that would be nice but I think the metadata is much more powerful (as I personally have my own helper functions for things like rendering to tables, etc) - the toggle means interfacing with the UI (unless portal exposes it via the library) while the metadata means my functions can just do it automatically.
Supporting render depth via metadata first works for me, what are you thinking it would look like? Currently, here is some of the metadata portal understand:
{:portal.viewer/table {:columns [:a :b :c]}
:portal.viewer/for
{:code :portal.viewer/code
:time :portal.viewer/relative-time}
:portal.viewer/code {:language :clojure}}
I would consider not limiting to the inspector
since the table
and tree
also can have depth, right?
I saw (via github code search) that it was theme based, but to me that seems a bit like an implementation detail
That's interesting
I don't have too much opinion on it, to be honest
Like pass these options to the current viewer and every viewer is usually wrapped via the inspector
The reason I lean toward root is just that I think of the nested maps as config for the individual inspectors. As a new user, if you don't know that a sub-inspector recursively invokes a new instance of the :portal.viewer/inspector
then you might think that the config only applies to the :portal.viewer/inspector
and not things like tables, etc
:portal.viewer/options
is good - I would consider whether things could be consolidated a bit into there
ie. right now you need to know multiple different namespaced keywords, as well as the un-namespaced keys that go into those maps to be able to configure things
{:portal.viewer/options
{:portal.viewer.table/columns [:a :b :c]}}
I'm not suggesting its worth having a breaking change, just that there's a lot to unpack right now as a new user looking for this stuff
I'm also not sure that having nested maps is better than just having further namespaced keywords on the root-metadata... after all that seems the point of namespaced keywords
True, although I like being able to specify different options for different viewers independently
Again, no real strong opinions here. I think solid documentation can allow for any decision
Yeah that's very true
That's kinda why things are {viewer options-map ...}
although the :portal.viewer/for
broke that a little
You could do
:portal/for
Same then for :portal/options
Thank you for the responses and the consideration 🙏 . Portal has become a daily tool for me. The clojure.core.protocols/nav
integration is