Generalized mappings / Top-level function

[edemaine]

Does it make sense for top-level function to be (key) -> -> ...@ is context...? Why not (key) -> ...@ is context...? Or, for that matter, just -> ...@ is context, @key is key...?

The new proposed generalized form of mapping can be

• Preact VDOM (modern way to write SVG),
• a raw string (for the old-school way of writing SVG),
• a filename string (as a shortcut for including images or SVG from files),
• an object (dictionary, as shorthand for (key) -> obj[key]),
• a Map as a modern alternative to object,
• an array (for multiple symbols Keys expanding to multiple <symbol>s #33), or
• a function whose return value can be any of these, recursively.
  • Functions would be called with arguments (key, context), and for backward compatibility, with this set to the context as well.

This would provide backward compatibility with -> -> ... and X: -> ..., but would remove the need for the double ->. It would also allow interesting/weird things like

->
  if @i == 0  # use different object mapping on first row
    x: ...
    y: ...
  else
    x: ...
    y: ...

• new Mapping takes one of the above as an argument
• Mapping.prototype.lookup recursively evaluates a symbol given context
• Require object or Map or function at top level (string/VDOM/array, which don't depend on key at all, allowed only at deeper levels).

Static Symbols

The one thing this approach would lose is a way to express static symbols defined by a function. Strings and Preact VDOM directly in an object would still be static. But I don't think functions that return things other than functions is too common in practice, because it isn't very easy. And I hope that rerunning in that case won't cost too much in performance. But I think we could replace it with:

• svgtiler.static(foo) could wrap foo in a declaration that its contents do not depend on context at all. This would make it easier to specify when desired for efficiency, also in a conditional or something. And it would work to specify some parts of an array are static while others are not. [This is the equivalent of untrack in Solid.]
• context.amStatic() would be another way within a function, but this doesn't let us distinguish individual items in an array.

More broadly, fine-grained reactivity is a better solution if we want to optimize further than the static/dynamic line.

Needs to be paired with #50.

[edemaine]

I think another way to phrase this is that, for js/coffee mappings defined by a function, it'd be natural to think of everything as a universal dynamic symbol. This requires refactoring the "symbol cache" from individual DynamicSymbols to... The Mapping? The renderer? This has the added advantage of detecting duplicate symbols with different keys.

[moved this to #50]