nbShow for images and tables

[pietroppeter]

we should have a dedicated command nbShow whose behaviour will depend on the type of object is applied.

For example:

• when applied to a ggplot, it should show the image (would it be possible/advisable to save as svg and incorporate directly in html?)
• when applied to a dataframe, it should print a nice table

this should be in some nimib/show module that should uses when compiles(import ggplotnim) or similar mechanism not to introduce additional dependencies.

I plan to do this after #24 (hopefully I will start soon working on that, likely starting from scratch)

[HugoGranstrom]

this should be in some nimib/show module that should uses when compiles(import ggplotnim) or similar mechanism not to introduce additional dependencies.

So it would only work for types that are officially supported by nimib? I don't have full understanding of how this works, but wouldn't something like this perhaps work?

template nbShow(t: untyped) =
	t.nbShowApi(nbDoc)

proc nbShowApi(m: MyCustomType, nb: NbDoc) =
	# Logic here

All types which implement nbShowApi are then supported. There might be aspects I'm missing of course which require tight nimib integration 😄

[pietroppeter]

Still too early for me to understand how it will be for a custom type, but there will be some mechanism like the one you suggest to make this something that any custom type can implement.

I do think though that for each nbShow there might be custom parameters (e.g. max rows and max columns for a table, caption for a plot, ...).

[HugoGranstrom]

I do think though that for each nbShow there might be custom parameters (e.g. max rows and max columns for a table, caption for a plot, ...).

That's a very good point! Didn't think about that.

[pietroppeter]

have been thinking about how this could be implemented, here I describe a possible implementation:

1. change partial for nbCode from

nb.partials["nbCode"]= """
{{>nbCodeSource}}
{{>nbCodeOutput}}
{{>nbCodeHtmlOutputs}}
"""
nb.partials["nbCodeHtmlOutputs"]= """
{{#htmls}}{{.}}{{/htmls}}
"""

2. we provide a addHtml(blk: var NbBlock, html: string) function that adds a generic html string to current block (initializes sequence htmls if not present.

3. a generic nbShow[T](obj: T) template is provided that calls a T.toHtml function and uses addHtml to add output to current block.

4. for every specific type that ones want to show, you need to implement toHtml(o: MyType): string =

5. (optional) we might be able to pass some untyped varargs argument to nbShow that are passed as is to toHtml to implement options (like maxRows, maxCols, ...). If we are not able than to use non default of optional arguments one needs also to specialize nbShow and pass arguments to toHtml (a macro could be supplied to do that automatically).

what is nice about the above is that for every new type you just need to add a toHtml function that might be anyway useful besides nimib. Also I liked the use of addHtml that hides the implementation detail of how the partials are handled. For example if in a next version of nimib we add a partial field to the block object (so that you can customize the single block), then the addHtml will change its implementation but not the rest.

Note that in the above we assume that all html outputs produced by nbShow are shown after the capture stdout outputs. It would be complex to do otherwise and not worth the effort IMO.

[HugoGranstrom]

This API looks really clean, I really like the toHtml idea 😁 the only nitpick I have is that nbShow and --nbShow could be a bit confusing for those uninitiated. Not sure what else to call it though 🤔

[pietroppeter]

ah yes, all names are up for changes:

• nbShow: an alternative could be nbView
• nbCodeHtmlOutputs: why specific to nbCode blocks? maybe just nbHtmlOutputs? or maybe we lose the nb prefix since it is not supposed to be tied to a specific block? e.g. htmlChunks?
• htmls: as name of field in the context/data. are there better options here?

[HugoGranstrom]

Here are my 10 cent:

• nbView isn't bad. Throwing nbPretty into the mix as well.
• I think the nb prefix is suitable still, nbHtmlOutputs sounds fine to me.
• I actually think htmlChunks fits better for this than the above. htmls feels a bit too vague of a name and something that a user might create in their own contexts/partials.

[pietroppeter]

Inflation really is ramping up 😜

• Yeah to be honest I still think nbShow is the better option (should we rename the runtime option to nbOpen?)
• agree on htmlChunks but I was trying to avoid 🙄 the decision whether to use html_chunks (as we do for many theme related things) or htmlChunks. Do we have a style insensitive json?

[HugoGranstrom]

:rofl: That's what I get when I don't know your idioms properly...

• Fair enough, npOpen is more logical for the runtime option actually :+1:
• Hehe, I'd go with the convention we currently have when in doubt. Style insensitive json doesn't sound like something someone would want :sweat_smile: