trouble setting -value using New-UDAutocomplete with -OnLoadOptions

Hello @Matthew Morrow,

Your thread has been moved to the PowerShell Universal forum.

Best regards,
Christian

Hello,

Thanks for your patience.
We have a technician on this case; he should be back to you by tomorrow at the latest.

Best regards,

Hi @Matthew Morrow ,

Thanks for the report and for the minimal repro, it made this very easy to trace.

I confirmed the behaviour on a fresh PowerShell Universal 2026.2.5 instance and can reproduce it exactly with your snippet.

Passing -Value 3 sends "3" (as a string) to the browser, but when -OnLoadOptions is used the client's option list is empty at first render because options are only fetched after the user starts typing.
The MUI Autocomplete component then falls back to displaying the raw value string, which is why you see 3 instead of xyz 3, even though the underlying selected value is correct.




There are actually two things stacked on top of each other here.
The cmdlet coerces the value to a string (if ($Value -isnot [object[]]) { $Value = [string]$Value }) which prevents you from handing it a full option object such as @{ name='xyz 3'; value=3 }.
And the JS component only recomputes the displayed label from the value when at least one option in the current options list matches, which never happens at mount time in the OnLoadOptions parameter set.

The workaround that works reliably today is to use the static -Options parameter instead of -OnLoadOptions and let MUI filter client side.
MUI virtualizes the popper list so 6000 items still render smoothly, and the one time payload is small (roughly 90 KB for name plus value pairs at your scale).


New-UDDynamic -Id testDyn -Content {
$myTestOptions = @(1..6000) | ForEach-Object {
New-UDAutocompleteOption -Name "xyz $_" -Value $_
}
New-UDAutocomplete -Id 'autocomplete8' -FullWidth -Options $myTestOptions -Value 3
}
Verified: input shows xyz 3 at first render, the OnChange selection still returns the numeric value, and the drop down remains filterable as before.




I also tested a second workaround based on Set-UDElement hydrating the value with the full option object after mount, and I want to save you the time.
The setState message reaches the browser correctly (I verified over the wire) but MUI still refuses to paint the label because the value does not match anything in the empty options list, so that path is a dead end without a client side change.

If keeping the server side lazy filter is really important for your scenario (dynamic or truly huge dataset) there is no clean workaround at the moment, only the static Options path above.
A proper fix would need to happen in the cmdlet itself, either by letting a hashtable or PSCustomObject value survive the string coercion, or by adding a way to preload the currently selected item into the client's initial options state alongside OnLoadOptions.

Best regards,

ya when i load 100k records in there, -options is not quite usable, i was hoping we could get the control or add a patch to the control to enable a select, or an -onloadoptionsValue parm or something that would let us get the item selected even if we have a dynamic load setup.

Hi @mmorrow ,

Thanks for the follow-up, feedback like this is what helps us prioritize the right things internally.

After exploring a few directions, I have to be upfront: beyond the static -Options approach from my previous reply, there isn't a clean client-side workaround for the combination of -OnLoadOptions and a preselected -Value at your dataset size.

Every avenue I looked at either sacrifices the lazy loading you rely on (not viable at 100k rows) or requires dropping down to a custom React component through the PSU Apps SDK.

That second path is technically possible, but it's a substantial investment for a single control and rarely justified outside of very specialized scenarios.

That said, there are a couple of things worth keeping in mind while the fix works its way through the pipeline.

Worth noting that the value passed to your OnChange handler is still the correct one, only the label rendered in the input is off at first paint.

For workflows where the functional behaviour matters more than the initial visual, this can be a serviceable stopgap, imperfect but not blocking.

Alternatively, if you can identify an earlier PSU build where this scenario rendered correctly in your environment, pinning to that version is a supported approach until the fix ships.

I'd recommend validating the downgrade against the rest of your dashboard first, to confirm nothing else regresses in the process.

Best regards,

ya when i load 100k records in there, -options is not quite usable, i was hoping we could get the control or add a patch to the control to enable a select, or an -onloadoptionsValue parm or something that would let us get the item selected even if we have a dynamic load setup.