Support for evaluating JavaScript functions for layer enabled parameter

[warpedgeoid]

Perhaps I'm missing something, but it doesn't appear that Tangram supports evaluating JavaScript functions for top-level layer parameters such as enabled. At least, I didn't see it in the source.

First, am I missing something obvious? If so, apologies for spamming the issue tracker. I'm attempting to learn my way around the Tangram source with the goal of being able to make more meaningful comments and perhaps even contributions in the future.

If this isn't supported, I would like to request support for either JS functions or some sort of syntax for defining a predicate combining multiple globals to determine whether a layer is enabled. My specific application is many layers which each have a category and sub-category, and a scene with one boolean global per category and sub-category. I need to check a two of these globals for each layer to determine whether it should be displayed.

Thanks!

[matteblair]

Your reading is correct, there currently is no support for using JavaScript in the parameters of a layer itself. There isn't a specific reason that this wasn't implemented, it just wasn't needed as badly as functions for draw parameters.

From what you've described, it sounds like you might be able to achieve what you want by nesting the sub-category layers inside the category layers:

global:
  show-category: true
  show-category-major: true
  show-category-minor: false
layers:
  category:
    data: { ... }
    enabled: global.show-category
    major:
      enabled: global.show-category-major
      ...
    minor:
      enabled: global.show-category-minor
      ...

But this wouldn't work if, say, the sub-categories had data sources as well.

Enabling JS for layer properties might be a sensible enhancement. If we implemented this with a custom syntax we could run the operation in native code, which is a big win for performance. But there's a big difference between this and other usage of JS functions, which is that layer functions would have access to much less state: no feature, no $zoom or other keywords, basically just globals. This means it would be relatively easy to cache the results of these functions. That makes me inclined to use JS, for more flexibility and consistency.

[warpedgeoid]

Our styles are very complex, hundreds of different layers coming from the same tile source, and different symbologies for the same layer but different geometry type. We're already nesting layers for display priority group (domain specific meaning); I'm not sure how we would add the extra structure needed to handle the categories. Instead, we've opted for adding a JavaScript filter to the top-level layer that checks the globals. Since the styles are generated by a Python script that reads a set of rule files, this was pretty simple to add. I went for adding a filter over setting the visible property of each draw group because I was assuming that the filter would only be evaluated once for the top-level layer while there may be many draw groups in each layer/sublayer.