A talk I gave at Montreal React Native Meetup (July Edition).
Talks about the experience we did using React Native for a mobile application development project. Gives an overview of the post-mortem the team did at the end of the project. Subjects are the current good and pain points of React Native in mid-2017 as well as actions that had been decided to diminish the pain points and increase the good ones.
5. The Good
Excitement among the team.
Improved team cohesion and spirit.
Developers found it easier to keep a clean architecture.
Quick on-boarding for new comers on the project.
6. The Good
JavaScript language has been liked by the team.
Reduced developers assigned to project for same overall
quality.
Plan B (native integration) was available.
11. Actions
Inconsistencies between platforms: update react native
more often and best practices knowledge base.
Navigation is still a pain point: continue following trends on
navigation (react-navigation & native-navigation mainly).
Packager is not always cooperating: check if Haul could be
a good replacement.
Could come with more “batteries”: start integrating Expo.
12. Actions
JavaScript dynamic typing: use Flow.
We had to define our architecture: start from great
boilerplates (Futurice/Pepperoni, Infinite.red/Ignite)
Could be harder to sell to native purists: do our best to make
the experience painless.
First Samsao web + mobile project
Opportunity to share code between three projectsEvaluated close to native only technologies
Evaluated NativeScript and React NativeChose React Native (for renown and knowledge base)
We will start with the good points raised by the team
* Everybody was excited to try React Native and all the related tools.* Greatly improved the cohesion between the team, was much more easier to share knowledge and to get help from everybody. People were more involved since logic is shared between iOS & Android.* Thanks to React sub-components, people found it easier to have the logic correctly encapsulated in meaningful components.* New comer were able to effective very quickly (it wasn't perfect but was pretty good)
* The language was liked by the team in general. Dynamic typing was a double-edged sword causing fun and pain points. They had heard bad things so expectations were low but they were surprised and happy in the end. Still need static type checking however, The Bad).* For a similar project as the one we did in React Native, we were able to cut the developer by almost 2 (1.5 would be more realistic).* We always had an exit way if anything would not work as we would like on React Native. * Having a plan B just in case ready helped us go in the right direction.
* Layouting issues (position: attribute, tapping inside scrollviews), differences between supported attributes between iOS and Android, Android is always a kind of second-class citizen, less performant.* As you probably know, navigation, even if being actively worked, is still a pain point. We had tons of problems preventing Android back button to happen.
* Had some caching issues where something was working on local machine and not anymore one someones else machine. Harder to debug problems.* We had a hard time doing stuff that were so easy to do in native. Like adding a splash screen as painful. We needed extra libraries for easier widgets creation.
The dynamic nature of JavaScript was harder to work with for new comers and those that don't work often on the project. For example, it was hard to know something what was the actual real type of a variable. May have been caused by a bad architecture however.
React Native is really in the end a library that a full development framework. As such we needed to define what architecture we would like. An due to bad start, it did not go well. Started with Redux, team was not seeing the benefit immediately, dropped, switch to an MVP inspiration.
It was a point raised that some people could be refractor to changes, career decision, etc.
Two actions were decided, update react native more often to reduce number of inconsistencies. Create a best practices knowledge base for layout and view implementation to reduce new comers hitting those problem in the first place.
No real definitive solution right now, we still monitor react-navigation for improvements and looking at Airbnb native-navigation router that could be a replacement. We still need to make a proof of concept with to see what it can do.
We heard about Haul recently and it seems to be a good replacement candidate for packager. Implements the same server interface but based on web pack, which we know a lot. Could have a better extensibility.
We started integrating Expo library (not the full framework yet) to reduce the gap between current react native state and what we would like it to provide.
We already started integrating Flow into our next project. Overall, it’s great but we had some drawbacks (avoid the @flow annotation, dependencies analysis). We have thought about switching to TypeScript, we might change later on, will see.
Our next project has an architecture based from both pepperoni and ignite (smart/dumb containers, redux, project layout) but switch redux-sagas to redux-observable. We had prior experience in Rx so it was more natural.
Reduce learning curve, on-boarding, knowledge transfer, mentality switch (the right tool for the right job).