RFC: Create attrTypes to describe the interface of a component

[jonathanKingston]

...nent

Rendered

[mmun]

I like this. It can land after 2.0 and I'm interested to see a PR after glimmer lands.

[mmun]

Some prior art: http://facebook.github.io/react/docs/reusable-components.html#prop-validation

[locks]

Shouldn't it be allowedAttributes instead of allowedProperties?

[mmun]

Yes. Still not a fan of it though. A list of allowed attributes is not very expressive. I prefer React's approach which lets you specify further constraints.

[jonathanKingston]

@mmun I wanted to put in types however I didn't want the change to be too big initially without there being an interest for it.

The other thing is I was considering using the Ember data attribute types for declaring the data types, what do you think. The only other alternative I can see would be using Ember.typeOf results.

I like the react way of doing things.

@locks I did have originally two separate interfaces, where by you could specify the inbound attributes and the outbound properties. I think the outbound component to the components template is more important however attributes would probably chime more into glimmer I suspect.

[jonathanKingston]

@mmun an alternative to the two separate interfaces would be having the ability to specify an attribute/property as private/protected.

My only worry with this is it is getting complex enough that I would personally prefer the computed property work to be expressed within this data structure.
So the new getters and setters syntax would be incorporated, similar to:

  myThing: Ember.computed('other', {
    type: 'string',
    private: true,
    get: function () {...},
    set: function () {...},
  })

[mmun]

@jonathanKingston I don't think it should be expressed as a CP. I was thinking of putting it on attrTypes, not unlike React. Something like

import { attrType } from "ember-component";

return Ember.Component.extend({
  attrTypes: {
    checked: attrType({ boolean: true })
  }
});

[jonathanKingston]

@mmun I think there are two use cases here if both are important is a different story.

Template usage:

<my-component thing="element" thing1="element" ></my-component>
{{!-- thing1 would be ignored here --}}

my-component.js

import Ember from 'ember';
var attr = Ember.Component.attr;
export default Ember.Component.extend({
  attributeTypes: {
    thing: attr('string')
  },
  thing2: 'my thing',
  exposedProperties: ['thing']
});

my-component.hbs

  {{thing}} {{!-- element --}}
  {{thing1}} {{!-- '' --}}
  {{thing2}} {{!-- '' --}}

The ability to accept attributes and what gets exposed are distinct, I don't thing exposedProperties would need types as they come from the JavaScript internals.
I think exposedProperties is a better name for that use. 'permittedAttributes', 'allowedAttributes' or 'attributeTypes' is a better name for inboud.

The only other alternative is the parity with ember data which would cater for both use cases.

[mixonic]

+1 for attrTypes

[jonathanKingston]

Working on the change now.

[mmun]

@jonathanKingston might wanna wait until after glimmer lands because it will massive simplify how attributes are propagated through a template.

[jonathanKingston]

@mmun I was just writing up the changes that were discussed here, no real effort being expended:

jonathanKingston@5ddcdac

I will look over the latest changes there and see how that impacts this.

[jonathanKingston]

@mmun one other thing that I have been toying with is the fact that it is very hard to get multiple properties into a component, much like you can for the link-to helper.

This could be resolved with this issue in several ways, however here is the most in keeping that I can think of right now:

Add in a serializedArray type to deserialize the type into an array:

<component-name models=(serializeArray model model2) >Text</component-name>

The serializeArray would work similar to JSON.stringify([model, ...]) however implementation doesn't matter so long as the attr type matches.

In the component:

export default Ember.Component.extend({
  attrTypes: {
    'models': attr('serializedArray'),
  },
  url: function () {
    return 'me/' + models.join('/');
  }.property('models')
});

[jonathanKingston]

I forgot to update this to mention that @mixonic resolved my last comment in:
https://github.com/emberjs/rfcs/blob/master/active/0000-improved-actions.md

An attribute type would still be required for this data type however.

[igorT]

👍 on more complex validators.
Those would allow us to make the attrTypes work seamlessly between Ember Data's attrs and relationships and component's attrTypes

[tomdale]

We would like to explore using JavaScript typesystems (e.g. TypeScript, Flow) rather than adding our own ad-hoc component type checking at runtime. If we do end up doing runtime type checks, we would like to explore using decorator syntax rather than attrTypes.

To move this forward, we would like to see it implemented as an addon that can be vetted in the community before it is supported in core.

[jonathanKingston]

@tomdale thank you for reviewing this also.

I wasn't sure if that would be a direction that would be adopted by ECMA so I assumed that would be a no-go. The decorators solution certainly seems a viable option certainly.

Is this the direction Ember Data is going to take also?