Skip to content

feat: [Remote rendering 3.5b] client uses server owned variables - #153

Draft
LKasianAnsys wants to merge 6 commits into
feat/3.5a-move-variable-ownership-to-serverfrom
feat/3.5b-client-uses-server-owned-variables
Draft

LKasianAnsys wants to merge 6 commits into
feat/3.5a-move-variable-ownership-to-serverfrom
feat/3.5b-client-uses-server-owned-variables

Conversation

@LKasianAnsys

@LKasianAnsys LKasianAnsys commented Oct 1, 2026 •

Copy link
Copy Markdown
Collaborator

Issue

Addresses #23

Status: WIP

Copilot summary

This pull request refactors how variable metadata and range information are managed and delivered between the server and client in the Visor application. The changes move ownership of variable records from the client to the server, ensuring that variable state is always sourced from server deliveries rather than being reconstructed or duplicated on the client. The update also simplifies the flow for updating and applying variable ranges, and introduces new utility methods for UI components to refresh their state based on the latest variable records.

Key changes include:

Variable Record Ownership & Delivery

  • Removed client-side reconstruction of variable records during scene rebuilds; now, variable records are always delivered by the server and not carried over or duplicated on the client. (VisorFrontend.tsx, VisorVariableManager.tsx) [1] [2]
  • Updated VisorVariableManager to provide methods for setting delivered variable records (setRecords) and projecting them as needed, replacing the previous approach of aggregating from local data arrays. (VisorVariableManager.tsx)

Variable Range Application & Synchronization

  • Added sendVariableRangeAsync and updated setVariableRangeAsync in VisorFrontend to report range changes to the server and apply them locally, with error handling for failed sends. (VisorFrontend.tsx) [1] [2]
  • Simplified and clarified the process of applying variable ranges to scene parts: variable records are set before part updates, and redundant range applications are avoided by checking if the range has changed. (VisorFrontend.tsx, VisorSceneGraph.tsx) [1] [2]

UI Synchronization Enhancements

  • Added a refreshSelectionAsync method to the Panel_TopRight_Util class, allowing UI panels to refresh their selection and displayed ranges after variable records are updated. (Panel_TopRight_Util.tsx, Panel_TopRight.tsx) [1] [2] [3]
  • Ensured that the UI panel refreshes its selection after new variable records are delivered and the tree view is synchronized. (VisorFrontend.tsx)

Testing and Internal API Adjustments

  • Updated tests and internal APIs to use the new variable record delivery and management flow, ensuring that tests reflect the server-delivered variable state. (VisorSceneGraphPartTriggers.test.tsx, VisorSceneGraph.tsx) [1] [2] [3]

Type and Documentation Updates

  • Updated type definitions and documentation to reflect the new flow of variable record management and clarify the meaning of fields such as defaultRange. (VisorVariableManager.tsx) [1] [2]

These changes collectively improve consistency, reduce duplication, and make the client more robust to server-driven updates of variable state.

@github-actions github-actions Bot added the added label Oct 1, 2026
@LKasianAnsys LKasianAnsys changed the title Feat/3.5b client uses server owned variables feat: [Remote rendering 3.5b] client uses server owned variables Oct 1, 2026
@github-actions github-actions Bot added the enhancement New feature or request label Oct 1, 2026
@LKasianAnsys
LKasianAnsys force-pushed the feat/3.5a-move-variable-ownership-to-server branch from a6e2619 to 328ccf1 Compare October 2, 2026 17:22
@LKasianAnsys
LKasianAnsys force-pushed the feat/3.5b-client-uses-server-owned-variables branch from c04cb7f to 77400e7 Compare October 2, 2026 17:30
@LKasianAnsys LKasianAnsys self-assigned this Oct 2, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

added enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants