Allow someone to access definitions

[matthewp]

Tools that need to know the definitions for a DefineMap need to access MyMap.prototype._define.definitions. It would be good if this was exposed in a better / more public way. Maybe something like:

define.getOwnPropertyDefinitions(MyMap); // -> defns

[BigAB]

I would rather define.getOwnPropertyDefinitions() just return whatever was passed into .extend, methods and whatnot (it would be nice to hold onto the static defines somewhere as well), so that plugins and what not can look into how a DefineMap was defined, and make decisions from there.

I know I would like it for react-view-model

[matthewp]

Is there a can-reflect way to do this yet @phillipskevin @justinbmeyer ?

[phillipskevin]

canReflect.getOwnEnumerableKeys will give you the keys from _define.definitions and also any keys you pass to the constructor.

There isn't a way to get all of the definitions themselves.

[justinbmeyer]

This is probably a discussion for can-reflect. can-reflect should have APIs that make types inspect-able.

[matthewp]

I kind of agree, but also am not sure if this is metadata that anything other than can-define would have. It's certainly not generic in the way that get/set on/off are.

[justinbmeyer]

So there is already a defineInstanceKey that supports a limited set of args (basically what definePropery supports). can-connect needs it. Define, map, observe, simple map all implement. We can give some basic inspection results. If a prop exists, get back what was used to define it.

[DesignByOnyx]

I wanted to chime in here as I am wanting to build forms dynamically from a DefineMap's prop definitions. I am able to access Thing.prototype._define, but the information therein is not the same as what I used to define the object. For example, if I use name: { type: 'string' } in the definition, then _define.definitions.name.type is a function that takes the value and converts it to the correct type. There's no way to see that the "name" field is of type "string".

In the mean time, I will be exporting my prop definitions separately, but it would be nice to be able to access the raw definitions somehow.

[justinbmeyer]

Generally speaking, you don’t want the raw definitions. This is because there are so many rules for figuring out the final definitions. What you want are final definitions you can make sense of.

Sent from my iPhone

On Feb 6, 2018, at 10:32 AM, Ryan Wheale [email protected] wrote:

I wanted to chime in here as I am wanting to build forms dynamically from a DefineMap's prop definitions. I am able to access Thing.prototype._define, but the information therein is not the same as what I used to define the object. For example, if I use name: { type: 'string' } in the definition, then _define.definitions.name.type is a function that takes the value and converts it to the correct type. There's no way to see that the "name" field is of type "string".

In the mean time, I will be exporting my prop definitions separately, but it would be nice to be able to access the raw definitions somehow.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[DesignByOnyx]

I'd want that for a super generic drop-in form builder, but for our immediate case we don't mind using a stricter policy for using straightforward prop definitions. There may be 10 ways to define a prop, we're going to pick one and use it - mainly requiring static [Tt]ype values and optional static/function [Dd]efault values.

[justinbmeyer]

This is partially closed by canReflect.getSchema()