Blazor InputLargeTextArea

[TanayParikh]

Usage:

<InputLargeTextArea @ref="TextArea" OnChange="TextAreaChanged" />


@code {
  InputLargeTextArea TextArea;

  public async Task GetTextAsync()
  {
      var streamReader = await TextArea.GetTextAsync();
      GetTextResult = await streamReader.ReadToEndAsync();
      StateHasChanged();
  }

  public async Task SetTextAsync()
  {
      var memoryStream = new MemoryStream();
      var streamWriter = new StreamWriter(memoryStream);
      await streamWriter.WriteAsync(new string('c', 50_000));
      await streamWriter.FlushAsync();
      await TextArea.SetTextAsync(streamWriter);
  }

  public void TextAreaChanged(InputLargeTextAreaChangeEventArgs args)
  {
      // args.Length represents the new textarea value length
  }
}

Implementation Notes:
Follows the overall pattern we have with the InputFile Component, communicating with the client and relaying back events.

Fixes: #30291
API Proposal: #35007

[TanayParikh]

/ping @aspnet-blazor-eng, this is ready for review 😄

[ghost]

Thank you for your API proposal. I'm removing the api-ready-for-review label. API Proposals should be submitted for review through Issues based on this template.

[pranavkm]

The code changes are fairly straight forward, but I'd like to make sure this is the right API shape.

[TanayParikh]

This is now ready for review based on the new symmetric StreamReader/StreamWriter approach discussed in the API Proposal: #35007

[pranavkm]

The PR looks great.

[pranavkm]

Can we throw a more specific exception? Hard to say that ArgumentOutOfRange is specifically because of a 0-length stream?

[TanayParikh]

Hmm in the original context, I believe the ArgumentOutOfRange exception may make sense, however I see your point about it still being ambiguous with other areas where that exception may be thrown.

How about this:
https://github.com/dotnet/aspnetcore/pull/34856/files#diff-30d94608ca41ec93dcbe8eb2bb646257519e86080e81ed5c246a715a8782c4b9R94-R102

Alternatively, we can decorate the Exception.Data property with something more specific (though that may not necessarily be statically typed).

[TanayParikh]

Suggested change

	// public override async Task InitializeAsync()
	// {
	// // Since the tests share interactivity with the same text area, it's easiest for each
	// // test to run in its own browser instance.
	// await base.InitializeAsync(Guid.NewGuid().ToString());
	// }
	public override async Task InitializeAsync()
	{
	// Since the tests share interactivity with the same text area, it's easiest for each
	// test to run in its own browser instance.
	await base.InitializeAsync(Guid.NewGuid().ToString());
	}

[SteveSandersonMS]

In Typescript it's idiomatic for interfaces not to have an I prefix. I suppose the difference vs C# is that it's very meaningful to think about runtime types in .NET but not so relevant in JS.

[SteveSandersonMS]

Suggested change

	/// The textarea element for which the event was raised.
	/// The <see cref="InputLargeTextArea" /> for which the event was raised.

[SteveSandersonMS]

Should the type be long? Can it be > 2GB? I know that it would be pretty outrageous to have a 2GB textarea, but do we definitely want to preclude it?

[TanayParikh]

There are concerns with API complexity from having to work with Stream{Reader/Writer} when users may be expecting to work with strings directly. Supporting strings directly isn't optimal either due to the (large) amount of allocations it would trigger.

Closing this PR in favor of docs/samples of a solution for users that encounter this issue.