

Custom Native iOS Views with React Native - almost
http://almostobsolete.net/react-native/custom-ios-views-with-react-native.html

======
untog
All this makes me realise that even if React Native isn't the best way to do
what it's doing, the sheer amount of support it has will make up for it.
Within a month I swear it'll have more custom plugins than every other
"compile to native" framework out there...

~~~
iLoch
Having used React Native for two months, I can confidently say it's the best
way to do what it's doing. Native is garbage (overly complicated), web is
garbage (for now, maybe?) and as for solutions using a JS bridge like React
Native, I think RN does it best. Easy to use and extend, and has default
support for one of (if not the best) JavaScript framework available right now.

------
joeblau
What's interesting about this example to me is that Apple is moving away from
programmatically laying out your views. I wonder what the tradeoffs in
building a complex view are vs just using Interface Builder, constraints, and
size classes.

Also outside of Facebook Groups, which other apps are using React?

~~~
stephenson
It feels a bit unfair to expect more apps to use React Native at this point,
it has only just ben open sourced.

~~~
joeblau
Oh I didn't expect many, I just wanted to know what's been published that uses
React. I want to test the apps and see if they live up to the hype. For the
past six years, I've tried so many non-Apple frameworks for building iOS apps
that I gave up about 6 months ago after Famo.us.

~~~
vjeux
React (outside of React Native) is being used on many high traffic websites.

\- Facebook comments, chat, search, ads creation, photo upload, tablet
website... and basically every new product being written.

\- Entire Instagram website

\- Yahoo Mail: [http://yahooeng.tumblr.com/post/101682875656/evolving-
yahoo-...](http://yahooeng.tumblr.com/post/101682875656/evolving-yahoo-mail)

\- A lot of the Khan Academy front-end: [http://khan.github.io/react-
components/](http://khan.github.io/react-components/)

\- Netflix website and TV experiences:
[http://conf.reactjs.com/schedule.html#beyond-the-dom-how-
net...](http://conf.reactjs.com/schedule.html#beyond-the-dom-how-netflix-
plans-to-enhance-your-television-experience)

\- Many Airbnb new products: [http://www.slideshare.net/spikebrehm/the-
evolution-of-airbnb...](http://www.slideshare.net/spikebrehm/the-evolution-of-
airbnbs-frontend)

\- Flipboard mobile website: [http://engineering.flipboard.com/2015/02/mobile-
web/](http://engineering.flipboard.com/2015/02/mobile-web/)

\- ...

------
amelius
Does React Native support everything that React in the browser supports, and
vice versa?

Can browser-based react apps be converted to React Native apps with the click
of a button?

~~~
underwater
Not out of a box. There's not a huge difference in environments but automatic
porting was never a design goal. React Native follows the mantra "learn once,
write anywhere" instead of "write once run anywhere". The main differences
are:

* React Native has its own primitive components (Text or View) instead of primitives that map to standard HTML elements (span, div).

* React Native's runtime environment won't have all the browser APIs (DOM, navigation, web storage).

* React Native uses a subset of CSS and exposes it through the JS API instead of relying on the browser's styling (and separate CSS files).

That said, porting components is trivial. If you have a library of core
components (Buttons, Menus, TabBars, etc.) then porting just those to the
native implementation gets you most of the way there.

It's also possible to alias Text => span, View => div, etc. and use React
Native's css-layout library on the web. But that won't help for legacy
applications.

~~~
pests
While I've had no problems with React's coupling of components controller and
view in one location, doesn't this suggest that it should be separated? One
view for web, one for RN using the same state and controller?

~~~
underwater
That's how we've approached the apps I've been involved in. Your Flux or Relay
stores and non component modules can be shared.

This isn't a hard and fast rule, just an acknowledgment that different
platforms have different constraints and conventions. If you try and share all
your code then you'll end up designing for the lowest common denominator, and
your app will feel out of place.

