Skip to content

Conversation

@jonthysell
Copy link
Contributor

@jonthysell jonthysell commented Oct 16, 2024

Description

This PR simplifies and scopes down the API for ReactNativeAppBuilder and ReactNativeWin32App.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

Why

ReactNativeAppBuilder's API surface made it too easy to call incorrectly and not realize it.

Resolves #13946

What

There are a variety of changes to the API surface:

  • ReactInstanceSettingsBuilder deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's ReactNativeHost's ReactInstanceSettings with a new one is what caused the bug in When Using New App Template (with ReactNativeAppBuilder) In-App Defined Native Modules Are Not Automatically Registered #13946 in the first place
  • ReactNativeAppBuilder now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. DispatcherQueueController, Compositor, and AppWindow), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a ReactNativeWin32App with those types properly pre-made
  • ReactNativeWin32App::Start() is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
  • All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
  • The template has been updated to follow the pattern of:
    • Use ReactNativeAppBuilder to get a ReactNativeWin32 app with the base WinAppSDK types ready
    • Get and modify the types as necessary from the created app object (like the ReactInstanceSettings and the AppWindow)
    • Call app.Start()

Screenshots

N/A

Testing

Verified new apps and example apps in libraryes build and run properly.

Changelog

Should this change be included in the release notes: yes

Cleanup ReactNativeAppBuilder and ReactNativeWin32App

Microsoft Reviewers: Open in CodeFlow

This PR simplifies and scopes down the API for ReactNativeAppBuilder and
ReactNativeWin32App.

Closes microsoft#13946
@jonthysell jonthysell requested review from a team as code owners October 16, 2024 01:04
@microsoft-github-policy-service microsoft-github-policy-service bot added Area: App Template New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric labels Oct 16, 2024
@jonthysell jonthysell merged commit e1b07c7 into microsoft:main Oct 21, 2024
@jonthysell jonthysell deleted the appbuildercleanup branch October 21, 2024 20:12
jonthysell added a commit to jonthysell/react-native-windows that referenced this pull request Oct 23, 2024
This PR backports microsoft#13983 to 0.76.

## Description

This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

### Type of Change
- Bug fix (non-breaking change which fixes an issue)

### Why
`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves microsoft#13946

### What

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in microsoft#13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

## Screenshots
N/A

## Testing
Verified new apps and example apps in libraryes build and run properly.

## Changelog
Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App
jonthysell added a commit that referenced this pull request Oct 24, 2024
This PR backports #13983 to 0.76.

## Description

This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

### Type of Change
- Bug fix (non-breaking change which fixes an issue)

### Why
`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves #13946

### What

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in #13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

## Screenshots
N/A

## Testing
Verified new apps and example apps in libraryes build and run properly.

## Changelog
Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App
acoates-ms pushed a commit to acoates-ms/react-native-windows that referenced this pull request Nov 2, 2024
This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

- Bug fix (non-breaking change which fixes an issue)

`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves microsoft#13946

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in microsoft#13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

N/A

Verified new apps and example apps in libraryes build and run properly.

Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App
acoates-ms added a commit that referenced this pull request Nov 5, 2024
* [Fabric] Introducing autocapitalize prop in TextInput - Take 2 (#13343)

* New implementation of autocapitalize!

* Change files

* Fixed bug for sentences scenario

* Just keep characters mode for now

* Revert "Just keep characters mode for now"

This reverts commit 60ca1ce.

* Re-apply changes minus packages.json.lock

* The original js file was deleted, re-applying changes

* Fixed snapshot and lint errors

* Fix override mismatch, added comments

* Remove stale test check

* Minor changes

* Update obsolete snapshot

* Cleanup ReactNativeAppBuilder and ReactNativeWin32App (#13983)

This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

- Bug fix (non-breaking change which fixes an issue)

`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves #13946

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in #13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

N/A

Verified new apps and example apps in libraryes build and run properly.

Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App

