Happy Friday! For those coming over from Part 1, hopefully you’ve had an opportunity to explore the React and React Native projects in the project repo and get things running locally. Once you’ve done so, it’s time to dive into the details of React and React Native.
create-react-app have some very nice convenience scripts that are abstracting away some of the burdens of development. You can find more details about the
react-scripts library in Session 0 materials (this is being re-built for the Code Wolfpack site, and this will be updated with a link when complete).
React vs React Native
React is somewhat overloaded as a term, as React itself through many iterations has moved much of the DOM-specific functionality into a separate package,
react-dom. That being said, there is still a lot to React that finds itself tied into the DOM-related functionality, which is revealed in the
@types/react supplementary library for TypeScript. As a consequence to this, you cannot simply interrogate package dependencies in a React library for the presence of
react-dom to determine if the library can be used in React Native, and oftentimes your best bet when developing React Native applications is to approach the two libraries as separate entities with very similar semantics. More simply put: React for web, React Native for mobile.
If you want a curated directory of React Native libraries, check out https://reactnative.directory/
React takes flight the moment the render loop is started. You can see this in index.tsx:
JSX and TSX files allow us to substitute calls to
React.createElement, otherwise this would look like:
It doesn’t take much of a leap to understand why the former is preferable. The PascalCased tags are Components (and in JSX, so too are the lower-cased DOM elements!). Components are classes which inherit from
React.Component or one of its variant subtypes. Components exist to encapsulate logic in discrete, composable elements, by standardizing and exposing hooks to its own lifecycle, providing state management, and enforcing a pattern that drives data down into the render phase, and pipes actions up to where they are needed. This drastically simplifies data binding in web applications, as other libraries which allow two way binding have a bad tendency to be a source of bugs due to responding to unexpected state changes (e.g. “Somewhere down the chain of components the data was updated and now this component is sending events because I had a listener on it”).
Components are passed attributes like normal tags:
and in the ExampleComponent class, they can be accessed via
To manage state in a component, you use the state property:
Other than native-specific bindings, React Native is essentially the same thing as React, except instead of DOM components, you have to use the React Native components - these components are turned into native UI elements on the rendered application.
Look familiar? Instead of
<div/>s, we’re using
<View/>. Instead of
<span/>, we’re using
<Text/>. What happens if you try to use HTML elements instead?
They’re pretty clear about expectations. There are more advanced concepts like React Hooks, state management with Redux and advanced state management boilerplate like Sagas, but these are reserved for a more in-depth session. Happy experimenting!