Display real type information in the State view instead of always "Object" #776
Conversation
|
@clbond, thanks for your PR! By analyzing the history of the files in this pull request, we identified @sumitarora and @xorgy to be potential reviewers. |
|
@clbond I am assuming we do not display primitives types like string or number because there is no constructor property? |
|
@igor-ka We display primitive types using |
|
@clbond yes i understand, I am wondering if it makes sense to display both the (primitive) type as well as let users edit them. It seems like an overkill at first thought but i am wondering what you think about this? |
Object metadata cannot be based on paths, has to be based on reference, because the same object can appear at multiple paths - Luckily our serializer retains object references across serializations, so this can work for us
clbond
force-pushed
the
display-type-info
branch
from
0be73bc
to
58743ed
Compare
|
@igor-ka I had to add a bit of code to this PR because the way I did metadata is a bit wrong. I was creating a map of Path -> Metadata, but of course an object can appear at multiple paths, in which case the metadata was wrong. So I removed the md5 package and all the path hashing code and replaced it with object references. Our serializer maintains object references across serialization (if the same object appears twice, it will use the same instance), so now the metadata system relies on object references instead of paths when determining what decorators to apply to an object. Sorry if this is confusing ... it's a confusing problem |
cannot store component metadata keyed off values, because oftentimes those values are scalars that are not unique keys that can be used in a map. So now we store the component instance as the map key and then retain a list of all properties and their metadata.
|
OK, I fixed the case I discussed above. Paths are no longer used as keys for the metadata structure. Additionally, we can't store object values as component metadata keys because oftentimes those values are scalar and not unique. So we use the component instance itself as the map key and then store a list of properties and their metadata and associate those with the component. This works across all use cases, across circular references, duplicate references, deep nesting of component references, etc. I am confident in this fix. |
Now we retain the name of the type across backend->frontend serialization so that we can display the real object type in the "State" view. See:
Resolves: #775