* Update Guardrails on Provider Instantiation (#13961)

* Update Provider Guardrails

* Change files

* Format

* Update Snapshots

* Add very basic box-shadow support (#14028)

* Add very basic box-shadow support

* Change files

* Focus should notify island host when tab loop wraps to give host oportunity to take focus (#14026)

* Focus should notify island host when tab loop wraps to give host oportunity to take focus

* Change files

* Default scroll to bring a component into view should have padding around the viewport (#14018)

* Default scroll to bring a component into view should have padding around the viewport

* Change files

* Update focus visuals to use cornerRadius and inner/outer strokes (#14008)

* Update focus visuals to use cornerRadius and inner/outer strokes.

* Change files

* Format

* lint fix

* Scale focus border for scaleFactor

* [Fabric] Get Modal to host RN components in new hwnd (#13500)

* save state

* add example

* build but blank page still :(

* clean up comments

* visuals show up in new hwnd!

* clean up code

* better naming and unfork Modal examples

* testing save state

* Make the RN island a Modal member var

* Failed attempt at skipping root view in CEH, leaving it for learning purposes

* you can click on UI!

* clean up code

* Change files

* save state

* remove hardcoded rootTag

* add width/height to example

* add test

* revert simple.tsx

* remove test

* update snapshot

* feedback part 1: make Modal a RootComponentView

* feedback part2: simplify MountChildren

* fix deleting modal

* feedback round2

* remove comment

* remove imports

* feedback part 3

* fix overrides

* add simple layout - still has issues with padding/flex

* feedback part4

* lint

* update overrides

* Change files

* feedback

---------

Co-authored-by: Daniel Ayala <14967941+danielayala94@users.noreply.github.com>

* Support accessibilityState 'checked' (#13962)

* Implement accessibilityState checked

* Change files

* Add Testing

* Format and Update Snapshots

* Adjust Guardrails

* Merge

* Format

* Format

* Lint

* Change files

* Fix Merge Error

* Fix issue with prop cloning with custom native props (#14061)

* Fix issue with prop cloning with custom native props

* format

* prettier

* Change files

---------

Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>

* change files

* Build fixes

* fix

* fix

* snapshot

---------

Co-authored-by: Daniel Ayala <14967941+danielayala94@users.noreply.github.com>
Co-authored-by: Jon Thysell <jthysell@microsoft.com>
Co-authored-by: Chiara Mooney <34109996+chiaramooney@users.noreply.github.com>
Co-authored-by: Tatiana Kapos <tatianakapos@microsoft.com>
Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>
acoates-ms pushed a commit to acoates-ms/react-native-windows that referenced this pull request Nov 12, 2024
This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

- Bug fix (non-breaking change which fixes an issue)

`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves microsoft#13946

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in microsoft#13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

N/A

Verified new apps and example apps in libraryes build and run properly.

Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App
acoates-ms added a commit that referenced this pull request Nov 23, 2024
* [Fabric] Introducing autocapitalize prop in TextInput - Take 2 (#13343)

* New implementation of autocapitalize!

* Change files

* Fixed bug for sentences scenario

* Just keep characters mode for now

* Revert "Just keep characters mode for now"

This reverts commit 60ca1ce.

* Re-apply changes minus packages.json.lock

* The original js file was deleted, re-applying changes

* Fixed snapshot and lint errors

* Fix override mismatch, added comments

* Remove stale test check

* Minor changes

* Update obsolete snapshot

* Cleanup ReactNativeAppBuilder and ReactNativeWin32App (#13983)

This PR simplifies and scopes down the API for `ReactNativeAppBuilder` and `ReactNativeWin32App`.

- Bug fix (non-breaking change which fixes an issue)

`ReactNativeAppBuilder`'s API surface made it too easy to call incorrectly and not realize it.

Resolves #13946

There are a variety of changes to the API surface:
* `ReactInstanceSettingsBuilder` deleted: not only are there are simply too many APIs that would need to be exposed to be useful, the very act of creating and replacing the app's `ReactNativeHost`'s `ReactInstanceSettings` with a new one is what caused the bug in #13946 in the first place
* `ReactNativeAppBuilder` now only exposes APIs to specify the intial, non-ReactNative, WinAppSDK types, (i.e. `DispatcherQueueController`, `Compositor`, and `AppWindow`), objects the app developer may already have created for their existing app, and otherwise is only responsible for building a `ReactNativeWin32App` with those types properly pre-made
* `ReactNativeWin32App::Start()` is now more responsible for the stitching together all of the relevant types to make a working Win32 fabric app
* All WinRT APIs without an immediate use-case have been commented out until we are sure they are necessary and that it is safe to expose them
* The template has been updated to follow the pattern of:
    * Use `ReactNativeAppBuilder` to get a `ReactNativeWin32` app with the base WinAppSDK types ready
    * Get and modify the types as necessary from the created app object (like the `ReactInstanceSettings` and the `AppWindow`)
    * Call `app.Start()`

N/A

Verified new apps and example apps in libraryes build and run properly.

Should this change be included in the release notes: _yes_

Cleanup ReactNativeAppBuilder and ReactNativeWin32App

* Update Guardrails on Provider Instantiation (#13961)

* Update Provider Guardrails

* Change files

* Format

* Update Snapshots

* Add very basic box-shadow support (#14028)

* Add very basic box-shadow support

* Change files

* Focus should notify island host when tab loop wraps to give host oportunity to take focus (#14026)

* Focus should notify island host when tab loop wraps to give host oportunity to take focus

* Change files

* Default scroll to bring a component into view should have padding around the viewport (#14018)

* Default scroll to bring a component into view should have padding around the viewport

* Change files

* Update focus visuals to use cornerRadius and inner/outer strokes (#14008)

* Update focus visuals to use cornerRadius and inner/outer strokes.

* Change files

* Format

* lint fix

* Scale focus border for scaleFactor

* [Fabric] Get Modal to host RN components in new hwnd (#13500)

* save state

* add example

* build but blank page still :(

* clean up comments

* visuals show up in new hwnd!

* clean up code

* better naming and unfork Modal examples

* testing save state

* Make the RN island a Modal member var

* Failed attempt at skipping root view in CEH, leaving it for learning purposes

* you can click on UI!

* clean up code

* Change files

* save state

* remove hardcoded rootTag

* add width/height to example

* add test

* revert simple.tsx

* remove test

* update snapshot

* feedback part 1: make Modal a RootComponentView

* feedback part2: simplify MountChildren

* fix deleting modal

* feedback round2

* remove comment

* remove imports

* feedback part 3

* fix overrides

* add simple layout - still has issues with padding/flex

* feedback part4

* lint

* update overrides

* Change files

* feedback

---------

Co-authored-by: Daniel Ayala <14967941+danielayala94@users.noreply.github.com>

* Support accessibilityState 'checked' (#13962)

* Implement accessibilityState checked

* Change files

* Add Testing

* Format and Update Snapshots

* Adjust Guardrails

* Merge

* Format

* Format

* Lint

* Change files

* Fix Merge Error

* Fix issue with prop cloning with custom native props (#14061)

* Fix issue with prop cloning with custom native props

* format

* prettier

* Change files

---------

Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>

* Export MS.RN.Color ctor in Office dll (#14082)

* Export MS.RN.Color ctor in Office dll

* Change files

* Implement TxScreenToClient and TxClientToScreen

* format

---------

Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>

* TextInput caret becomes visible on non-focused TextInputs on resize (#14091)

* TextInput caret becomes visible on non-focused TextInputs on resize

* Change files

---------

Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>

* Fix focus visuals being obscured by adjacent views (#14093)

* Fix focus visuals being obscured by adjacent views

* Change files

* update snapshots

* Fix uimplemented view

* review feedback

---------

Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>

* change files

* Build fixes

* fix

* Update Test Website to dotnet8

* update snapshots

* fix overrides

---------

Co-authored-by: Daniel Ayala <14967941+danielayala94@users.noreply.github.com>
Co-authored-by: Jon Thysell <jthysell@microsoft.com>
Co-authored-by: Chiara Mooney <34109996+chiaramooney@users.noreply.github.com>
Co-authored-by: Tatiana Kapos <tatianakapos@microsoft.com>
Co-authored-by: React-Native-Windows Bot <53619745+rnbot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: App Template Backport: Requested New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

When Using New App Template (with ReactNativeAppBuilder) In-App Defined Native Modules Are Not Automatically Registered

2 participants