Clojurians Log v2

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}}

The config has been per viewer, but this one feels more universal 🤔

{:portal.viewer/max-depth 5}

Maybe

{:portal.viewer/inspector {:max-depth 5}}

I would consider not limiting to the inspector since the table and tree also can have depth, right?

Kinda, in that they recurse via the inspector

We could also go a little crazy and do:

{:portal.viewer/theme {:max-depth 5}}

This would open the door to configure the entire subtree differently

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

True

I don't have too much opinion on it, to be honest

That's fair, but what are the other things you might want to be able to drive?

I think :portal.viewer/options might be a little less theme specific

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

Now we can't have a for viewer be configurable lol

😄

You could do

:portal/for

and leave :portal.viewer reserved for viewers

Same then for :portal/options

Okay, I'll play with some of these. Thanks for the help 🙏

Thank you for the responses and the consideration 🙏 . Portal has become a daily tool for me. The clojure.core.protocols/nav integration is chef_kiss