Vega-lite: Set scale to null (formerly "Specify Color value in Data")

[tyre]

Our users customize colors for given priorities. We would like to use this as the color for a bar chart.

For example:

{
  "data": {
    "values": [
      {"count": 7, "color": "#29d908", "name": "High"}
    ]
  }
}

We would want to specify that the "color" field be used as the color.

[kanitw]

Thanks for reporting.

@domoritz. I think the right solution for this is to support scale.type = "identity", which is equivalent to not applying scale property in the output Vega marks?

[kanitw]

Alternatively, specifying scale = null could be another option. (undefined = default, null = no value).

[domoritz]

I think an identity scale makes sense.

I think "undefined = default, null = no value" could be a bit difficult to support for other languages such as python.

[kanitw]

I like identity more for this case. That said:

I think "undefined = default, null = no value" could be a bit difficult to support for other languages such as python.

We still have to solve #1285. In that case, we can treat None as null. undefined is undefined.

[domoritz]

Python only has None. There is no undefined (unless you mean actually not defined).

[kanitw]

you mean actually not defined

Yes. Notice the absense of code syntax. ;)

[domoritz]

Yes. Notice the absense of code syntax. ;)

Wait, you edited the comment and swapped what is code and what is not :-P

[tyre]

Thank you for the quick response. So this would result in something like?

color: {
  field: "color",
  scale: { type: "identity" }
}

[kanitw]

@tyre. Exactly.

[kanitw]

Another proposal that would be more consistent with how axis and legend works are actually:

color: {
   field: 'color', 
   scale: false | null  
}

Plus, doing the scale.type="identity" like above might cause D3-pro to think that we produce an identity scale. In this case, we should just not produce scale and output raw value directly so this syntax is actually better.

To be consistent with current version, this should be false, but going forward I think null makes schema cleaner (see my comment in #1377 and see relevant #1285).

@domoritz

[domoritz]

As I said in other places, I'm against introducing null until we figure out a better way to handle auto.

[kanitw]

For the record, @domoritz and I kinda agree to 'null' approach in a slack conversation.

[kanitw]

Let's put this on hold as it might cause conflict with @ayush29feb's planned changes.

[tyre]

For the record—and this is somewhat off-topic so forgive me—this is a fantastic example of open source collaboration and strong maintainership. 💯 💯 💯

[kanitw]

This will be handled as part of #1408.

The schema will be updated as part of #1384 whenever TS releases a new version.