Add polyfill for <Input> and <Textarea>

[simonihmig]

Based on #72, will rebase once that is merged.

[rwjblue]

Needs a rebase I think

[simonihmig]

Rebased, but the Ember 2.12 scenario is failing. Will have to investigate...

[simonihmig]

Ok, that was a stupid mistake. Green now!

[rwjblue]

Thank you! Glad we had coverage 😄

[rwjblue]

Reading through this made me think of another issue: passing modifiers, comments, or attributes other than the specific ones we handle should issue a helpful error. I think this is also going to be an issue over in the link to one so probably could share a util or something?

[rwjblue]

Let’s propagate the original location info in these branches (so downstream error messages can use it)

[simonihmig]

It seems I cannot do that with b.string(), can I?

https://github.com/glimmerjs/glimmer-vm/blob/master/packages/%40glimmer/syntax/lib/builders.ts#L564

Btw, as AST docs are quite sparse/non-existent, what does this actually do and how is this used? For error messages to print concrete line/column numbers of hbs files that break something?

[rwjblue]

It seems I cannot do that with b.string(), can I?

Ugg, indeed you are correct. Though I think you can create it and then add the loc:

let newString = b.string(attributeValue.chars);
newString.loc = attributeValue.loc;
return newString;

https://github.com/glimmerjs/glimmer-vm/blob/83a0c2fdfa8f22fd353dcab32ea41c4bcacaa379/packages/%40glimmer/syntax/lib/builders.ts#L577-L581 needs to be updated to take loc as the last arg in the returned function.

what does this actually do and how is this used? For error messages to print concrete line/column numbers of hbs files that break something?

Right, when creating new AST nodes we should always attempt to propagate the original location information through to the new nodes. This helps to ensure that any error messages include the correct module name, line, and column number.

[simonihmig]

Reading through this made me think of another issue: passing modifiers, comments, or attributes other than the specific ones we handle should issue a helpful error.

What do you mean by "comments"?

So to make this clear, as we transform to curly syntax that does not support arbitrary HTML attributes and no modifiers (which RFC435 does allow for angle bracket invocation), we should error on

• passing an attribute that is not supported through attributeBindings
• passing any kind of modifier

However passing any kind of unsupported property should not error IMHO, as that wouldn't be the case also with "native" angle bracket support (no polyfill required).

Correct?

Do you want me to tackle this in this PR? I would suggest to do that in another one, that also includes the link-to transform. So we can hopefully merge this before?

[rwjblue]

Do you want me to tackle this in this PR? I would suggest to do that in another one, that also includes the link-to transform. So we can hopefully merge this before?

Sorry, yes, I totally agree that we don't want that here in this PR. I just thought of it while reviewing this one.

[rwjblue]

What do you mean by "comments"?

<LinkTo @route="foo" @model={{whatever}} {{! template-lint-disable-tree no-bare-strings }}>Hello Untranslated String!</LinkTo>

[rwjblue]

So to make this clear, as we transform to curly syntax that does not support arbitrary HTML attributes and no modifiers (which RFC435 does allow for angle bracket invocation), we should error on

• passing an attribute that is not supported through attributeBindings
• passing any kind of modifier

Yes, exactly what I meant.

However passing any kind of unsupported property should not error IMHO, as that wouldn't be the case also with "native" angle bracket support (no polyfill required).

I don't quite understand what you mean here. Can you give an example of what you refer to as an "unsupported property"? Do you mean an attribute that isn't in the attributeBindings? A named argument that we don't "know" about? Something else?

[simonihmig]

A named argument that we don't "know" about?

Yes, that one. I probably was confused about your "comment" remark, because I didn't realize that was even possible until now, so thought you might mean some else / have a typo. I guess we agree that we don't have to do anything about arguments, so please ignore my confusion! 😝