krakenjs / zoid

Cross domain components
Apache License 2.0
2.03k stars 248 forks source link

Should we allow React-style arbitrary props? [i.e. not require props to be defined up-front?] #63

Closed bluepnume closed 7 years ago

bluepnume commented 7 years ago

So instead of

var MyLoginComponent = xcomponent.create({

    // The html tag used to render my component

    tag: 'my-login-component',

    // The url that will be loaded in the iframe or popup, when someone includes my component on their page

    url: 'http://www.my-site.com/my-login-component',

    // The size of the component on their page

    dimensions: {
        width: 400,
        height: 200
    },

    // The properties they can (or must) pass down to my component

    props: {

        prefilledEmail: {
            type: 'string',
            required: false
        },

        onLogin: {
            type: 'function',
            required: true
        }
    }
});

you could write

var MyLoginComponent = xcomponent.create({

    // The html tag used to render my component

    tag: 'my-login-component',

    // The url that will be loaded in the iframe or popup, when someone includes my component on their page

    url: 'http://www.my-site.com/my-login-component',

    // The size of the component on their page

    dimensions: {
        width: 400,
        height: 200
    }
});

then just pass down whatever props you want? Defining them up-front is nice for validation, self-documentation, etc. but not strictly necessary for xcomponent to work. So it's possible to make this optional in future.

Leaving this open for discussion.

jmc265 commented 7 years ago

I think we shouldn't have to define the properties up front. To make things robust I am going to check the properties I receive anyway, including checking to see if they are there or not. I can do my own validation at that point to make sure the ones I require are present and I can also do any type checking and any further domain specific checks I need to. So maybe what we might need here is, instead of specification of properties, is a standardised way of returning errors to the parent? That will include validation errors on the properties.

bluepnume commented 7 years ago

Hey thanks for weighing in @jmc265. Some good points.

On the error handling thing, this is standardized like so, today, with a built-in onError prop, that will be called in case of any rendering or other errors:

Foo.render({

    onError: function() { ... }

}, '#container');

Errors can be triggered from the child by doing:

window.xchild.error(err);

Which triggers that callback and destroys the component. For more specific error handlers, it's possible just to define whatever prop you need and pass it down.

Sorry half of this stuff isn't documented yet. Now people are starting to use this library I need to spend a few hours throwing together a half-decent set of API docs. In the mean time please keep asking away! :)

bluepnume commented 7 years ago

Alright! This is now done, and published, and simplifies building xcomponents for the first time massively. Now all you need is a url and a tag.