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
Currently, deserialization (i.e., syncing from an attribute string to a typed property) will only work on “serializable types” — declared as the types Boolean, String, and Number. Other types will simply not be synced. Similar story for serialization (aka reflection, this is when a typed property is serialized to a string and set as an attribute).
While real-world use-cases for more complex deserialization / serialization are few and far between — we may choose to be less restrictive about this functionality in the future.
Proposal
Expose new serialize and deserialize options in the property block:
// Toy example.classMyElementextendsXElement{staticgetproperties(){return{child: {type: HTMLElement,// Allow deserialization of stringified values via document.createdeserialize: value=>{try{returndocument.create(value);}catch(error){returnnull;}},serialize: value=>value?.localName,reflect: true,},};}}
Rationale
Allow deserialization of compound types
Perhaps there are reasons that you cannot use property binding for certain things. Rather than impede developer flows, we could allow authors to get around this road bump if they really want.
classMyElementextendsXElement{staticgetproperties(){return{object: {type: Object,// Allow deserialization of stringified values via JSON.parse.deserialize: value=>JSON.parse(value),},};}}
We recently shipped a change to address #147 which deserializes the empty string to NaN when syncing to Number-type properties from attributes. This behavior is likely the “right” default, but authors may want to override this and we shouldn’t get in their way. E.g., they may want 0 instead of NaN:
classMyElementextendsXElement{staticgetproperties(){return{number: {type: Number,// Rather than deserialize `'' >> NaN`, deserialize as `'' >> 0`.deserialize: value=>Number(value),}};}}
The text was updated successfully, but these errors were encountered:
Currently, deserialization (i.e., syncing from an attribute string to a typed property) will only work on “serializable types” — declared as the types
Boolean
,String
, andNumber
. Other types will simply not be synced. Similar story for serialization (aka reflection, this is when a typed property is serialized to a string and set as an attribute).While real-world use-cases for more complex deserialization / serialization are few and far between — we may choose to be less restrictive about this functionality in the future.
Proposal
Expose new
serialize
anddeserialize
options in the property block:Rationale
Allow deserialization of compound types
Perhaps there are reasons that you cannot use property binding for certain things. Rather than impede developer flows, we could allow authors to get around this road bump if they really want.
Change default serialization / deserialization behavior
We recently shipped a change to address #147 which deserializes the empty string to
NaN
when syncing toNumber
-type properties from attributes. This behavior is likely the “right” default, but authors may want to override this and we shouldn’t get in their way. E.g., they may want0
instead ofNaN
:The text was updated successfully, but these errors were encountered: