React in the eyes of the great God native--spare

When I first tried reactnative, I thought it was just a astray for web developers to get involved in native mobile applications.

I think it's really cool that a JS developer can use JavaScript to build the iphone app, but I quickly gave up the idea of using it. After all, I've been working on iOS native for a hobby for years, and I'm already familiar with this set of development tools.

I've created some of the iOS apps I'm proud of--some apps built with Object-c and Xcode, and that's usually what people do. These two tools are provided by Apple to develop iOS apps, so I'm using it with other Apple developers. And when Apple released Swift two years ago, I didn't hesitate to try it.

Swift is still being used in Xcode and is still the recommended development method for Apple, so I quickly went deep and learned the language effortlessly. I am content with my Apple ecosystem circle. React native looks like just a little fun, in my mind, all native applications must be developed in the native habitat. For me to start mastering the native development approach, learning JavaScript (I don't have this experience) and an almost entirely new way of building apps is a waste of time.

Fast forward to a few months later, I can play promise said, I will never use OBJECTIVE-C or Swift to develop iOS apps.

We took over a new mobile app development project, and I probably looked at the design and requirements. Just as I was going to open the beautiful blue icon of Xcode. When creating a new project, our interactive designer, Adam, came to the point, "Let's do this with react native." ”

He explained that part of the project contract explicitly mentions the need to make an Android version of the app. Although react native does not support Android, we know that Facebook is actively working on this. Theoretically, if we built the iOS version of this app with RN, many parts would work directly on future Android versions.

Well, I'm not happy. I feel like I'm on the cusp of iOS development and now I'm going to throw it all away. In the face of the inevitable learning curve, I wonder if I can release a high-quality product in a timely manner. But beyond that, I question whether RN is capable of producing a high quality product. It seems to me that I do not even find this question unfair. At that time, the RN as a beta version was just released shortly, the documentation is scarce, the number of open source libraries and builds is sparse, the demo code or the reference on stack overflow is almost absent.

I don't even want to look at it. But my closed attitude will only lead to more negative consequences. My first hurdle is learning how Flexbox,rn makes UI layouts. Starting with the most basic interface builder, using purely code to lay out the UI almost overwhelmed my confidence. I struggled to build the most basic visual effects.

But it's not just ui--that everything is different. This is the biggest challenge for me.

"Whenever I stop or I don't understand, I tell myself," If I use objective-c, I can solve it in five seconds. " Whenever I find a bug in Rn (and the number of bugs is very large), I think, "there is no such bug in OC, why must I fight with RN?" ”

For two weeks, I struggled at work. The way I feel about myself has turned from a great iOS developer to someone who has never written a single line of code. It was a setback until I spent a whole week clearing the train of thought. I took a step back and realized that Adam had done a lot of research on RN. As my interaction knew, I had to trust him, believing that he had not led me into a wrong way. I swear I'm going to get into work in Monday, working hard, pretending objective-c and Swift never existed, and solving this project.

Learn to like react

A few weeks ago, we provided the App Store with the first react native app. I'm really proud of the end result of the application, and I can't wait to start building the next project. In just one months and a little more time, I completely embarked on the pirate RN, what changed my mind?

React Example

In react, all UI components are placed in the render () method, and are controlled by state status. Your render () method defines how the UI is presented in various states. When you call SetState (), react will find the part that needs to be changed and modify it for you. Imagine a simple view that has a "Hello World" tab and a button. Each click of a button will toggle the label between "Hello World" and "Goodbye World". In objective-c, I need some embarrassing if declarations in the handle of the button, just like the following.

2. if([label.text isEqual:@”HelloWorld”]){
4. label.text =@”GoodbyeWorld”;
6. }else{
8. label.text =@”HelloWorld”;
10. }

This is useful, but this UI code is completely out of line with where I first created the tag, possibly in code or in the interface Builder. In react, we define a buttonclicked bool variable in state, and in the render () function, the label looks like this:

1. <Text>
2. {this.state.buttonClicked ? ‘Hello World’ : ‘Goodbye World’}</Text>

And our button handles are very simple.

1. this.setState({buttonClicked:!this.state.buttonClicked});

All the code associated with the visualization is in the same place and is controlled by the state. This makes it very easy to understand and fix this code.

Flexbox

This is the UI Layout tool I hated at first, and now it's become one of my favorite things in Rn. I admit it's very difficult to master at first, but once you start using it, it's quick and easy to build a UI for many different sizes of screens. I have been very enthusiastic about the Visual interface Editor in Xcode, and its automatic layout is a complex Mandarin compared to flexbox. The CSS style used by Flexbox makes reuse of styles as simple as copy-and-paste. The best thing to do is to allow you to change the value of the style to perfection in a moment.

Live/hot Reload

Yes, I want to see the button move right 5 pixels is as simple as command+s. The React native can be set to automatically redraw the current screen in the iphone emulator without rebuilding the Xcode project. It's very powerful because you can save time not only by avoiding recompilation, but also by adjusting a deeply nested interface in the app, adjusting the UI without going back to the original interface.

Android

It's still not released, but it's fast-it's going to be amazing. At first I was hesitant about reactnative because I was used to doing native iOS development. I've never had any complaints about it. But I have also done the native Android development, which is not a happy person. React native on Android will be very thin welcome, at the same time I am also looking forward to its release. This will change the status of mobile app development by using the same code to deploy two-platform applications.

Review Miss Xcode

I still miss Xcode, or an IDE editor. I've got a good RN development setup, but it's not easy, Sublime text and a bunch of plugins let me have syntax highlighting. Sublime is able to complete the automatic completion of variables based on the same file, but it is always less robust than some Xcode auto-completion. I still have to search the developer documentation for reference.

Small drawbacks, like typing the REACT.PROPTYPES.F IDE doesn't tell me whether I'm looking for func or function, which is confusing. I also miss the version control of Xcode-allowing me to compare my last git commit and the current version, and even allow me to undo some special changes based on the line. I realize that third-party programs can help me do this, but the best thing for the IDE is to include them in a package. (translators use Vscode to solve these problems)

In order to run the RN project, I need the terminal to run Npm,chrome to Debug,sublime to edit the code, and eventually I need Xcode to run the project and open the emulator. These are small complaints in big projects, but this is still a drawback when I face Rn. For Nuclide (Facebook's new IDE) I have high hopes that it will end all of these shortcomings.

Bridge connection

Facebook has not and will not be able to provide all the iOS steering react native APIs, so for those missing fragments they provide a way to bridge JS. When I first came into the RN, the documentation was very bad. Whenever I realized that I needed to connect something, I almost gave up on Rn because these things would have been able to work in objective-c. But when they explained the bridging process in more detail and provided excellent examples, there was no fear. It's still a hassle, but I can see that the open source community and nom have some bridging options. In fact, most of the iosapi already exist.

Vulnerability, documentation, open source community

Probably all my initial complaints about RN are now gone, if I start studying it today. The vulnerability is fixed every day, and the new version is iterated every week. The document still needs to be added, but much better than before. Facebook and the open source community have become very rigorous about developing this framework. People began to gather on GitHub and stack overflow to explore it. If you're an iOS developer considering trying RN, you know you're not alone in the fight. RN is great, you should embrace him with an open mind. Don't be like me, you're confined to the greenhouse.

React in the eyes of the great God native--spare