...
- UI components: The tangible UI elements, screens, controls, etc. These should have the ability to work in different contexts (e.g. course_list works in different screens and use cases).
- User workflows: Workflows encoded on how the user interacts with the UI elements as well as background components. This includes the navigation routing using react navigation library.
- Webservices: Services that allow external interaction with Totara Mobile plugin. This is done using Apollo Client
- Storage: Location where the app maintain the data state of the app and persists data. The persisting happens using AsyncStorage and one of the main libraries for Redux is
redux-persist.
App
...
code layout
The mobile app will be organised in the following way.
- @totara/action: Redux actions
- @totara/auth: Authentication screens, flows and related utils. This code might be moved to /core shortly
- @totara/components (Typescript): These are the generic none specific UI elements that are used throughout the app (e.g. buttons, panels, etc.). These components are pure and stateless or have only local state.
- @totara/core: This folder contains essential components and utils for the app authentication and other critical flows
- @totara/features : This is a particular feature of the app such as:
- root (Javascript): The specific screen components that contains the feature. It is also at this level which appropriate container to show on particular device screens capability are included (e.g. small phone, extra large phone, tablets, etc.). This uses Javascript only instead of Typescript.
- API (Typescript): Where data centric and background code lives.
- @totara/lib (Typescript): Code for functions/helpers and non styling constants that are used across different areas. In other words, this is the place where we put utilities and utils files.
- @totara/reducers: Redux reducers
- @totara/theme (Javascript): Code theming and UI.
- @totara/types (Typescript) : Types, schema, and domain model of the mobile app.
| Note |
|---|
@totara/lib can't depend on features, also one feature can't directly depend on another feature. Make the interface clear on a per module basis. e.g. lib is function calls, features are routing info, etc. |
...
- Inputs: Navigation params and API access through graphQL queries and subscriptions, as well as Totara dependency
- Outputs: Navigation params to other features, user interaction and graphQL mutations
@totara/activities
Here is where you can find different learning activities that can be performed in the app. From react convention this package has the following containers (these are included inside @totara/features):
- Inputs: Activity through react context and API access through graphQL queries and subscriptions, as well as Totara dependency
- Outputs: Navigation params to other features, user interaction and graphQL mutations
...