Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Remove some schema mapping heuristics? #692

@LeaVerou

Description

@LeaVerou

We currently have a lot of schema mapping heuristics, only some of which are documented.

I've made a pass through the code to make a list:

  1. Singletons can be rendered on collections, they are just wrapped in an array
  2. Arrays can be rendered on singletons. If the singleton is not the root object, then the first item is rendered (and the rest are preserved, but not shown). If the singleton is the root object, then the array is rendered:
    1. on the collection with property=main
    2. If none found, on the first writable collection
    3. If none found, the first item is rendered instead, just like any other object.
  3. Superfluous properties are retained, and even reachable from expressions.
  4. Nested objects with only one property that is the same as the parent property are "unwrapped". This means that {foo: {foo: 5}} when rendered on the foo property is the same as rendering {foo: 5}.
  5. Primitives can be rendered on objects.
    1. If the object contains a property with the same name, it is rendered there.
    2. Failing that, the first writable primitive property
    3. FFS, there is even a ...scoring function!
  6. Objects can be rendered on primitives. What is rendered?
    1. If Symbol.toPrimitive exists, it is invoked and the return value is rendered.
    2. If it's a plain object, we render one of its properties on the primitive (preserving the rest):
      1. If there is only one property, we choose that
      2. If there is a property that is the same as the primitive's property, we choose that
      3. If there is a value or content property, we choose that
      4. Failing that, any property with the same datatype.
  7. Some of the rules above are not applied if the node is a helper variable, i.e. a <meta>.

As discussed with @karger, not all of these heuristics are useful, and some end up making Mavo's behavior rather unpredictable. Which ones should we drop, and which ones are useful enough to be worth their complexity?

Consider cases where we are rendering data we don't control (e.g. via an API), or the user doesn't have full sense of the data schema (like the shopping list)

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions