 Hai So, I'm Ken So today I'll be sharing with you what I've learnt after coming from a React developer over to a React Native development So I first started out as a React developer about like 2-3 years back So after graduating I started to work on React Native So here are my comments So firstly to start off So React Native isn't React but fret not we still pray to the same God than Abramov So for React Native there is an engine that converts RN components over to the native component So for instance an image an image component in RN will be converted over to image view on Android and UI image view on iOS So next is it's about the UI So as the view is not rendered React Native need to manage the layouts in a different manner So RN adopted yoga So it is an open source engine developed by Facebook It helps to calculate where to place the visual elements in terms of X and Y So So this engine picks up from the concept of flexbox So because RN isn't HTML we don't have HTML table support so something really weird So and neither did yoga engine support table So we can't actually achieve responsive roles and columns through flex So what we have are pseudo tables where the roles and columns resize independently of each other which is not a table So next is if you just start using RN it has a lot of things that would be quite counter-intuitive So if you come directly from React and Mover to React Native you'll realize where all these simple things are not available So the examples the more common ones are CSS stuff SGG linear gradients So fortunately it's open source and somebody had the solution for it so you can add them in So next is a huge pin point for React Native So if any of you guys React Native developers you'll share this pain So for both platforms they have their own design language So this means that they also have their own definition of how a shadow should mean and look like So on iOS you have your regular drop shadows but on Android you have depth and Z-index relation shadows So this means that if you were to use android shadows in the default way your elements with thicker and longer shadows will be placed further up in terms of Z-index in the view So try having models that doesn't have a shadow while having a view element behind that has a shadow You'll realise that how come on Android your model is not the first element that the user sees So as we know earlier React Native runs within the app on the phone itself So it's lifecycle is somewhat tight to the app So on browsers users will be the current React bundle if they visit website assuming that you did your cache correctly but on R& the users can choose not to update their app So this means that they cannot get the latest update So maybe I lied a little bit So some of you guys may know that R& can update on the fly So one example is Microsoft Code Push So there's a caveat So the idea of updating on a fly may sound enticing but unfortunately the app can only update non-native code So this means that if you're updating code that isn't on JavaScript you can't update it So for instance your R& engine it's not a JavaScript So if you want to upgrade your engine but the new R& version might not be a compatible change this means that if you were to use Chinese new features like concurrent word that would not be So your stakeholders the person who is paying you money might not might have to stop you from using concurrent word So maybe some in the future we might have poly fields they don't know So next is the R& and app interface so also known as the jazz bridge So with regards to API data is fetched from a JavaScript site but it doesn't immediately land so the data first has to reach the app and then transferred over the bridge over to your JavaScript site So this means that you have a super speedy network the app may take tens of seconds to pass through the bridge to reach your JavaScript land So next is async events so when we declare a component to be created we send the information through the same bridge as well So the R& engine on the app would then create or process the data and then have it on the native site So this includes the creation of views or handling of events So from here on it comes a little bit complicated but it still behaves the same way as read on a browser So events are received on the app site then imitated to the JS site So for instance your finger touch and scrolls down on the screen to reach it reaches the app site first then depending on the event they send over to the JavaScript site through the bridge So their events which doesn't need to be processed by the JavaScript site So for instance scrolling up and down a list because on the JavaScript site you have already declared that you have a 10 iPhone list and it goes on So the native knows that you want to see certain things it doesn't it doesn't require a JS input So you scroll and the app receive the scroll it will send the scroll over to the JavaScript site but you might not need to act on it So that response handled by the app native list So the scrolling event you can also add a listener to it if you want So however if you have an event that does not have any response that responds to a native handle for instance showing an alert after the user clicks the user will notice a delay in their action So the JavaScript site receives it and then it sends back to the app site to show that alert So this part is still consistent with React but for React native we have a bridge as in one single bridge So if you recall the previous point that I have about data you see something So what happens if you have a huge amount of data coming in from the API and then the user press and then the JavaScript but you still get more data we're still getting data we'll get that somewhere Finally get some reading room and then after that the app site will then respond to it So that's all I have