Create the Prop Decorator

[Inkdpixels]

As noted in reduct/nitpick#1 and discussed on monday, we should add the Prop decorator in this repository. This should as well be part of the 2.0.0 release, since it is a breaking change and I don't want major releases every 2 weeks . 👺

The Prop-Decorator should have the following functionality.

• Get the propValue out of the passedProps/Elements Dataset/DefaultProps.
• Expose an evaluation API
• Set the result if the evaluation result is truthy.

[Inkdpixels]

Don't mind me - Just noting some stuff:

I've messed around with decorators this evening, and babel doesn't allow decorators to be applied on Class constructors. So we need either a) apply the decorators 'outside' of the class or b) create a second verbose initialize method on which the decorators can be applied on.

Anyway, I worked a bit more on the API proposal:

import { Component, Prop } from '@reduct/component';
import { isNumber } from '@reduct/nitpick';

@Prop('myProp').validate(isNumber) // Requires an function as a parameter which can validate and correct the prop.
@Prop('myObjectProp').is('string') // Requires a) a string which will be used in a typeof comparison -  or b) a fixed value on which the propValue will be compared to.
class FooComponent extends component.Component {
    constructor(el, props) {
        super(el, props);
    }
}

[Inkdpixels]

Pushed a first API draft of the @prop decorator, which can be used e.g.:

import { Component, Prop } from '@reduct/component';

function numberProcessor(value) {
    const expected = 'number';
    let is = typeof value;

    if(is !== expected) {
        value = Math.abs(value);
    }

    is = typeof value;

    return {
        expected,
        value,
        is
    };
}

@Prop('myProp').is('string')
@Prop('withoutExplicitType').is('434234')
@Prop('processedProp').is(numberProcessor)
class MyComponent extends Component {
    constructor(el, props) {
        super(el, props);
    }
}

[Inkdpixels]

As discussed yesterday:

• The Prop decorator should automatically convert the propValue into the primary js types.
• The API is alright and will stay with the .is method.
• Processors will only modiffy the value and should, if needed, throw errors on its own. Therefore the processor will only return the modified value.
• In the future we will strive into a more complex API for async properties. The proposed API for that is isAsync.and.is().
• The decorator should only be applied on ES7 class properties(proposal)

[Inkdpixels]

Alright, the @prop decorator will now transform the propValue into the requested primitive, if necessary. The leaner processor approach is also implemented. I've stopped now because of the following:

• I've discovered that with the current approach the props itself aren't accessible in the constructor or methods that get called within it, which totally makes sense since the decorator creates the instance and sets the prop afterwards. This breaks the lifecycle of props and is unwanted.
• The leftover task for modifying the decorator to only work on ES7 class properties could be done, but it's impossible to access the instance itself in this approach. A problem which @akoenig already solved with the @component decorator here https://github.com/akoenig/lightfold/blob/master/lib/Decorators/Component.js.

So basically the @prop decorator has a dependency to the @component decorator, thats why I would suggest to move the @prop decorator into the same repository as the @component decorator.

To go along with this, I would also re-evaluate the placement of the @component decorator, as I would like to have the Prop and Component functionality in the same place, and placing both decorators into the glue/framework package would totally reduce the functionality/justification of this package. More or less the component package only makes sense with both decorators in combination I think.

So yeah - I think all three things should be delivered in the same package - The 2.0.0 is still in development, so we should discuss this.

Update:
I've forgotten that we already agreed on merging the lightfold decorators into the component package.

What do you think @grebaldi @akoenig ?

[Inkdpixels]

Note for @akoenig - I've implemented the @component decorator in v3.0.0, but without the @prop decorator since it was too much magic wizardry going on there.

Since this wont be a breaking change, and we still can confidently use the props via passing them to the decorator itself or using static properties on the class, we should add the @prop decorator later on. (Could be a minor push for the version)