Skip to content

Conversation

@domchristie
Copy link
Collaborator

Removes the unnecessary call to update the clone textarea on change, since it should already have updated on the input event. It also exposes the update method to the jQuery plugin, so that rather than accessing the Expanding instance and calling update:

$('textarea').data('expanding').update()

users can do:

$('textarea').expanding('update')

as is shown in the updated demo.

@bgrins
Copy link
Owner

bgrins commented Nov 7, 2016

I thought there was some case on older browsers not supporting 'input' that change would capture cases where keyup didn't (maybe right click -> paste for instance). However, at this point I think we can assume it's available: http://caniuse.com/#feat=input-event

@bgrins
Copy link
Owner

bgrins commented Nov 7, 2016

Looks fine to me if you are OK with #68 (comment)

@domchristie
Copy link
Collaborator Author

I thought there was some case on older browsers not supporting 'input' that change would capture cases where keyup didn't (maybe right click -> paste for instance)

Good point: I have added a paste handler for browsers that do not support input.

this.textarea.on(inputEvent, inputHandler)
this.textarea.on('change', inputHandler)
this.textarea.on(inputEvent, this.update.bind(this))
if (inputEvent !== 'input') this.textarea.on('paste', inputHandler)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say either use inputHandler in both places or this.update.bind(this) in both places.

Also, 'change' seems a bit more robust vs paste - I was just bringing the paste context menu as an example - there are probably other cases where the input changes but a paste didn't happen (for instance, dragging text around).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say either use inputHandler in both places or this.update.bind(this) in both places.

Apologies! Corrected in 8331b51

Also, 'change' seems a bit more robust vs paste

Yes, although it won't expand the textarea until it is blurred, which isn't a great user experience. Whilst it doesn't cover every case, handling keyup, cut, and paste, should cover the most common cases on IE9.

I guess we could also handle thechange event if input is not supported? That way it expands immediately on keyup, cut and paste, and then on change for any other event.

To add a bit more background to this change, I am working on a messaging app, where the textarea is positioned at the bottom. As the user types and the textarea expands, the viewport's scroll position needs to be fixed to the bottom. I have something like the following:

textarea.addEventListener('expanding:update', function () {
  window.scrollTo(0, document.body.scrollHeight)
})

However, if the user tries to tap the "Send" button straight after typing, expanding:update is called on change, the window is scrolled, which seems to prevent the touch event from submitting the form.

This only appears to happen on iOS. I have replicated this without the Expanding library here: http://jsbin.com/toxaha/edit?html,js,output

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants