Input Large Text Area Sample #77
Conversation
| } | ||
|
|
||
| // Make the following APIs available in global scope for invocation from JS | ||
| window['InputLargeTextArea'] = InputLargeTextArea; |
There was a problem hiding this comment.
Out of curiosity, why would we do do this? Probably enough for a user to operate directly against the textarea element, no?
There was a problem hiding this comment.
Just wanted it to be more general / following the in-framework pattern.
| /// <param name="streamWriter">A <see cref="System.IO.StreamWriter"/> used to set the value of the textarea.</param> | ||
| /// <param name="leaveTextAreaEnabled"><see langword="false" /> to disable the textarea while setting new content from the stream, otherwise <see langword="true" /> to allow it to be editable. Defaults to <see langword="false" />.</param> | ||
| /// <param name="cancellationToken">The <see cref="System.Threading.CancellationToken"/> used to relay cancellation of the request.</param> | ||
| public virtual async ValueTask SetTextAsync(StreamWriter streamWriter, bool leaveTextAreaEnabled = false, CancellationToken cancellationToken = default) |
There was a problem hiding this comment.
Now that it's not in the box, would we consider adding a set of string based overloads with the caveat that says "using this might result in excessive allocations"? The nice-ish part about doing so would be that we would expose this as a Stream based overload and let users figure out how to turn it in to readable text.
There was a problem hiding this comment.
consider adding a set of string based overloads
expose this as a Stream based overload
I'm assuming you mean string in both cases?
public virtual async ValueTask SetTextAsStringAsync(string textToSet, bool leaveTextAreaEnabled = false, CancellationToken cancellationToken = default);
public virtual async ValueTask<string> GetTextAsStringAsync(CancellationToken cancellationToken = default);
Merging this in now. I think the string based API should be a fairly simple addition if developers need it (should just be a matter of wrapping the StreamReader/StreamWriter usage around a function in |
Fixes: dotnet/aspnetcore#30291
Replaces: dotnet/aspnetcore#34856