You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The distinction between groups and primitives (or "simple" and "complex" properties as the docs call them) always confuses newbies, and is the source of many hard to detect bugs. It is particularly confusing when rendering existing data on a template or using mv-value, since one often uses expressions instead of properties, which don't trigger the group recognition heuristic. It is also confusing when one renders objects on primitives, and expects them to function like groups. Possibly the most notorious case is dynamic datalists and <select> menus: <option mv-value="myCollection" mv-multiple value="[id]">[name]</option> is a primitive because there are no child properties, but should actually be a group).
Furthermore, groups create scopes in Mavo expressions and primitives don't, unless they are also collection items. Not only is this confusing, but it also doesn't serve every use case: One typically expects $this on a primitive to refer to the primitive, not its containing scope.
These should be one and the same: Mavo.Property, Mavo.Value or some such. Both should be able to have child properties and an assigned value.
Done correctly, this shouldn't be much of a breaking change, but it may still break some use cases that depend on internals.
The text was updated successfully, but these errors were encountered:
By default, if there is no associated attribute, having children prevents the node from also having a primitive value. Using it as such in expressions will output a serialization of the object.
Adding a child property="$value" defines its primitive value to be that property
Issue: Does the object literal returned when its used as an object contain $value?
The distinction between groups and primitives (or "simple" and "complex" properties as the docs call them) always confuses newbies, and is the source of many hard to detect bugs. It is particularly confusing when rendering existing data on a template or using
mv-value
, since one often uses expressions instead of properties, which don't trigger the group recognition heuristic. It is also confusing when one renders objects on primitives, and expects them to function like groups. Possibly the most notorious case is dynamic datalists and<select>
menus:<option mv-value="myCollection" mv-multiple value="[id]">[name]</option>
is a primitive because there are no child properties, but should actually be a group).Furthermore, groups create scopes in Mavo expressions and primitives don't, unless they are also collection items. Not only is this confusing, but it also doesn't serve every use case: One typically expects
$this
on a primitive to refer to the primitive, not its containing scope.These should be one and the same:
Mavo.Property
,Mavo.Value
or some such. Both should be able to have child properties and an assigned value.Done correctly, this shouldn't be much of a breaking change, but it may still break some use cases that depend on internals.
The text was updated successfully, but these errors were encountered: