Main layout of the application #3
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The main layout of the application is divided into sections, each containing crucial options and features. The main App class component should be responsible only for calling widgets provided by separate components' classes.
The initial thought is to divide the application into three main panels, each providing separate functinalities: * UserAccountPanel - responsbile for handling user's login/logout actions, user's info displaying, user's account options * LeftOptionsPanel - panel containing options related to the notes: adding, removing, etc. * NotesMainPanel - responsible for displaying the main content of the app - Notes. Each note will be represented as a Touchable widget with UI elements. This commit adds the components only with the Placeholder text in them.
Each panel has been provided with styles (width, height, most basic behavior) and it has been marked with the border to mark it's position in the application window. The Placeholder text has been replaced with the panel's name.
The architecture of the whole application system is based on the navigation between separate components implemented in the React Native. These components are to be rendered as the UWP's Page content, just like in the original RNW application. The difference is, that in this approach each RN Component will be rendered inside separate Page as it's own ReactNative Root View. This approach requires all Components to have the separate Page implemented, each containing XAML scheme, IDL implementation and it's code-behind implemented in native C++.
The NavigationView is a native UWP control which is able to easily create navigation panel and provides developer with embedded event handlers. More can be found here: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/navigationview Using this control each page given as a tag is converted into TypeName and directly invoked as a type to navigate to.
BartoszKlonowski
added
C++
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 adds the main layout of the application.
This implementation can be treated as the base for further development. It adds three separate screens which will contain all the logic and includes the navigation top panel which is UWP's native control.
The whole layout of the application contain three main layers each handling different abilities of the React Native and UWP:
and they can be described as the following:
This is the root of whole application. The NavigationView acts as a handler of all the actions that can be done on the UWP's Pages registered in the application.
It is the fully native UWP control, which contains
navigation items - responsible for keeping and wrapping registered Pages
and the Frame - responsible for handling the navigation with native animations
This layer is implemented using only the native UWP and XAML languages. It also brings in the standard code-behind approach used also in WPF and other frameworks.
These are the most standard and well-known JS classes extending React's Components. They are the main core of the application - each contains the logic which is to be used in each screen. That's why they are implemented as totally separate components and they are also registered each via a separate
AppRegistrycall.Using the JS approach in the middle gives the ability to utilize the React Native's advantages and, beside having native UWP controls at the top, implement all the features using fancy community modules and components.
Anything that can't be made using the JS or React Native's community modules, or anything that requires native approach is handled by the native modules and native UI components utilized by the JS Components above.
This includes various C++ tricks, UWP fancy controls and animations, tools available on the native side.
The results are as below:
The implementation is done step-by-step, so in case of any questions or doubts please see the commit messages, or commits implementation.
Why dividing the application into separate components?
There were two main reason for giving up the React Native's "App.js-approach":
One is that it should ease the development, as each screen is the separate part handling separate part of business logic and separate screen look (controls, widgets...)
The second is that this is one of (if not the only) way to use the
NavigationViewand register other pages in the application as well.What about the MVVM?
Yes - standard code-behind approach is used less and less often, leaning to the MVVM pattern which of course has it's abilities.
In this case though, the focus is on JS layer and all the screen's implementation done in them. Which leaves the backend at it's best practices at the end of the line.
MVVM allows to easily connect the logic with view using the XAML bindings and it's perfect for huge applications implemented in UWP, but for application this size that would be an overkill. Moreover it's not that the code-behind is a bad practice, not at all. It's still used and has it's advantages, so it can be safely used for this app.