4 ms·

On a more technical note - I'm exploring React Native (having significant experience shipping native iOS Apps) and while on the face of it React Native looks am

On a more technical note - I'm exploring React Native (having significant experience shipping native iOS Apps) and while on the face of it React Native looks amazing, as I go deeper into building something production quality, I've hit roadblocks with doing simple (natively) things like scrolling a scroll view to focus on a text field that's partially visible and changing the offsets of a scroll view to prevent the keyboard from masking the focused text field in a way that doesn't appear glitchy. Did you encounter any such problems?

jordwalke 11y ago
I've implemented one solution to this in FB's Groups App. Try that experience out and let me know what you think. Also, Nick Lockwood should comment here.
- cridenour 11y ago
  Is the solution something you can share on a general level? Would love to see how you approached it.
  - jordwalke 11y ago
    It's not incredibly advanced: It mostly just consists of measuring where exactly the current text box is in the scroll view, how high the text box is, and then having the scroll view scroll to that location, followed by fading in a docked text input right on top of the underlying one. It's pretty slick, but I'd encourage the community to recreate it in a reusable component and open source it.
- nicklockwood 11y ago
  We should hopefully be able to open source a cleaned up version of the solution that Jordan alluded to, but we have a long list of components we'd like to work on, and only a finite in-house development resource. I think it's important to understand that React Native is not an attempt to replicate the entire iOS native framework - it's a set of UI components that aim to provide a better developer experience for the common app development challenges we face at FB, combined with a framework for building new components. When we encounter an uncommon challenge (i.e. something that we haven't already had to solve and build a reusable JS component for), we simply drop down to the layer underneath and create a new native component. That's why I struggle to understand the argument that "React Native doesn't do this one thing I need, so I can't use it" - we put a lot of thought into the plugin architecture of RN, and making native plugins is trivial for anyone familiar with iOS or Android development. If there is something you already know how to do natively, you can leverage that knowledge to build an RN plugin and then get the best of both worlds. If you don't already know how to do it natively, there's a good chance that someone else already made a plugin that will do what you want.
alexashka 11y ago
What are you hoping to get out of using react native? This write once, use everywhere is such a strange desire. If you're a serious company, develop on iOS/Android first, then hire a dev or two to make an exact copy for the remaining platform. It's really not that hard. The hard part is doing something the first time and iterating. Copying is not rocket science - look at the Russian facebook clone - it's actually better because of copyright laws, you can do more on their version.
- EvanPlaice 11y ago
  There are two fundamental issues with the mobile first approach. Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication. The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time. Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences? Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale. The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.
  - alexashka 11y ago
    I understand the theoretical upsides to one platform/language to rule them all, absolutely. I am saying that trying to re-write the layout engine, data layer and all the rest to make it work the same on both platforms is not only a massive undertaking - it is ignoring the reason the platforms diverge to begin with. iOS has features Android doesn't and vice versa. Something that works on both platforms is always going to be a second-class citizen - it's the lowest common denominator. I don't want the lowest common denominator because it's 'easier for developers'. I want the best stuff. The theoretical technical debt due to writing on different platforms is why we have software architects and senior developers. Really, I've been part of a dev shop that does ios/android - the biggest hurdle is people problems, not code. People who don't know what a good app is or have any taste so they say first show me, then I will start asking for changes at random while insisting on a tight deadline. As for web/ios/android/desktop - this is a rare bird, if you need to support that many platforms, you can afford an architect and some smart people.

jordwalke 11y ago

I've implemented one solution to this in FB's Groups App. Try that experience out and let me know what you think. Also, Nick Lockwood should comment here.

cridenour 11y ago
Is the solution something you can share on a general level? Would love to see how you approached it.
- jordwalke 11y ago
  It's not incredibly advanced: It mostly just consists of measuring where exactly the current text box is in the scroll view, how high the text box is, and then having the scroll view scroll to that location, followed by fading in a docked text input right on top of the underlying one. It's pretty slick, but I'd encourage the community to recreate it in a reusable component and open source it.
nicklockwood 11y ago
We should hopefully be able to open source a cleaned up version of the solution that Jordan alluded to, but we have a long list of components we'd like to work on, and only a finite in-house development resource. I think it's important to understand that React Native is not an attempt to replicate the entire iOS native framework - it's a set of UI components that aim to provide a better developer experience for the common app development challenges we face at FB, combined with a framework for building new components. When we encounter an uncommon challenge (i.e. something that we haven't already had to solve and build a reusable JS component for), we simply drop down to the layer underneath and create a new native component. That's why I struggle to understand the argument that "React Native doesn't do this one thing I need, so I can't use it" - we put a lot of thought into the plugin architecture of RN, and making native plugins is trivial for anyone familiar with iOS or Android development. If there is something you already know how to do natively, you can leverage that knowledge to build an RN plugin and then get the best of both worlds. If you don't already know how to do it natively, there's a good chance that someone else already made a plugin that will do what you want.

alexashka 11y ago

What are you hoping to get out of using react native? This write once, use everywhere is such a strange desire. If you're a serious company, develop on iOS/Android first, then hire a dev or two to make an exact copy for the remaining platform. It's really not that hard. The hard part is doing something the first time and iterating. Copying is not rocket science - look at the Russian facebook clone - it's actually better because of copyright laws, you can do more on their version.

EvanPlaice 11y ago
There are two fundamental issues with the mobile first approach. Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication. The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time. Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences? Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale. The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.
- alexashka 11y ago
  I understand the theoretical upsides to one platform/language to rule them all, absolutely. I am saying that trying to re-write the layout engine, data layer and all the rest to make it work the same on both platforms is not only a massive undertaking - it is ignoring the reason the platforms diverge to begin with. iOS has features Android doesn't and vice versa. Something that works on both platforms is always going to be a second-class citizen - it's the lowest common denominator. I don't want the lowest common denominator because it's 'easier for developers'. I want the best stuff. The theoretical technical debt due to writing on different platforms is why we have software architects and senior developers. Really, I've been part of a dev shop that does ios/android - the biggest hurdle is people problems, not code. People who don't know what a good app is or have any taste so they say first show me, then I will start asking for changes at random while insisting on a tight deadline. As for web/ios/android/desktop - this is a rare bird, if you need to support that many platforms, you can afford an architect and some smart people.