19 de Diciembre de 2018 · 3 min de lectura
The mobile team at APSL has always been a driving force of innovation. Since we moved from Ionic Framework to React Native, we have completely transformed not only our mobile team, but also influenced the front-end projects we deliver, introducing React, Flux architecture for better SPA apps and a lot more of different practices and architectures.
During our first steps with React Native, we have faced many of the issues other React Native devs have experienced out there. Being a small team, oriented to fast delivery and iteration, sometimes our capability of taking a step aside to do internal engineering stuff gets compromised. That, however, doesn't mean we haven't been able to collaborate with the React Native community with PRs, libraries or PacktPub courses.
One of our main contributions is the react-native-keyboard-aware-scroll-view library. Basically, this library enables us to gracefully handle the most common case of
TextInput positioning on React Native apps. Turns out that something that was a pain point for us in the beginning of our React Native days is something that also has helped a bunch of other devs out there. Today, we're glad to have hit yet another huge milestone for the APSL mobile team, we have passed the 3.000.000 downloads barrier.
I'm sure many of you are wondering right now why we haven't fixed the 20-something issues we have at this moment and I want to take advantage of this post to give a more detailed answer. Since day zero, our policy with OSS at APSL has been the following:
But, what does this mean? Simple, it means we're customer and project oriented. We will prioritize always what our projects need and those things will always go first. Then, we will fix or add things when we need them. If the stars align and we find ourselves with a couple of free days to do OSS, we will try to solve what we think will be useful for the team. Also, it's an open source code, so you can send us PRs or even fork the project and everything you need.
This policy may change in the mid future, but it's not going to get away soon. This is one of the reasons we have developed our common components library InterfaceKit as separate repos and components (although we may join them into one multi-package repo with Lerna). With this separate architecture we can avoid bloating our component library and also we can assure that changes won't affect sibling components by any means.
I hope you found this read interesting and please, if you have any questions, do not hesitate to reach us at amedina or amoreno at apsl.net (email) or in our Twitter profiles.