[BLAZOR WASM] Lagging textarea binding with large amount of text

I am using textarea in Blazor webassembly (core 3.1) which is binded to a property in the page. I am using bind-value and bind-value:event because when I use only bind=“Property” then It does not update as the user is typing which is my use case. I am using this binded value to send requests and save current content of the textarea after the user stops typing.

<textarea @bind-value="Note.Content" @bind-value:event="oninput" @onkeyup="@NoteTypingKeyUp"></textarea>

@code {
    [Parameter]
    public NoteDetailViewModel Note {get; set;}
    private Timer timer;
    protected override async Task OnInitializedAsync()
    {
        //Initialize timer
        timer = new Timer(300);
        timer.Elapsed += NoteStoppedTyping;
        timer.AutoReset = false;
    }

    private void NoteTypingKeyUp(KeyboardEventArgs e)
    {
        // remove previous one
        timer.Stop();

        // new timer
        timer.Start();
    }

    private void NoteStoppedTyping(Object source, ElapsedEventArgs e)
    {
        if (Note.Id == null)
        {
            if (!string.IsNullOrWhiteSpace(Note.Content))
            {
                InvokeAsync(async () =>
                {
                    await CreateNote();
                    await LoadNotes();
                });
            }
        }
        else
        {
            InvokeAsync(async () =>
            {
                await UpdateNote();
                await LoadNotes();
            });
        }
    }

It works fine when the text in the textarea is short. For large amounts it causes UI delays as the user types letters are appearing with a very significant delay.

Is it a known bug and is there some workaround? Thanks

[silverx69]

I think I might have found a workaround. @captainsafia had mentioned something that gave me an idea.

It’s expected that Blazor components will trigger a re-render when an event handler is invoked.

When an input control or textarea is INSIDE of a larger, more complex Blazor component, the events cause the parent component to re-render it’s contents. This is laggy when the Blazor component is large, however!

If you make a NEW component, and ONLY put the input box in that component and then add that component in the same place as the original input box. It’s renders MUCH MUCH MUCH faster, and I have virtually no lagg.

So this problem is definitely tied to how complex the input/textarea’s parent component is, and you can side skirt this issue by placing the input in a much less complicated container component.

[silverx69]

I am having this problem too, it’s very very easy to reproduce, you should not need an example from the community to reproduce this behavior, it’s mind numbingly easy. Just bind-value and bind-value:event=“oninput” or attach any onkey* event handler on a textarea OR input type=“text” and hold a key down or try to type quickly, the words do not appear until you pause typing and let go of keys. This is very confusing to the user because they think it’s not working until they stop typing and the text suddenly appears.

The strange part about this, is that I have an input box on another page that has an ‘oninput’ event handler and does not suffer from the same input lagg even though the event handlers are virtually identical.

I have tried every single combination of onkeydown, onkeypress, onkeyup, oninput, onchange, etc… There is no input lagg on the element unitl I attach a blazor binding/event-handler, and it seems to only happen on complex pages during the “onkeyup” phase.

The lowest amount of lagg I had in the elements were when using “onkeyup” as an event handler. If you hold a key down, there was no lagg, but if you tried typing random characters quickly then it would lagg. So my guess is there’s something on the “KeyUp” handler internally that’s slowing things down when attached to blazor events/binding. I’m assuming a re-rendering (however it should be noted that the new characters appear, meaning rendering is still happening even with the keydown and there is no lagg).