React Native and Redux Interview Questions and Answers

Q1. What is React Native?  

Ans: React Native is the next generation of React - a Javascript code library developed by Facebook and Instagram, which was released on Github in 2013. Native app creation means writing apps for a specific operating system.

React Native helps developers reuse code across the web and on mobile. Engineers won't have to build the same app for iOS and for Android from scratch - reusing the code across each operating system.

Android and iOS have very different codebases and startups and businesses often struggle to hire - or afford- engineers for both. Now just one developer can write across different mobile operating systems.

Facebook opened up React in 2013 and has been using its proprietary React Native code for iOS app development for over a year.

Q2. Why open source?  

Ans: "If we work together in the open, we can advance the state of technology together," Facebook said in a blog post yesterday evening.

Altruism aside, opting to open source code is a tricky decision. Keeping a businesses infrastructure under-wraps has commercial advantages, especially when your technology is your business model.

But the developer community is loyal to those who open up. Web engineers across the world are quick to point out a bug in the code for free.

Developing open source projects helps keep Facebook one of the most coveted companies to work for. Developers want a challenge, and a sense of giving back - and Facebook wants a large pool of talented engineers to pick its employees from.

Plus, it saves on training. If every engineer Facebook hires already knows how to write in React Native, they have a running start.

Facebook has a culture of maturing its development. Over ten years' it has scaled to serve one billion users, thousands of developers and three major platforms - iOS, Android and Web.

It's a considerable development from when the fledgling startup copied Facebook code on Harvard University's server for releases and,
"poke on it to see if it was still working every day at 10am," mobile engineering manager Bryan O'Sullivan joked earlier this year.

Q3. How did Facebook write React Native for Android?  

Ans: The first cross-platform React Native app - ads manager - was developed by the London-based dev team, who were in the US to announce the Android release yesterday evening. Ads manager lets businesses that advertise on the social network manage their accounts and create new adverts.

React Native has only recently been proven in production and building a new app based on the framework carried some risk.

Three product engineers familiar with React set about to create an app for Android and predicted problems with the logic necessary to understand differing time zones, date formats, currencies and ad formats across the world.

This business logic was already written in JavaScript, and the team knew it wouldn't be efficient to build it all again in Objective-C to do it again in Java for Android.

Now this project has been released on Github, developers can use a single workflow to develop for iOS and Android. This means you can use the same editor and propagate it to both the iOS simulator and Android emulator at the same time.

Airbnb, Box, Facebook, GitHub, Google, Instagram, LinkedIn, Microsoft, Pinterest, Pixar Animation Studios, Twitter, Uber, and WhatsApp all use React code.

Q4. What's the Challenges with React Native?

Ans: Working across separate iOS and Android codebases is challenging.

"When we were building the app, Facebook used this model, and all our build automation and developer processes were set up around it. However, it doesn't work well for a product that, for the most part, has a single shared JavaScript codebase," wrote Daniel Witte and Philipp von Weitershausen, engineers at Facebook in a blog yesterday.

Developers who often struggle to figure out where the master code exists and whether bugs have been fixed in all platforms may want to hold out for when Facebook opens up its unified repository. It is moving all of its code from Git to Mercurial, and will be one of the largest codebases of its kind.

Google is another web giant that understands the power of open source, recently committing to OpenStack and creating an enitrely open source container management project, Kubernetes. The project seems at odds with its own Google cloud business, but again, it knows that the benefits outweigh any loss of Google cloud customers.

Q5. Advantages of React Native?  

Ans: The fact that React Native actually renders using its host platform's standard rendering APIs enables it to stand out frommost existing methods of cross-platform application developement ,like Cordova or Ionic. Existing methods of writing mobile applications using combinations of JavaScript,HTML,and CSS typically render using webviews.While this approach can work, it also comes with drawbacks,especially around performance.
Additionally,they do not usually have access to the host platform's set of native UI elements.When these frame works do try to mimic native UI elements,the results usually "feel" just a little off; reverse-engineering all the fine details of things like animations takes an enormous amount of effort,and they can quickly become out of date.

In contrast, Reactive Native actually translates your markup to real,native UI elements,leveraging existing means of rendering views of whatever platform you are working with. Additionally,React works separately from the main UI thread,so your application can maintain high performance without sacrificing capability.The update cycle in React Native is the same as in React :when props or state change,React Native re-renders the views.The major differnce between React Native and React in the browser is that React Native does this by leveraging the UI libraries of its host platform, rather than using HTML and CSS markup.

For developers accustomed to working on the Web with React,this means you can write mobile apps with performance and look and feel of anative application,while using familiar tools. React Native also represents an improvement over normal mobile development in two other areas:the developer experience and cross-platform development potential.

