Attempt to clarify substitution example paragraph #18
Conversation
i.e. current 4th paragraph in section "Templates, Substitution Keys and Transformations". I think the previous version of this paragraph made sense once you understood what Hanami's doing overall, but I found it confusing the first few times that I read it. The new version is longer, but I hope spells things out for someone new to the Hanami process.
|
Let me know if this should go in a new branch, and if you want me to squash the new commit into the original. |
I revised the text after realizing that there actually are keys `:field` and (in Vega-Lite) `"field"`. I thought `:field` might just be a dummy variable for the sake of an example. I also added links to Hanami source and a Vega-Lite doc page. Maybe it's inappropriate to include these links in a section that's intended to give an overview. However, part of what's confusing is all of the layers involved (:X is value of :field, but it's a key to look up "x", which will be a default value for "field"). One doesn't have to follow the links, but maybe having the exact references available will help some readers to sort out the layers. Fixed typos created when fixing typos
| @@ -299,7 +299,7 @@ _Substitution Keys_ can be considered or thought of in two ways. They are the ke | |||
|
|
|||
| The second way of thinking about substitution keys is that they are the starting values of keys in templates. So, they represent parameterized values of keys in templates. | |||
|
|
|||
| As an example consider the following. In a template (which is a Clojure map) we might have a key `:field` with value `:X`. Here `:field` could correspond to a Vega-Lite field name, in this case "field". When we apply `hc/xform` to the template, `:field`'s value `:X` will be replaced by a new value, which comes from the current substitution map. In the default substitution map `hc/_defaults`, the key `:X` has the value of "x", so the resulting key/value pair will be `:field "x"`. | |||
| As an example consider the following. In a template (which is a Clojure map) we might have a key `:field` with value `:X` (cf. [xy-encoding template](https://github.com/jsa-aerial/hanami/blob/0dd9ac62e89ec5a5d0285cd0c0da5e2bc87b2ad0/src/cljc/aerial/hanami/templates.cljc#L84)). Here `:field` corresponds to a Vega-Lite key, ["field"](https://vega.github.io/vega-lite/docs/field.html). When we apply `hc/xform` to the template, `:field`'s value `:X` will be replaced by a new value, which comes from the current substitution map. In the default substitution map [`hc/_defaults`](https://github.com/jsa-aerial/hanami/blob/9cfa38118486fa0e139defeaa20ac3595690c8f9/src/cljc/aerial/hanami/common.cljc#L161), the key `:X` has the value of `"x"`, so the resulting key/value pair will be `:field "x"`. | |||
There was a problem hiding this comment.
Hi, thanks for thinking about this. Some of what you write I believe would communicate the intent better. I think the links here may just distract and the parenthetical note is either redundant or actually a bit misleading (the first argument to hc/xform can be any collection, eg. a vector. (hc/xform [:X :Y] :X 1 :Y "hi") => [1 "hi"]). What might be better is to not use the ':field' example at all (bringing in too many orthogonal issues), but something totally artificial. So, maybe something like
In a template we might have a field foo with value :BAR, as in {... :foo :BAR ...}. When we apply hc/xformto the template,:foo's value :BARwill be replaced by the value of:BARin the current substitution map. The value of:BARin the current substitution map could come from in line arguments, such as(hc/xform {... :foo :BAR ...} :BAR "hi" ...)or from the default substitution map if:BAR` is added there, or from template local defaults.
Or something along those lines.
There was a problem hiding this comment.
Thanks @jsa-aerial. I'll think about all of that. There are often tradeoffs between introducing new ideas and being accurate. (When I'm teaching, I sometimes tell students "What I just said isn't exactly correct, but it's close enough for now. You can take the advanced course to find out more.") I don't want to mislead, and I want to try help someone who doesn't yet have the big picture to take a step into it.
There was a problem hiding this comment.
Hi @mars0i, that's a good point about introduction vs 'detail/accuracy'. Since this is basically the reference document, I wonder if a nice way of "threading this needle" would be to have a simple introductory text as well. Or probably even the thing a new person would reach for first. That does seem like something that would be very valuable. At the moment, I am drowning in some other things (including more documentation for something else), so I don't think I would be able to get to it soon. Many thanks for these helpful ideas!
There was a problem hiding this comment.
Actually, on the 'intro' front, have you seen Kira McClean's Visualizing Data with Hanami talk from re:Clojure? It is really good - better than any I've done :-/. Hmmm, now I think of it, I should put that in the README somewhere.
There was a problem hiding this comment.
I'm not in a position to write a full intro document. Even if I had time, I don't feel I understand enough yet--I think you've seen evidence of that already. I still think I can probably come up with a version of that substitution example paragraph that will help someone get in to the ballpark without misleading, though.
(I attended Kira McClean's talk, and yes, it was very helpful, and it got me started--though for me at that point it was a lot at once. I'd had no experience at all with hanami, Vega-Lite, or clerk--which one needed to run to follow along (or with any grammar of graphics lib--I use Lattice not ggplot with R--or any notebook!). I'm sure I'd learn more if I went back and watched the video now, though, with pauses if need be.)
There was a problem hiding this comment.
Yes, that would have been a lot to onboard all at once!
(Hi - Are you open to PRs for the README file? I'm learning hanami, which
is great, by the way. I'd like to offer some suggested changes to the README
bit by bit as I study Hanami and the README further.)
i.e. this is a revision to the current 4th paragraph in section "Templates,
Substitution Keys and Transformations".
I think the previous version of this paragraph made sense once you
understood what Hanami was doing overall, but I found it confusing the
first few times that I read it. The new version is longer, but I hope that it
spells things out better for someone new to the Hanami process.