I wrote my last
article a few days later, after I even started poking around in react native, before having experience only in native development for android and iOS. After this time I have already managed to work on a real react native project. And now I want to highlight all the obvious and non-obvious moments that I encountered at the time of working with a real project. Anyone interested under cat.
Instruments
Once again I want to highlight the topic of working tools. React native is not yet very close to the version, at least, 1.0, which is why the lack of a fully working and sharpened IDE for this product. Although, suddenly, I came across this:
Deco IDE . Yes, this is a real IDE (only for macOS for obvious reasons), and yes even
purchased airbnb. But not everything is as rosy as it turned out. Yes, you can “program with the mouse” by simply dragging components into the code. Again, there is a list of components, you do not need to go to the office every time. site to find out which component is still there. It is also possible to start a project with just 1 tyk (but only iOS, there are always problems with android). But that's all the chips and ends. There are no quick transitions to the components on the click with the cmd clamped, there is not even an adequate linter and auto-completion. In terms of coding functionality, this is a simple notepad that only a non-closed tag can highlight. But now this tool is occupied by a large company, I hope for its rapid development.
In most of the videos about react native, as well as in the screenshots of various articles, I saw
VS code everywhere. The piece is really quite good, the eslinter is easily hooked up as a plugin, you can pick up a flow, there are autocompletions and even transitions to components. There is an embedded git and even an integrated terminal. And I would use it too, but there is a huge minus for me - by default each open file opens in one tab, as if replacing the previous one. To open 2 tabs with different files, you need to start editing in the file, then open another one, which will open in the second tab. If you just need to quickly view 2-3 different files, the
upholstery on the chair has to be changed, which brings some discomfort.
Therefore, I still stopped at
Nuclide , however, picking up a
flow , which greatly improves autocompletion, adds quick transitions to components on click, plus all the chips with typing. About beautiful and convenient launches of projects in 1 click so far you have to forget.
')
Work with the camera, map and other complex things.
This is perhaps the most interesting question for all. The bad news is that there are no default components for the camera and the map. It is necessary to use the native code. The good news is that everything has been done for a long time:
- Airbnb wildly cool cards . I used it personally, everything works fine on both iOS and Android, it is also very customizable.
- The camera is already there. Although I did not personally try it, there was no need, although it was curious.
- In geo -position, good, out of the box.
In general, there are already a lot of working components, you just need to google it. But you can write yourself.
The working process
React native has only 1 problem -
android problems with android. I don’t know if it’s a problem of the system or of the developers that put the bolt on the android, but there’s always some strange jambs with it.
The strangest case: Date translated into a format string: “YYYY-MM-DD HH: mm: ss” has different lengths of characters on iOS and android, guess which platform has an extra space? Which simply leads to a fierce pair, it would seem that the code is on pure js, everything works fine on iOS, and on an android something can go wrong. Therefore, it is ALWAYS necessary to check the application on both platforms after ANY code change, you never know what the problem may be.
In fact, this problem was rare for me, for some reason, the Date works crookedly on the android, but the momentJS is fine. So immediately use the latter. But with the layout problems of a different nature.
First, the android does not know how to in the shadows, which are indicated in the styles. There is a separate parameter for it - 'elevation', but that's all. The color of the shadow, radius, transparency - all this passes by the android.
Secondly, the screen resolution. Yablofonov just huge resolution, especially in the pros, from which, there are problems when you expose the buttons with the correct font sizes, on iOS everything looks good, on the android everything sticks together - the screen will be too small. Fortunately, react native makes it possible to determine the platform on which the application was launched, and thus change something in the code, for example, styles.
As for the development process itself, it is difficult to describe the feeling of freedom that you gain after the native development for android. The Android SDK gives us tools designed for something specific, from which it is impossible to depart from. It was invented that there should be an activity in which the class is hooked up to the layout, and at least what you do, but there must be an activity, even Google itself cannot do anything about it. Here they gave us data binding, and using this library, the activation is used as a crutch in 99% of cases, just to pick up the layout and ViewModel, passing the Model along the way, although we have explicitly specified both model and ViewModel in the layout. Absolutely no logic in this case, there is no, but there is aktiviti. Intent is needed to transfer information, and it can transfer only simple types without problems, and if you want to transfer an object, then hello Parcelable.
And there are a lot of such examples. In the case of react native there is only ... JavaScript and that's it. You yourself decide how to make this or that element. That is why you can use as many as 3 different libraries for navigation:
Anyway, any task can be solved as you like (well, almost). And this is the most interesting in the reagent.
Components
Special mention deserve the components. For the guys from the web, this is a familiar tool, but for us, the guys from mobile phones is just a silver bullet.

Here we have 3 different buttons. Actually not different, it is one component. Understand the scale of the steepness of the components? Here you can forget about copy-paste in the layout from the word “absolutely”. Yes, in android there are styles that theoretically should save us from copy-paste. But after all they are applied to pure components. Yes, I can set the button style, but to make a button like in the picture above, one button in the android will not work. This is a whole separate layout, where there will be both TextView and ImageView and all of this, as well as layout will have its own style parameters. And all 3 buttons will differ also by different amounts of these components, somewhere there are no pictures, somewhere 2 texts, etc. ... In other words, it’s impossible to make all these 3 buttons on an android 3 times. Well, how do you do it in the reactor? There are 3 pinches of magic:
- Props
- Display only those elements that exist
- Style overlay
More about everything.
In android, we first create the component in the layout, then we find it by ID's name in the activation and pass some parameters, for example, we change the text. This works if we know in advance what we want to display. In the reagent, we indicate which component to create with the parameters we need. What is the salt? In props, we can transfer EVERYTHING ANYWHERE, without any problems, ranging from simple types to objects. Suppose we need another 1 button, the same as in the middle, only with another arrow. In android, we are running to draw the 4th button, and then we just pass another icon through props.
But more magic is happening here:
{true && <Text> </Text>} {false && <Text> </Text>}
The point is that it is possible not to display non-existent objects. After all, we use JS with dynamic typing, and it can be conveniently used for ourselves, for example:
const text = this.props.text; {text && <Text> {text} </Text>
If we passed the text parameter to props, then the component will draw it, and if not, it will not, because why? It is worth once again to focus on the dynamic typing. With the text, everything is fine, the text is - true, there is no text - false, also with objects. But with the numbers of trouble, send 0 - JS will think that it is false ... For numbers, it is better to more clearly check the type.
The logic starts to reach? We are making a component that takes into account all the possible options for what is in it, wrapping them in the design that I presented above.
And here another problem may arise - too big text, too big picture and so on can break the appearance of the component. Here point 3 comes to our rescue:
<Text style={[styles.defaultStyle, this.props.customStyle]}> {this.props.text} </Text>
Style we define as an array of styles. What does it mean? This means that if we have NOT transferred our style to props, then the component will be in default, which we defined in advance. But what if we pass 1 parameter into the custom style, say, indent from the top? And this component will have default style plus indent from the top. The point is that the default style is always FULLY applied, only it replaces only the parameters that we pass in the custom style. Those. if we only want to change the color of the text - it doesn’t matter, dimensions, indents and other joys will not fly off. And if we don’t need any parameter in the style, we give this parameter with the value null in the custom style.
Conclusion
You can also mention working with data through redux, but this is a separate philosophy, designed for full-sized articles. I will say for myself, after the native development, I went through all 5 stages of making the inevitable when I worked with redux. But then I got involved and very much began to respect this approach.
The main question for whom react native? Yes, for all. When making a product, you need to keep 2 teams of developers - for iOS and android. Immediately enough, and one. Firstly, it is stupidly cheaper, you need 2 times less people, and secondly, it is convenient - a bug appeared, corrected immediately on 2 platforms. And serious guys, too, began to
get involved . There is not only Facebook and instagramm. Airbnb, walmart, testa, I think these guys know something)
And then, the project is not even close to the release of version 1.0, and they are already interested in many famous guys who
come together to develop the project. We have a unique chance to get on a train that has not even reached the station, but not on the train leaving. All who mastered this tool (especially those who have experience in native development for mobile phones) before the mass release of version 1.0, will have a huge advantage over others.