Q6. Handling Multiple Platforms?  

Ans: React Native gracefully handles multiple platforms. The vast majority of the React Native APIs are cross-platform, so you just need to write one React Native component, and it will work seamlessly on both iOS and Android. Facebook claims that their Ad Manager application has 87% code reuse across the two platforms, and I wrote a flashcard app without any platform-specific code at all.

If you do want to write platform-specific code -- due to different interaction guidelines on iOS and Android, for instance, or because you want to take advantage of a platform-specific API -- that's easy, too. React Native allows you to specify platform-specific versions of each component, which you can then integrate into the rest of your React Native application.

Q7. React Native - Differences between Android and IOS?  

Ans: The base setup for building with Android and iOS are the same, but once you start getting into the development of your app, there are a few differences. From what I've experienced, we can probably bet on using about 80% of our code cross platform. I've heard of others using up to 90%, and I've normally heard the number being around 85%.

To use the code cross platform, you would just copy the code from your .ios.js or .android.js file, and copy it into the other. As long as there are not platform specific components, it should work.

Also:

There are a few modules that were build specifically for iOS, and there are a few that were specifically built for Android, and some of them work cross platform. For example, ActivityIndicatorIOS (https//facebook.github.io/react-native/docs/activityindicatorios.html#content) is an iOS styled element, but if you look in the component itself, you will see both ActivityIndicatorIOS.android.js and ActivityIndicatorIOS.ios.js, so it should at least work cross platform, but UI will probably not be what you would be looking for in Android.

If you install any plugins that need to access any native functionality, for example using a custom font, you will need to do a bit of work separately (on each platform) to get them working for each platform and it will not work cross platform.

Bridging will be entirely different for each platform, though this may not be something you would even have to worry about unless you needed to do something that React Native does not support out of the box. To build in IOS, you will need a Mac and Xcode. To build in Android, you will need the android SDK and some type of emulator (I use Genymotion). But keep in mind that as of now, you can't develop iOS on a Windows machine unless you use something like ExponentJS, but if you have a Mac, you can develop cross platform.

Q8. Are all React components usable in React Native?  

Ans: Web React components use DOM elements to display (ex. div, h1, table, etc) but these are not supported by React Native. You'll need to find libraries/components made specifically for React Native.

I doubt there are components that supports both, thus it should be fairly easy to figure out if it's made for React Native or not. As of now, if the creator does not specifically say that they made for React Native, it probably does not work on React Native.

Q9. Passing functions between components in React and React Native?  

Ans: I would stay away from such passing functions between components. I always use Flux architecture with ReactJs and React Native.

Keep components just to render stuff by properties and sending new actions.

You have hard dependency between components. This stuff does not scale. It will be hard to maintaine such code.

What i personally do is just write actions, stores, dispatcher and don't use any dependency on stuff like redux, because React Native is envolving rapidly and you never know if your dependencies will do it at same speed.

Q10. Difference between React Native and NativeScript, which one do you prefer and why?  

Ans: React JS for the web is fantastic. But when it comes to React Native - i felt i was boxed or caged to Reacts way of creating the views and constructing the screen there after.

With NativeScript that's not the case. The UI definition follows XML syntax. I know XML so easy to follow. When it comes to application logic - it allows ES5, TypeScript - again which i already know so i can reuse my skill. You use a subset of CSS to style your app. Again big plus point here - if you know CSS3, NS allows you to use most of the basic rule sets to style your app. Basically NS is all about open standards - you don't have to learn anything new. you use what you all ready know.

Q11. Are there any disadvantages to using React Native for mobile development?  

Ans: Having played around with it for a few weeks, I've found React Native to be fairly buggy. I don't think it's anywhere near production ready. A lot of features are currently still missing, for example, pin annotations for maps. Being that it's open source, there's nothing stopping you from building the feature yourself, but if you're trying to get something created quickly / for production, you're better off using developing directly for iOS or Android.

Q12. What is the difference between using constructor vs getInitialState in React / React Native?  

Ans: The two approaches are not interchangeable. You should initialize state in the constructor when using ES6 classes, and define the getInitialState method when using React.createClass.

class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = { /* initial state */ };
}
}
is equivalent to

var MyComponent = React.createClass({
getInitialState() {
return { /* initial state */ };
},
});

Q13. Re-Render on Changes?  

Ans: In addition to props, components can also have an internal state. The most prominent example of that behavior would be a click counter that updates its value when a button is pressed. The number of clicks itself would be saved in the state.

