New-UDTable does not apply refreshed -InitialState when the table ID is unchanged
New-UDTable does not apply refreshed -InitialState when the table ID is unchanged
I reproduced this on a PowerShell Universal dashboard page at `/test`.
`New-UDTable -InitialState` accepts an initial state containing `Search`, `Filters`, `OrderBy`, and `PageSize`. However, when a table is recreated inside a synced `New-UDDynamic` with the same table ID, the refreshed `InitialState` is emitted by the server but is not reflected in the existing client-side table UI.
Minimal reproduction
```powershell
New-UDPage -Name 'Test' -Url '/test' -Content {
New-UDButton -Text 'Apply Bob state' -OnClick {
$Page:testCasesBulkNoteTableState = @{
Search = 'bob'
Filters = @(
@{
id = 'name'
value = '-2'
}
)
OrderBy = @{}
PageSize = 12
}
Sync-UDElement -Id 'testClearFilterDynamic'
}
New-UDDynamic -Id 'testClearFilterDynamic' -Content {
$tableState = $Page:testCasesBulkNoteTableState
New-UDTable -Id 'table7' `
-Data @(
[pscustomobject]@{ Name = 'Alice - 1' }
[pscustomobject]@{ Name = 'Bob - 2' }
) `
-Columns @(
New-UDTableColumn -Property 'Name' -Title 'Name' -Id 'name'
) `
-ShowSearch `
-InitialState $tableState
}
}
```
Expected behavior
After clicking **Apply Bob state**, syncing the enclosing `New-UDDynamic` should cause the same-ID table to apply the newly rendered `InitialState`:
```json
{
"Filters": [{ "value": "-2", "id": "name" }],
"PageSize": 12,
"OrderBy": {},
"Search": "bob"
}
```
In particular, the search input should show `bob`, and the state should apply in the same way as a table initially mounted with that payload.
Actual behavior
On first render, `$Page:testCasesBulkNoteTableState` is `$null`, so `table7` mounts with an empty search input.
After the button assigns the state and calls `Sync-UDElement` on the enclosing dynamic region:
- Server-side instrumentation shows the recreated `New-UDTable` component emits the exact `initialState` JSON above.
- The post-sync payload is byte-for-byte identical to a separately mounted hard-coded control table that displays `bob`.
- With the stable table ID `table7`, the original search input node remains connected after the dynamic sync and remains blank.
- The updated `InitialState` is therefore not applied to the existing same-ID client table.
Changing only the child table ID after the click, for example from `table7-r0` to `table7-r1`, forces a new mount and the search input correctly displays `bob`.
Confirmed observations
The reproduction ruled out:
- `$Page:` scope availability after the click
- Hashtable versus ordered hashtable / JSON serialization behavior
- Filter ID casing; the final state uses `name`, matching the column ID
- A mismatch in the emitted `initialState` payload
- Syncing the table directly; only the enclosing `New-UDDynamic` can be synced in this scenario
Request
Could PSU provide a supported mechanism for a same-ID `New-UDTable` to apply a refreshed `InitialState` when its enclosing `New-UDDynamic` is synced?
Alternatively, an explicit supported client-state update API for `New-UDTable` would address this use case.
Changing the table ID is not a practical workaround because it resets the table's client state and uses component identity as a forced refresh rather than applying the intended updated state.
Workaround
The current workaround is to maintain a page-scoped revision and include it in the child table ID, incrementing that revision immediately before syncing the enclosing `New-UDDynamic`:
```powershell
$Page:testCasesBulkNoteTableRevision = [int]$Page:testCasesBulkNoteTableRevision + 1
Sync-UDElement -Id 'testClearFilterDynamic'
New-UDDynamic -Id 'testClearFilterDynamic' -Content {
$revision = [int]$Page:testCasesBulkNoteTableRevision
New-UDTable -Id "table7-r$revision" `
-InitialState $Page:testCasesBulkNoteTableState `
# existing columns and load-data configuration
}
```
For example, the table ID changes from `table7-r0` to `table7-r1` when applying the preset state. This forces the client to mount a fresh table and causes `Search = 'bob'` to appear. It is a functional workaround, but it discards existing client-side table state, so it should not be required for a same-ID refreshed `InitialState`.
All Comments (5)
Hello mmorrow,
Thank you for the detailed report and for providing a clear minimal reproduction.
Based on the behavior you documented, the dynamic region appears to regenerate the table configuration and emit the updated `InitialState`, while the existing same-ID table retains its current client-side state. The fact that changing only the table ID causes the updated search and filter state to apply is a useful control for the investigation.
Before we attempt to reproduce this, could you please confirm the following?
• Your exact PowerShell Universal version and build
• The browser and browser version used
• Whether the production implementation uses local `-Data`, as shown in the example, or `-LoadData`
• Whether this currently affects a production environment and the practical impact on users
We will use your example to test whether `Search`, `Filters`, `OrderBy`, and `PageSize` are reapplied when the enclosing `New-UDDynamic` is synchronized while the table ID remains unchanged.
At this stage, we have not yet independently confirmed this as a product defect. We will update the thread after reviewing the behavior under the reported version and conditions.
Best regards,
Ruben Tapia
• Your exact PowerShell Universal version and build
2026.2.2
• The browser and browser version used
chrome Version 150.0.7871.184 (Official Build) (64-bit)
• Whether the production implementation uses local `-Data`, as shown in the example, or `-LoadData`
prod uses -loaddata because the dataset is large
• Whether this currently affects a production environment and the practical impact on users
trying to add a preset save feature so people can set all the filters and save them for later
Also, i cannot get the filter presets to set. so like i have a Name and Value table and i try to set the filter to array to something, that does not populate the filter column field.
Hello mmorrow,
Thank you for confirming the PowerShell Universal version, browser version, production use of -LoadData, and the impact on your preset-saving feature.
We will attempt to reproduce the behavior in our lab using PSU 2026.2.2, including the same-ID New-UDTable scenario and the production-relevant -LoadData configuration.
We will specifically validate whether the updated Search, Filters, OrderBy, and PageSize values are emitted but not applied to the existing client-side table state. We will also compare this against the workaround that changes the table ID and forces a new component mount.
Once the behavior has been independently validated, we will document the findings and route the case through the appropriate internal review process based on the lab results.
We will update this thread once the reproduction has been completed.
Best regards,
Ruben Tapia
Hello mmorrow,
Thank you for your patience while we completed the laboratory review.
We were able to partially reproduce the reported behavior in PowerShell Universal 2026.2.2.
In the -LoadData scenario, synchronizing the enclosing New-UDDynamic while keeping the same table ID caused the table to retain its previous Search, Filters, PageSize, and ordering state, even though the server emitted the updated InitialState. Changing only the table ID forced a new component mount and applied the updated Search, PageSize, and ordering values.
The -Data scenario behaved differently. Search and ordering updated with the same ID, while PageSize and the filter controls retained their previous state. We also observed that a filter value could be present in LoadData EventData while the visible column filter field remained empty.
Because the behavior varies depending on the table mode and InitialState property, the laboratory result is classified as partially reproduced rather than a universal InitialState refresh failure.
We will now escalate the findings internally for Development review, including the comparison between -Data and -LoadData, the component lifecycle evidence, and the filter display behavior. We cannot confirm the final product classification or expected contract until that review is completed.
We will update this thread when additional information becomes available.
Best regards,
Ruben Tapia
Hello mmorrow,
I have escalated the case and the laboratory findings to Development for internal review.
I will remain pending their assessment and will update this thread once additional information becomes available.
Best regards,
Ruben Tapia