NumericInput: no way to opt out of the JS interop layer

[mathewtaylor]

Split out of #328 (@leoneljerez), which bundled several unrelated things. This is the headline request from it: a numeric input that does not round-trip through JS.

The request

BbNumericInput has no mode that avoids JS interop. The reporter hit this building an Excel-like editing surface on WebAssembly — many numeric editors live at once — and measured a noticeable slowdown against MudBlazor's equivalent, which is pure C#.

They asked whether a Primitives-layer numeric input exists that strips the JS, or an attribute to disable it. Neither does.

What the JS layer actually costs

Per instance, on first render: a module import (cached after the first component), a DotNetObjectReference, and four addEventListener registrations — input, blur, focus, keydown — plus wheel when EnableWheelStep is set. Each instance also needs its dispose interop call on teardown.

Per keystroke: sanitizeInput runs in JS, then dotNetRef.invokeMethodAsync('JsOnInput', value). blur, focus and the stepping keys each round-trip separately.

DisableDebounce is not the escape hatch it looks like. It does not reduce interop — it removes the setTimeout, so JsOnInput fires immediately on every keystroke rather than once after DebounceInterval (default 500ms). It exists to make bindings feel immediate, and it makes the call volume strictly worse. Worth stating plainly because it is the parameter anyone would reach for first, and the issue sat for months partly because nobody said so.

What a JS-free mode would have to give up or reimplement

The JS is not decorative — porting it to C# means reimplementing:

• Input sanitisation with cursor preservation. Strips non-numeric characters as you type and restores the caret to the right offset, accounting for removed characters before it. Doing this from @oninput in C# means a round-trip to set SelectionStart, which is itself interop — so a naive port may not save anything.
• Full-width character folding (foldFullWidth), which matters for CJK input methods.
• Key stepping for Arrow/PageUp/PageDown/Home/End, currently handled by a JS keydown listener.
• Wheel stepping, with its accumulator for trackpad momentum.

A @oninput-driven C# implementation is straightforward for value binding and stepping, but the caret behaviour during sanitisation is the part that will decide whether it is actually usable.

Open questions

• Which layer? The reporter asked for a Primitives version. That fits the library's split — headless and unstyled, consumer supplies behaviour — but the sanitisation is behaviour, not styling, so it is not obvious the primitive is the right home.
• New component or a parameter? A DisableJsInterop-style flag on the existing component keeps one API but means two divergent code paths with subtly different typing behaviour, which is a support burden. A separate component is honest about the trade-off but duplicates surface.
• Is the cost per-instance or per-keystroke? Worth measuring before designing. If the dominant cost is per-instance setup in a grid of 200 editors, the fix might be shared listener delegation rather than removing JS.

Related

The same reporter noted that if this is not feasible, a performant editable DataGrid would address their underlying need. That is a larger piece of work but the same motivation — many simultaneous editors — and worth keeping in mind when scoping this.

[mathewtaylor]

Closing the loop on this one, @leoneljerez.

What v4 ships that covers the underlying need

The original report (#328) was about an Excel-like editing surface on WebAssembly — many numeric editors alive at once — and you noted that a performant editable DataGrid would address the need. v4 ships exactly that: BbDataGrid gains DataGridEditMode.Cell and DataGridEditMode.Batch, with isolated drafts through EditItemFactory, validation before save, retained drafts when persistence rejects a change, and keyboard save/cancel.

The important part for your scenario: the grid keeps one editor alive at a time, not one per cell. A single row is the editing row, and in Cell mode only the active column renders its editor. So a 200-row grid is one live BbNumericInput, not 200. The per-instance interop cost you measured does not accumulate there.

Worth knowing too: the JS module itself is imported once per runtime and shared across every instance, so that part was never per-component.

Live example and code at /components/datagrid-editing.

On a JS-free numeric input

We are not going to add one, and I would rather say so plainly than leave the issue open indefinitely.

The JS in BbNumericInput is not a wrapper we can peel off. It carries input sanitisation with caret preservation, full-width character folding for CJK input methods, key stepping, and wheel stepping with a momentum accumulator. Reimplementing that in C# means setting SelectionStart from .NET — which is itself interop — so a port could do the work and save nothing.

Shipping it as a flag or a second component would leave two code paths that type subtly differently. That is a permanent correctness and support cost, carried by everyone, for a scenario the library's own grid no longer creates.

If you still hit the wall

You would have to be building your own table outside BbDataGrid, with hundreds of numeric editors mounted at once. If that is you, please reopen with numbers — instance count, and a profile showing where the time goes.

The fix in that case would not be a second component. It would be shared event delegation: one listener set on a container instead of five per input, keeping a single implementation. That is worth doing against a measurement, not ahead of one.

Note on versions

v4 requires .NET 10 or later — .NET 8 and .NET 9 cannot consume it. It is in prerelease now (4.0.0-beta.9); tick "Include prerelease" to try it.

Thanks for the original report, and for the detail in it.