Should components define their 'arguments'?

[caolan]

I like to think of components as functions accepting named arguments (e.g. title="{{ article.title }}"). Should the <template data-tagname="my-template"> tag also require/allow you to define the context it expects to receive?

[benzen]

In the spirit of a couple of weeks project.
I think that support for this should be optional. A really great addition for the users still an option.

Since it should be easily ignored by implementation, let’s make it a comment inside the component definition, first comment node inside a template. Kind of a python docstring.

Then if template engine support it it will generate validation code for the context data.

Do you have syntax in mind ?
Should be look at Jason schema for this ?

[caolan]

Using a comment to annotate components like Python docstrings is an interesting idea, hadn't thought of that. I was assuming we'd use some attribute on the <template> tag, something like:

<template data-tagname="my-component" data-required="name amount type">

...which in that case would mean <my-component> expects to at least have name, amount and type attributes.

[benzen]

Using only a tag attribute limit your power of expression. For exemple you can’t define if name is a string or an array Doesn’t mean that we have to use all the freedom we have but let’s keep the options open Benjamin Dreux

…

Le 5 févr. 2018 à 06:20, Caolan McMahon ***@***.***> a écrit : Using a comment to annotate components like Python docstrings is an interesting idea, hadn't thought of that. I was assuming we'd use some attribute on the <template> tag, something like: <template data-tagname="my-component" data-required="name amount type"> ...which in that case would mean <my-component> expects to at least have name, amount and type attributes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[caolan]

Comments would be more flexible. However, we wouldn't be able to provide type warnings at template compile time anyway (as we won't know the type of the data until runtime). Since I'd like us to avoid runtime errors in the templating language (but give as many useful compile-time errors as possible), I don't think we'd gain much from the extra flexibility.

Parsing HTML comments as something like JSDoc would also require an additional parser (assuming it's more detailed than the attribute example I gave). This would complicate implementations a bit. Which may not be a huge problem server-side, but could bloat the client-side library.

On the positive side you could add more detailed descriptions for each expected attribute when using HTML comments. Though I suppose there's nothing stopping you from doing that now.

[benzen]

As i see it, the context expectation should be optional.
In my opinion there is two fold to this optionality:

• When you write you template
• When you use your template

At writing time, you can choose to write down thoses expectations.
When using you templates, you can decide to enable or not the checking of the expectations.

As a reference we could check out: https://reactjs.org/docs/typechecking-with-proptypes.html

In the server side, as you said, nobody care if the module is bigger.
On the client side, I could decide to exclude the expectation checker from my build.
(Or don't include the magery-type-checker.js script in my page.

On my app what i'd like to type/check is for exemple:
in my context i have a property named "todos", the value is a list of object that include for each a name (a string) and a done attribute (a boolean).

Keeping thoses expectation next to the template and close to to the template would help in keep the state of the app in a clean state.