A team is building several React-based code components for a model-driven app. Each component currently bundles its own copy of React and Fluent UI, which makes the bundles large and slows form loading. What should the developer change in each manifest?
Select an answer to reveal the explanation.
Short Explanation
Why should every component carry its own toolbox when the platform already has one in the garage? A virtual component that declares platform libraries borrows the shared React and Fluent, so your bundles shrink and forms load faster.
Full Explanation
React-based code components, called virtual components, set the control-type attribute in the manifest to virtual and declare platform-library elements for React and, when used, Fluent UI. The framework then provides those libraries from the platform, so each component's bundle contains only its own code, and the platform renders the component through its React tree rather than giving it a container to manage. This reduces bundle size and improves load performance, especially when several components appear on the same form. Adding the libraries as resources in a standard component still ships them with each component and loads them per component, which is exactly the duplication to remove. There is no react control type; the supported values are standard and virtual, and the build does not silently replace imports with platform copies. The feature-usage element declares framework features such as device capabilities and the Web API, not shared libraries. Exam caveat: a virtual component implements the React control interface, so updateView returns a React element and init does not receive a container element; converting an existing standard component therefore requires code changes as well as manifest changes. Operational check: rebuild after the change, compare the bundle size before and after, and confirm the component renders on the form using the platform's React version.