Each of the prop and state change triggers a complete re-render of the component.

Q14. What is a prop?  

Ans: A good analogy to define "what is a prop?" has been likened to the real life situation of when a person moves from one home to another. A moving van pulls up and all the contents of the home are loaded in the van and it drives off to be unloaded into the new house. The house is the scenery. The scenery includes the actual walls, floors, ceilings, doors- the architecture of the house. This does not move. It is stationary and permanent. The items boxed up, covered in pads, and carried out to the moving van when a person is changing residences would all be considered the props.

Q15. What is the difference between using constructor vs getInitialState in React / React Native?  

Ans: The two approaches are not interchangeable. You should initialize state in the constructor when using ES6 classes, and define the getInitialState method when using React.createClass.

class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = { /* initial state */ };
}
}
is equivalent to

var MyComponent = React.createClass({
getInitialState() {
return { /* initial state */ };
},
});

Redux

Q1. What is the concept of “single source of tWhat is the concept of “single source of truth” in Redux?

Ans: The state of your whole application is stored in an object tree within a single store. This makes it easy to create universal apps, as the state from the server can be serialized and hybridized into the client with no extra coding effort. A single state tree also makes it easier to debug or introspect an application; it also enables persisting the app's state in development, for a faster development cycle.

Q2. How is it different from MVC and Flux? 

Ans: In classical widely known MVC architecture, there is a clear separation between data (model), presentation (view) and logic (controller). There is one issue with this, especially in large-scale applications: The flow of data is bidirectional. This means that one change (a user input or API response) can affect the state of an application in many places in the code — for example, two-way data binding. That can be hard to maintain and debug.

Flux is very similar to Redux. The main difference is that Flux has multiple stores that change the state of the application, and it broadcasts these changes as events. Components can subscribe to these events to sync with the current state. Redux doesn’t have a dispatcher, which in Flux is used to broadcast payloads to registered callbacks. Another difference in Flux is that many varieties are available, and that creates some confusion and inconsistency.

Q3. What are “actions” in Redux? 

Ans: In a nutshell, actions are events. Actions send data from the application (user interactions, internal events such as API calls, and form submissions) to the store. The store gets information only from actions. Internal actions are simple JavaScript objects that have a type property (usually constant), describing the type of action and payload of information being sent to the store.

{

type: LOGIN_FORM_SUBMIT,

payload: {username: 'alex', password: '123456'

}
}

Actions are created with action creators. That sounds obvious, I know. They are just functions that return actions.function authUser(form)

{
return

{
type: LOGIN_FORM_SUBMIT,

payload: form

}
}

Calling actions anywhere in the app, then, is very easy. Use the dispatch method, like so:dispatch(authUser(form));

Q4. What is the role of reducers in Redux? 

Ans: In Redux, reducers are functions (pure) that take the current state of the application and an action and then return a new state. Understanding how reducers work is important because they perform most of the work. Here is a very simple reducer that takes the current state and an action as arguments and then returns the next state:function handleAuth(state, action)

{
return _.assign({}, state,

{
auth: action.payload
});
}

For more complex apps, using the combineReducers() utility provided by Redux is possible (indeed, recommended). It combines all of the reducers in the app into a single index reducer. Every reducer is responsible for its own part of the app's state, and the state parameter is different for every reducer. The combineReducers() utility makes the file structure much easier to maintain.

If an object (state) changes only some values, Redux creates a new object, the values that didn’t change will refer to the old object and only new values will be created. That's great for performance. To make it even more efficient you can add Immutable.js.const rootReducer = combineReducers({
handleAuth: handleAuth,
editProfile: editProfile,
changePassword: changePassword
});

Q5. What is ‘Store’ in Redux?

Ans: Store is the object that holds the application state and provides a few helper methods to access the state, dispatch actions and register listeners. The entire state is represented by a single store. Any action returns a new state via reducers. That makes Redux very simple and predictable.import { createStore } from ‘redux’;
let store = createStore(rootReducer);
let authInfo = {username: ‘alex’, password: ‘123456’};
store.dispatch(authUser(authInfo));

Q6. How is state changed in Redux?

Ans: The only way to change the state is to emit an action, an object describing what happened. This ensures that neither the views nor the network callbacks will ever write directly to the state. Instead, they express an intent to transform the state. Because all changes are centralized and happen one by one in a strict order, there are no subtle race conditions to watch out for. As actions are just plain objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.pened. This ensures that neither the views nor the network callbacks will ever write directly to the state. Instead, they express an intent to transform the state. Because all changes are centralized and happen one by one in a strict order, there are no subtle race conditions to watch out for. As actions are just plain objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.