Textarea template cannot be provided

[timwis]

It looks like if you set type to textarea, handleTypeChange simply replaces your <input> with a <textarea>. In my case, I'm using a CSS framework that requires class="textarea" be set on <textarea> elements for proper rendering.

It's not clear what the best solution here is. The only idea I've thought of so far is to define both an <input> and a <textarea> in the template and have handleTypeChange hide or remove the unnecessary one.

An alternative (and "for now" workaround) is to extend ampersand-input-view with a textarea-view class that has its own template.

[cdaringe]

that's one of those blocks of code that I figured no one would ever touch. is it even semantically acceptable to set type textarea on an input?

MDN doesn't suggest textarea an acceptable input: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type

im curious what the CSS framework people have to say on the matter!

[timwis]

@cdaringe I think we're talking about type in two different senses: I was talking about it in the sense of the options hash passed to the constructor of InputView. The code has special handling for when it's set to textarea: it converts the element from an <input> to a <textarea>. I was pointing out that when that happens, you lose the ability to provide a template for it.

Regarding the CSS framework I mentioned, I was saying that the framework requires <textarea> elements have their class set to textarea in order to apply the appropriate styles.

Does that make more sense?

[cdaringe]

whoops, ya, sorry there! please bear with me here as i put it all together. tell me where my thought process is wrong here:

• you provide a template
• renderWithTemplate is called
• &-input-view queries for textarea, and sets it to this.input
• handleTypeChange change runs. type is set to textarea from the constructor, and this.input is a text area, so this bit runs

what i think you're saying is that your this.input is being swapped by this bit. is that correct?

[timwis]

Almost -- the template I'm providing only contains an <input> (as does the default template in InputView), so your 3rd bullet doesn't occur, and in your 4th bullet, the first condition is true, so the "bit" you referenced at the end is called.

I suppose I could get around this by providing a separate template for <textarea>s, but it seemed like this module wanted to support both inputs and textareas so I was trying to think of a way to do that with a single template.

If I'm still being too vague don't worry about it, this is probably an edge case.

[cdaringe]

i'm really sorry man, i'm still not tracking. i do have a tendency to look at these issues pretty late at night, but...

why set type to textarea on an <input>? again, it's not a valid type for an input, and type per the constructor options is an attribute toggle.

looks like if you set type to textarea, handleTypeChange simply replaces your <input> with a <textarea>

yep, i observe that per you notes above as well

In my case, I'm using a CSS framework that requires class="textarea" be set on <textarea> elements for proper rendering.

but weren't we just talking about <input>s? if it's setting type and/or class to textarea on a <textarea>, aren't we all good?

Textarea template cannot be provided

Check this out: http://requirebin.com/?gist=05bba44a0ac73ac96c59

Whew. :) Please, set me straight if I'm still missing something

[timwis]

haha no worries, this is a pretty minor detail when it comes down to it, and I can understand how I haven't been clear.

What I'm really trying to point out is that handleTypeChange suggests the InputView module was intended to be used for both <input>s and <textarea>s since it creates a <textarea> element and replaces the <input> from the template with it if the view is initialized with type: 'textarea'. If one were to use it that way, however, you can't really customize the template of the <textarea> since the element is created in this function (with no classes etc.). Here's a demonstration of that approach.

It seems like the way you did it in your demonstration is the best approach - having a separate view (extended from InputView) for <textarea>s. It's just odd that handleTypeChange offers that functionality is all.

Really though, feel free to close the issue -- sorry if this has seemed silly.

[cdaringe]

not silly at all. it's a weird-ism of the API. if anything, i'm prone to removing that logic or throwing an error if there's some sort of mismatch. if you look at the blame, it's legacy stuff. maybe it had better purpose then, but certainly now its arguably unhelpful code!