Home
If you're an engineer working on the WeVote WebApp and are looking to get started to contributing to the ReactNative project, this is the place to be!
First, we have to ensure that the projects are running in the simulators properly.
If you are interested in working on the iOS project, ensure you have xcode installed on your machine. If you are interested in working on the android project, ensure you have android studio installed on your machine.
Next, clone the repo from your fork and do npm install in the root folder. This'll ensure all the dependencies are taken care of.
This State Of The Codebase wiki page is like a whiteboard of the current state of the Native project. Feel free to update it with new knowledge and clues for our developers.
This has been done for you, but is really complicated, and if something goes wrong there is a good article that describes the background.
The master branch is kept for a working version from which we will periodically merge snapshots of develop branch from. develop is a branch which will always be functional for anyone to test out.
Both iOS and android do have a common codebase, which is contained in the App.js file under the js/scenes directory. App.js is called on startup from index.android.js and index.ios.js. which as of October 2017, are identical except in name. In the few places where there is platform specific code, we use the { Platform } component from 'react-native' which can be queried as follows (Platform.OS === 'ios').
Additional platform-specific code can be added to ios.index.js or android.index.js for iOS and android respectively.
The file structure we are maintaining is flux-based, and kept as close as possible to the WebApp project. What this means is that most of the backend libraries will work as they are. The main changes that have to take place are with the frontend/UX part of the app. Luckily, we have some great libraries for doing so (see react-native elements).
The latter two don't have the community backing and stability that the former does. Based on the research I've done, the best option for LTS and compatibility with future elements is most likely react-native elements.
react-native-router-flux v4, built on top of react-navigation is how we will manage navigation. The native codebase still has many { Link, browserHistory } calls that come from the "react-router" library that we used in the WebApp, all of those calls need to be converted to react-native-router-flux functions like Actions. All of those Actions need to have routes defined in js/scenes/App.js
Just follow the same structure that we already have in place in terms of files. .jsx files will have to be renamed to .js files.
Starting from the routes or what we call scenes in react-native, place the required scene, and work your way backwards, adding all the required actions, stores, utils, etc,. which are required.
Once that's done, it's recommended that you comment out imports, focussing to get a singular aspect rendering correctly.
React-native does not use HTML, so all the <div> and <span> tags roughly translate to <View> and <Text> tags, and most <Button>s translate to <TouchableOpacity>. It will require additional tweaking. React-native had a good set of standard components, try to use those first, before adding in other external libraries .
React-native standard components here..
We use the react-router library in WebApp. We can use the react-native router library for react-native.
For svg-icons, we use react-svg-icons in WebApp. I recommend using react-native-svg to handle the same for react-native. An alternative would be to use the ART library which is a part of the actual react-native library, and just requires linking. The issue with the ART library at the moment, is the lack of documentation. In the future, that is what we should be looking at.
onesignal (push notifications)
js coach (popular react-native packages)
codepush (to manage app updates)
