Fork me on GitHub
#portal
<
2023-03-13
>
rschmukler16:03:15

Is there any way to specify initial render depth with metadata on an item?

👀 2
djblue19:03:23

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.

djblue19:03:00

Another option that has been mentioned previously is allowing toggle expand recursively

rschmukler20:03:41

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)

rschmukler00:03:28

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.

djblue01:03:16

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

djblue01:03:53

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

rschmukler01:03:02

{:portal.viewer/max-depth 5}

2
djblue01:03:20

Maybe

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

rschmukler01:03:42

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

djblue01:03:07

Kinda, in that they recurse via the inspector

djblue01:03:25

We could also go a little crazy and do:

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

djblue01:03:46

This would open the door to configure the entire subtree differently

rschmukler01:03:47

I saw (via github code search) that it was theme based, but to me that seems a bit like an implementation detail

rschmukler01:03:55

That's interesting

rschmukler01:03:03

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

djblue01:03:26

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

djblue01:03:07

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

djblue01:03:25

Like pass these options to the current viewer and every viewer is usually wrapped via the inspector

rschmukler01:03:35

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

👍 2
rschmukler01:03:10

:portal.viewer/options is good - I would consider whether things could be consolidated a bit into there

2
rschmukler01:03:44

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

rschmukler01:03:09

{:portal.viewer/options
  {:portal.viewer.table/columns [:a :b :c]}}

rschmukler01:03:26

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

rschmukler01:03:22

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

👍 2
djblue01:03:51

True, although I like being able to specify different options for different viewers independently

rschmukler01:03:52

Again, no real strong opinions here. I think solid documentation can allow for any decision

rschmukler01:03:09

Yeah that's very true

djblue01:03:52

That's kinda why things are {viewer options-map ...} although the :portal.viewer/for broke that a little

djblue01:03:00

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

rschmukler01:03:31

You could do

rschmukler01:03:46

and leave :portal.viewer reserved for viewers

2
rschmukler01:03:55

Same then for :portal/options

djblue01:03:51

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

rschmukler01:03:37

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

❤️ 2