Re:A monthly release cadence for React Native
by pps on Monday January 09, 2017 @03:14PM
(#13359418)
Hi guys, do you know if it is possible to create home screen widgets with React Native? I don't see any info about it in docs.
I'm thinking about something complex, like calendar or HabitHub widgets https://play.google.com/store/apps/details?id=com.rstudioz.h...
Re:A monthly release cadence for React Native
by orta on Monday January 09, 2017 @04:48PM
(#13360127)
This is great, I work on a pretty big React Native app ( http://artsy.github.io/series/react-native-at-artsy/ ) and keeping up to date with the latest version of React Native has been pretty tough when competing with product-based work items.
Re:A monthly release cadence for React Native
by mewwts on Monday January 09, 2017 @02:29PM
(#13359033)
React Native is great. Hands down, so cool to be able to go from developing websites to native apps. I also appreciate reading the release notes and seeing new features and fixes being released so frequently.
I do however experience real issues when upgrading. We tried going from 0.38 to 0.39, but getting the xcode project files to merge correctly has proved difficult for us, a couple of newbies. The new react-native-git-upgrade makes it easier to see the conflicts, but it is still hard for us to make it work. Does HN have any wisdom to share?
Re:A monthly release cadence for React Native
by ariabuckles on Monday January 09, 2017 @03:08PM
(#13359370)
My workflow so far (pre react-native-git-upgrade) has been to `git commit`, then run `react-native upgrade` and say yes to all the prompts, and then afterwards manually `git add -p` the changes that react native wanted to make to my files (the proposed changes made them "standard" and got rid of customizations, but also upgraded legacy parts from the original templates).
For each change, then, I try to upgrade any react-specific code while preserving my own changes to that file.
It's certainly cumbersome and I avoid doing it too often, but I've found this manageable.
Re:A monthly release cadence for React Native
by sheeshkebab on Monday January 09, 2017 @02:54PM
(#13359242)
React Native doesn't abstract mobile frameworks, so you still need to learn it all as far as iOS UIKit and Android SDK (and also learn React Native stuff on top of it).
That said, there is something about coding in mostly one language (javascript) vs 2 or 3 (Objc/Swift/Android) and also have that live app reloading.
In any case, this react stuff is not for beginners and won't make learning mobile platforms easier - you will still need to put in obligatory 10k hours to get good at mobile dev...
Re:A monthly release cadence for React Native
by roboguy12 on Monday January 09, 2017 @04:48PM
(#13360125)
Aside from the live reloading and being able to write in javascript as opposed to Swift/Java, the development paradigms of React is just better, IMO. The component-based design patterns and event-dispatching-based control flow just make so much more sense to me than the traditional Android/iOS way of doing things (I have experience in both the web and mobile). It's easier to test, easier to read/write, and easier to reason about. This is just opinion of course, others may not feel the same.
Re:A monthly release cadence for React Native
by dean177 on Monday January 09, 2017 @02:45PM
(#13359166)
Absolutely, if you already know react and are targeting Android only, picking up react-native will require minimal android knowledge, and the docs are great are walking you through the setup bits you need to get developing on-device.
Re:A monthly release cadence for React Native
by oakesm9 on Monday January 09, 2017 @03:10PM
(#13359381)
That's partly true, however as someone who uses React Native with multiple production apps, having "real" native experience is invaluable when using React Native. To create a good RN app you need to know how the system works and be comfortable jumping to the native side when needed. If you don't you're bound to create a sub-par app by trying to make everything fit into the web side which is all you know.
It is possible to create an app without native experience, but it is still needed to create a very good app.
Re:A monthly release cadence for React Native
by hafor on Monday January 09, 2017 @06:58PM
(#13361187)
In terms of how much React/JavaScript code you should expect to write vs. how much Native code for a production app, it obviously depends a lot on the app but maybe 80/20 might be a reasonable (if totally arbitrary) expectation.
You should only expect to write pure native code when you hit a performance barrier with some particular custom component you're creating and there isn't an existing JS api or a standard/3rd party component which does everything you need already. But when you do hit this barrier, wiring up your own natively implemented module is pretty straightforward.
Which is severe but has been open for so long just hasn't had any attention from the core team. It's clearly a massive problem and the packager code is... less than friendly.
Re:A monthly release cadence for React Native
by dean177 on Monday January 09, 2017 @02:27PM
(#13359018)
Its something which has a simple workaround, has no runtime impact and affects a minority(?) of developers using RN.
While it may be frustrating if this is affecting you, its certainly not a severe issue.
I have been part of development teams for two react-native apps, and nobody on either team has encountered this issue yet (with developers working on a a combination of OSX & Windows 10)
Re:A monthly release cadence for React Native
by evv on Monday January 09, 2017 @03:13PM
(#13359408)
I came across this issue last week and alerted the internal packager team about it. We'll get it resolved- even if the issue is avoidable, we can help people avoid it with better tooling, errors, and documentation.
Re:A monthly release cadence for React Native
by swah on Monday January 09, 2017 @04:48PM
(#13360120)
I'm trying RN now and I must say that for an outsider its very underwhelming, because one might expect more stuff to just work out of the box (surprises the last few minutes: back button not always handled, material design is a plugin, authentication doesn't have an example, etc).
Re:A monthly release cadence for React Native
by raspasov on Monday January 09, 2017 @05:10PM
(#13360273)
I disagree. From 0 to production, it took me 1 month. I had never done a mobile app before. Granted, I did have React experience on the web - that certainly helps.
I agree that the documentation can be better. My advice is - either contribute, or read the code. You'd be surprised how well commented and documented the code itself is.
Handling things like authentication would be falling into the trap of doing too much. A UI library/framework is an orthogonal concept to handling user registration or authentication. Material design? Let's say I don't like material design - then it'll be just extra baggage.
Re:A monthly release cadence for React Native
by swah on Tuesday January 10, 2017 @05:38AM
(#13363923)
Thanks for the heads up - I'll continue investigating. I'm thinking about my fav. Android apps (No iPhone since 3gs here) and really, some are material (say Recurrence, Gmail) and most are not (Waze, Pocketcasts..).
Re:A monthly release cadence for React Native
by evv on Monday January 09, 2017 @06:05PM
(#13360713)
Facebook is primarily focused on making React Native work great on iOS and Android. But the community is absolutely moving towards full cross-platform support. Windows is already supported, and there are promising experiments to run RN on Ubuntu, macOS, and web.
https://productpains.com/post/react-native/android-home-scre...
This will help the core team know what should be prioritized!
We're still on 0.34 ( https://github.com/artsy/emission/blob/master/yarn.lock#L484... ) now I feel guilty.
Glad to see the project start to stabilize.
I do however experience real issues when upgrading. We tried going from 0.38 to 0.39, but getting the xcode project files to merge correctly has proved difficult for us, a couple of newbies. The new react-native-git-upgrade makes it easier to see the conflicts, but it is still hard for us to make it work. Does HN have any wisdom to share?
For each change, then, I try to upgrade any react-specific code while preserving my own changes to that file.
It's certainly cumbersome and I avoid doing it too often, but I've found this manageable.
Last time I checkes, there was still rather much mobile know-how needed :/
That said, there is something about coding in mostly one language (javascript) vs 2 or 3 (Objc/Swift/Android) and also have that live app reloading.
In any case, this react stuff is not for beginners and won't make learning mobile platforms easier - you will still need to put in obligatory 10k hours to get good at mobile dev...
It is possible to create an app without native experience, but it is still needed to create a very good app.
what is a good balance between RN vs pure native? what works and what doesn't?
what about other considerations like power consumption..file size, etc?
Here's a good high-level talk which touches on the balance somewhat: https://www.youtube.com/watch?v=abSNo2P9mMM.
You should only expect to write pure native code when you hit a performance barrier with some particular custom component you're creating and there isn't an existing JS api or a standard/3rd party component which does everything you need already. But when you do hit this barrier, wiring up your own natively implemented module is pretty straightforward.
https://github.com/facebook/react-native/issues/4968
Which is severe but has been open for so long just hasn't had any attention from the core team. It's clearly a massive problem and the packager code is... less than friendly.
While it may be frustrating if this is affecting you, its certainly not a severe issue.
I have been part of development teams for two react-native apps, and nobody on either team has encountered this issue yet (with developers working on a a combination of OSX & Windows 10)
I agree that the documentation can be better. My advice is - either contribute, or read the code. You'd be surprised how well commented and documented the code itself is.
Handling things like authentication would be falling into the trap of doing too much. A UI library/framework is an orthogonal concept to handling user registration or authentication. Material design? Let's say I don't like material design - then it'll be just extra baggage.