And the include keys are: ["properties.0.value", "properties.3.value"]. This is
unacceptably brittle because the array order is now important. If the json is sourced
from an a 3rd party (and order can not be enforced, or new props are added) the
include key config is broken. It also destroys readability, it is no longer clear
why props 0 & 3 require translation.
Solution
Introduce a sibling test, making the key config:
["properties.#.value(name=title|description)"]
The code to support this is a bit dense but the resulting config is fairly
simple. The order dependency is removed and config self-documentation is restored.
Problem
When the json is pretty, it looks like:
And the include keys are easy:
["properties.title", "properties.description"]
.When the json is cruel it looks like:
And the include keys are:
["properties.0.value", "properties.3.value"]
. This is unacceptably brittle because the array order is now important. If the json is sourced from an a 3rd party (and order can not be enforced, or new props are added) the include key config is broken. It also destroys readability, it is no longer clear why props 0 & 3 require translation.Solution
Introduce a sibling test, making the key config:
["properties.#.value(name=title|description)"]
The code to support this is a bit dense but the resulting config is fairly simple. The order dependency is removed and config self-documentation is restored.
ping @imorrison