Update the RNW and RN versions to the latest #11
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request closes #2
It updates the versions of both React Native and React Native Windows to the latest.
The version update procedure is described in the release note of 0.64.0 version, but it guides the developer to create new project and move the sources to the newer and empty one.
But this approach is more problematic, than just running the
reactnative-windows-init
in the existing directory.So for this project the following steps were made to bump the version:
npx react-native-windows-init --overwrite --version "0.64.4" The
--overwrite` flag ensures that no matter what file has been already modified in the existing repository, it will be replaced by the file of latest version.It also forces the developer to track the missing changes and reapply them in the further steps.
This step includes both including the files, but also setting their properties according to the type and purpose of the file. For example: NotesPage.h should be includes as a header but also should be dependent upon it's XAML implementation.
It includes all the sources and components, but also re-modifies the index.js file so it keeps the structure of the component from before the update.
After all thee steps it is necessary to rebuild and run the app to double check the migration results.
Why is the official approach more problematic?
The official approach should be quite straightforward when it comes to updating the version of a "pure JS* application, in which case only the JS code should be copied to the latest project. Although it is still not as comfortable and it's more error-prone as the procedure applied in this pull request, it should give the developer the comfort when it comes to the guide-following feeling.
But, in case of this app, there's much code implemented on the native UWP side, which is very difficult to just copy to the latest project. so in this case the better approach is to leave the sources where they are and launch the update in the "legacy" project.