onInput performance ( even crash browser )

[hdriqi]

Hi, I am using onInput for my input field. here's the emitter:

emitter.on('inputUsername', (e) => {
		let input = e.target.value
		if(input.length < 9){
			if(input === '' || input.match(/^[a-z0-9]+$/i)){
				state.input.username = input.toLowerCase()
				emitter.emit('render')
			}
			else{
				state.input.username = input.slice(0, input.length - 1)
				emitter.emit('render')
			}
		}
		else{
			emitter.emit('render')
		}
	})

While typing a lot of characters, for example a,b,c,backspace,backspace,d,e, etc will crash the browser ( google chrome in my case ). After a bit of research, the google chrome dump is telling me that the browser ran out of memory.

Also, while testing on my mobile devices the browser doesnt crash but the performance is so bad. After I press a character in the keyboard, the dom need about .3s - .5s to rerender it.

Is there any solution?
I need to make sure the username field less than 9 chars and alphanumeric only.

[bcomnes]

Hard to imagine this event handler would be the cause of of a memory leak. I would suspect the culprits is living in the render cycles.

[hdriqi]

@bcomnes any idea about the workaround?

[graforlock]

Are you re-rendering the input fields? I suggest you prevent that for all input fields with .isSame and try again.

Also, you can validate inputs in event handlers checking it like this (these days):

const onInput = e => {
 if(e.target.checkValidity()) {
  ...
 }
}

Using HTML5 validation with regex patterns.

In general, can you reproduce it somewhere on, for example, github repo? That'd be helpful.

[graforlock]

@hdriqi Are you still experiencing the issue? Is it still a valid issue?

[hdriqi]

@graforlock yes, but i thought that it is because I did the re-render after each user input. So my workaround is that you should not re-render inside the onInput to give validation, instead you need to do it after the users press submit button to avoid the slow performance.

[graforlock]

It still shouldn't be technically happening, even though I am not a big fan of re-rendering inputs, this works well in React for instance and I see no reason why wouldn't it.

It has to be looked into. Can you provide reproducible scenario @hdriqi ?

[graforlock]

I believe this is related to the latest update finds @yoshuawuyts

[yoshuawuyts]

A repro on this would be good; I can't think of a good reason why this should be happening - even with lots of re-rendering nodes should be able to be garbage collected normally, and only ever cause the program to slow down, not crash.

Also related to this: it's definitely recommended to use html5 validation, as it performs better and is more accessible.

[hdriqi]

@yoshuawuyts just start a new project and using choo. This time oninput does not crash and run smoothly. My previous project that had oninput crash is using JSS (https://github.com/cssinjs/jss) which uses a lot of variables as classname and conditional class (which use function). I think those are the problem that cause the slow down, even crash.

[yoshuawuyts]

Oh; glad to hear it's not us! — if you ever run into more slowdowns (especially with long lists), we now have an issue to handle that! choojs/nanomorph#85

…

On Wed, Oct 11, 2017 at 8:24 AM Rahmat Albariqi ***@***.***> wrote: @yoshuawuyts <https://github.com/yoshuawuyts> just start a new project and using choo. This time oninput does not crash and run smoothly. My previous project that had oninput crash is using JSS ( https://github.com/cssinjs/jss) which uses a lot of variables as classname. I think JSS is causing the slow down, even crash. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#564 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWleovTLhMsEgQoz8vADxC4RtVp6i8vks5srLOHgaJpZM4PZTwm> .

[bcomnes]

Perhaps we could figure out if there is something going on between choo and jss.