At the dawn of \"smartphones\" in late 2007, when Apple released the iPhone, there were native apps. Apple's app framework included a native app SDK that allows developers to take advantage of all the physical device features and topped it off with an app store that allows for distribution and monetization of the finished applications. When Google released Android in competition, they also embraced this approach with their app store and SDK, which also leveraged the entire Google platform and its services.
\nDevelopers could tap into Google's search and maps services, as well as email, etc. Native applications served their purpose superbly and became the primo factor that propelled Android and iOS as the big two phone operating systems at the time, until the present day.
\nNative smartphone applications were so common that Apple coined the tagline \"There is an app for that\" and copyrighted it in 2009.
\nHowever, come the 2010s. Web technologies saw increasingly rapid growth. Server-side rendered web pages allow for the creation of full-fledged web applications that could offer business values beyond static information. The responsive design movement also enhances accessibility for these web apps across all platforms. It was also during this time that mobile applications became stagnant. Your phone started to have too many applications, and not all of them were equally useful. Some are thin clients to web services, which you could access using your mobile web browser instead.
\nRecognizing this, Progressive Web Applications, or PWA, came in to bridge the gap between native and web applications.
\nFirst and foremost, PWAs are web applications. They run in web browsers, but also usually in webviews on smartphones. Compared to traditional websites that you would visit with a conventional web browser, progressive apps tend to be a little more low key.
\nYou may see one through a direct URL, but more commonly through a desktop/home screen icon on your phone, which takes you to a webview hosting the application. By extension, PWAs are now also distributed through app stores, standing alongside native apps.
\nThe webview itself may also be without or with minimal menu bars to provide an impression close to navigating a native application. Furthermore, progressive applications usually come with some offline viewing capabilities, allowing you to interact with the app even when you are offline or in limited network availability. This is implemented using service workers that stand in between network requests and the user and handle caching as well as push notifications, providing a user experience similar to native app caching.
\nWith that in mind, the idea behind PWA is to create applications that would be most accessible, through the web, that also offers an experience as close to native applications as possible.
\nSuppose you are a new company looking to create a mobile application for your product. If you would like to distribute your app on all major mobile platforms - namely both iOS and Android - you would then have to go through the development and distribution process for both. First off, you will need to learn the language to develop Android applications (Java, Kotlin) and then iOS (Objective-C, Swift), have the correct hardware to test and develop.
\nThis process will have you relearn everything about one platform on the other. Once you finish the initial product, you will have to maintain both codebases moving forward to complete this.
\nWith a progressive app, the process becomes a lot simpler. Your application lives within a browser, and hence only needs to be supported by the browser standards. As of now, support for PWAs is available across major browsers: Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, and Firefox (for Android).
\nYour language is the language of the web: JavaScript. The choice is also yours to leverage the JavaScript platform you are most familiar with, be it React, Angular, or something completely different. The JavaScript codebase will then become the only codebase you need to maintain for the app.
\nAlongside this, you also gain the advantage in the availability of the application. With PWA, your app will be available on the web, accessible by users across many platforms, including all mobile devices that have browser support.
\nPWAs live on the web; this means you do not need to download and store many executables and assets on your device, saving you precious storage space if you are using the app on your phone. This is especially useful when the native version of the application is simply a portal to a web service, which serves to make API calls and present data based on the user data on the server only, without performing any device-specific actions. The functionality of these applications is not inhibited by the browser's sandbox and thus make for perfect PWA candidates.
\nPWAs are designed to be responsive. Even though this depends largely on the individual developer of the application, a well designed and developed PWA should, in theory, provide a consistent experience across devices. With native apps, a lot of effort will be required to ensure that the user experience is uniform across multiple platforms. And even then, certain platforms will impose their own set of requirements on the UI look-and-feel, as well as the functionality of the app.
\nProgressive apps are a creative solution to smooth out the differences between a native app and the web, but not necessarily replace native apps. While it inherits all the advantages and features of the web, there are still certain disadvantages that need to be considered when deciding between a progressive app or a traditional native app.
\nFor one thing, progressive apps are designed to be uniform across devices. This means it is not the technology's focus to make use of specialized features that are available only on select devices. Its feature set will be the lowest common denominator of the range of devices that it supports. With how diverse the feature sets are on modern devices like smartphones and tablets, with high-resolution cameras or fingerprint sensors, to name a few, it would be amiss for applications not to take advantage of these features. It follows that progressive apps are not ideal for specialized workflows, while their strength is in general purpose applications.
\nCompatibility is another big-ticket item. At a baseline level, PWA should be supported by all major browsers. However, platform differences still exist, where specific features are supported by one browser but not another, which will cause inconsistencies in behavior when the user switches from one device/platform to another. A prominent example of this being push notification support on iOS, which requires jumping through some hoops to make it work, as Apple does not support this directly. With that in mind, the subtle differences between browser support become a limitation similar to the difference between native app platforms itself.
\nFor applications to reach the hands of the users, it needs a distribution platform. For native applications, the answer to this is straightforward: Apps are distributed through the native app store, be it Google Play Store or iOS App Store. However, for PWAs, it is more complicated. Distribution can be as simplistic as passing around the application's URL, and anyone who knows the link can access the app. This method has the added advantage due to Google and other search engines/web crawlers naturally picking up the app URL and returning it as a search result.
\nHowever, this method is passive and requires the user to know the application beforehand. Developers might prefer the more traditional way of having the app listed in an app store, which is possible but requires them to jump through the same hoops as native applications, following all of the distributor guidelines, which removes its advantage compared to traditional apps.
\nSo with everything considered, should you go the route of the progressive app? We do not aim to give a concrete answer, but instead a suggestion: If your application can be made a PWA, it is a good idea to do so. At the current moment, progressive apps are an evolution of web apps. Compared to the feature set that users are already familiar with in native apps, progressive apps still trail behind.
\nThis means that if the scope of the application is complex enough, PWA may not provide you with enough tools to do the job. With that said, if your application can be fully implemented with the set of tools that PWA provides, then going this route may net you added benefits that are unique to progressive apps. Are progressive apps the future? It definitely has the potential, but a large part of that answer depends on whether we can leverage its platform to build productive solutions with it today.
\n","frontmatter":{"title":"PWA vs Native App: Which one is Better for you?","author":{"id":"Nathan Nguyen","github":"nathannguyenn","avatar":null},"date":"February 04, 2021","updated_date":null,"tags":["Progressive App","PWA","JavaScript"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/ff88b75a03f86a1891a9545ba6dcd4c4/ee604/index.png","srcSet":"/static/ff88b75a03f86a1891a9545ba6dcd4c4/69585/index.png 200w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/497c6/index.png 400w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/ee604/index.png 800w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/f3583/index.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Nathan Nguyen","slug":"/engineering/progressive-app-vs-native-app/"}}},{"node":{"id":"3bd2ec94-ca56-5b2e-be7f-e39cda842b74","html":"One fairly popular question that got asked on programming bulletin boards has to do with the similarities and differences between React’s constructor and the built in method getInitialState. While the simple answer to this question is indeed simple: “getInitialState is the ES5 friendly method to define the initial state of a React component,” there are a couple more details around getInitialState as well as React’s ES5 support that are interesting and useful to highlight.
One of the fundamental differences between ES5 and ES6 in regards to React implementation is the new class keyword. It allows definition of React components as classes, which is a familiar data structure for anyone who has had experience with more traditional object-oriented languages such as Java or C++. The class structure also allows for natural organization of the component’s elements like state, props, lifecycle methods and member functions. However, ES5 did not provide the same convenience. So instead of defining a React component as a class:
class HelloWorld extends React.Component {\n render() {\n return <span>Hello World</span>;\n }\n}You would rely on a helper module called create-react-class:
var createReactClass = require('create-react-class');\nvar HelloWorld = createReactClass({\n render: function() {\n return <span>Hello World</span>;\n }\n});And it is within the object passed into create-react-class that you could define an initial state by populating the getInitialState attribute:
var HelloWorld = createReactClass({\n getInitialState: function() {\n return {name: this.props.name};\n },\n render: function() {\n return <span>Hello {this.state.name}</span>;\n }\n});Which, in ES6 implementation would be the equivalent of:
\nclass HelloWorld extends React.Component {\n constructor(props) {\n super(props);\n this.state = {\n name: props.name\n }\n }\n render() {\n return <span>Hello {this.state.name}</span>;\n }\n}One difference worth noting is that the create-react-class method automatically binds this to every attribute method. This no longer holds true if you define React components using the common ES6 class syntax, making it so that you have to manually bind this to internal methods:
class HelloWorld extends React.Component {\n constructor(props) {\n super(props);\n this.state = {\n name: props.name\n }\n\n this.changeName = this.changeName.bind(this);\n }\n changeName() {\n this.setState({ name: "World" });\n }\n ...\n}Or otherwise use the “arrow function” shorthand which takes care of binding:
\nclass HelloWorld extends React.Component {\n constructor(props) {\n super(props);\n this.state = {\n name: props.name\n }\n }\n changeName = () => {\n this.setState({ name: "World" });\n }\n ...\n}Since the update to ES6, there have been multiple new React iterations. You could now forgo the constructor declaration altogether and just declare state inline as a class member, or utilize React Hooks as a new way to initialize states. However, the ES5 support remains useful for legacy systems and adds to the overall flexibility of React as a toolset.
You can read more about React's ES5 support in the official doc entry here, and the v0.13.0 beta release blog entry here, for the respective ES6 changes.
\n","frontmatter":{"title":"Constructor vs getInitialState in React","author":{"id":"Nathan Nguyen","github":"nathannguyenn","avatar":null},"date":"January 05, 2021","updated_date":null,"tags":["JavaScript","React"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/4fcf496b1fdd8d1d7ae98e1ab30f19b6/ee604/index.png","srcSet":"/static/4fcf496b1fdd8d1d7ae98e1ab30f19b6/69585/index.png 200w,\n/static/4fcf496b1fdd8d1d7ae98e1ab30f19b6/497c6/index.png 400w,\n/static/4fcf496b1fdd8d1d7ae98e1ab30f19b6/ee604/index.png 800w,\n/static/4fcf496b1fdd8d1d7ae98e1ab30f19b6/efc77/index.png 865w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Nathan Nguyen","slug":"/engineering/react-constructor-get-initial-state/"}}},{"node":{"id":"fee8acd2-7f05-5fc0-a6ab-55ce0c0abffd","html":"React thrives on being one of the premier tools to build single-page applications, which used to be a fairly foreign concept when I started building my first React app. Back then, I was used to the concept of serving separate web pages whenever the user redirects from an URL path to another, and it was rather challenging at first to wrap my head around how React handles navigation.
\nWith that in mind, this blog post aims to lay down and explain the basic aspects of navigation using React Router, one of the most, if not the most, popular solutions for navigation within a React app.
\nThroughout the first section below, please reference this CodePen example.
\nAs hinted at in the preface of this writing, routing in React does not involve replacing the HTML, CSS or JavaScript resources currently being served or reloading the browser content. Instead, using libraries like react-router allows containers to be swapped in and out dynamically based on the current URL location, and this all happens client-side. With that in mind, React Router can more generally be understood as a wrapper that handles conditional rendering based on URL path.
To accomplish this, the basic building blocks that developers get to play with are <Route>, <Switch> and <Link>. Let us look at a basic example making use of these 3 components:
First off, let’s create some simple text components. These components are stand-ins for actual components to be swapped in and out in navigation. HelloBanner will be a div containing the simple message “Hello”, and WorldBanner containing “World!”:
\nconst HelloBanner: React.FunctionComponent = () => {\n return (\n <div id="banner_hello" className="banner">\n <span>Hello Banner is currently displayed. We are currently in path "/hello"</span>\n </div>\n ) \n}\n\nconst WorldBanner: React.FunctionComponent = () => {\n return (\n <div id="banner_world" className="banner">\n <span>Hello Banner is currently displayed. We are currently in path "/world"</span>\n </div>\n ) \n}Now let’s imagine the layout of a conventional web application with a top navigation bar. The navigation bar contains links to each section of the app and the body would show the content of the current webpage. The skeleton code for that container would look something like this in React:
\nclass AppContainer extends Component {\n constructor(props) {\n super(props);\n }\n\n render() {\n return (\n <div id="div_app_container" className="app-container">\n <div id="div_nav" className="nav-bar">\n <span>Navigation bar</span>\n <Link to="/hello">\n <span>Link to /hello</span>\n </Link>\n <Link to="/world">\n <span>Link to /world</span>\n </Link>\n <Link to="/clearlyinvalidpath">\n <span>Link to a clearly invalid path.</span>\n </Link>\n </div>\n <div id="main_container" className="main-container">\n <span>Main Container</span>\n <Switch>\n <Route exact path="/">\n <div>\n <span>\n Default container. We are in root path\n </span>\n </div>\n </Route>\n <Route path="/hello" component={HelloBanner} />\n <Route path="/world">\n <WorldBanner />\n </Route>\n <Redirect to="/" />\n </Switch>\n </div>\n </div>\n );\n }\n}\n\nReactDOM.render(\n <BrowserRouter>\n <AppContainer />\n </BrowserRouter>,\n document.getElementById("app")\n);If you are currently looking at the render of this structure from the CodePen, you would see this very simple UI:
\nClicking on the <Link>’s in the navigation bar will “navigate” you to the corresponding paths. In effect, what this does is twofold:
<Route> components to rerender according to the current path.This is demonstrated through the example app. Once you click the links to /hello or to /world, the corresponding component will be swapped in under the <Switch> container.
A couple of noteworthy things from the code example:
\n<Switch> component allows swapping between <Route>’s and render the correct component with a given URL path. However, <Route> components do not have to be wrapped inside a <Switch>. While standalone, a <Route> will simply render when the URL path matches its own path prop.<Redirect> component at the end acts as the default route. In case none of the other routes match with the current URL path, it simply redirects the user back to root.The workflow described above is intuitive from the end user’s point of view. However, there are times when the application’s internal logic demands a redirection to be performed following app events. In these occasions, React Router leverages the history object to allow for programmatic redirection:
For a traditional setup, the history object can be accessed through a component’s props through the user of the withRouter higher order component:
import * as React from "react";\nimport { RouteComponentProps, withRouter } from "react-router-dom";\n\nexport interface SampleComponentProps extends RouteComponentProps {\n // props go here\n}\nexport interface SampleComponentStateState {\n // states go here\n}\n\nclass SampleComponent extends React.Component<SampleComponentProps, SampleComponentStateState> {\n constructor(props: any) {\n super(props);\n }\n\n performRedirect = () => {\n const { history } = this.props;\n\n history.push("/desired-pathname")\n }\n\n render() {\n return <div/>\n }\n}\n\nexport default withRouter<SampleComponentProps>(SampleComponent);In the example above, you can see all the components required to extract the history object, as well as the history.push() call to perform the redirection.
For a more updated approach, React Router introduced the hook useHistory, which should blend in more naturally when programming with a React Hooks intensive workflow.
Certain redirects are unique in nature, and/or contain certain information about the previous user activity that you might want to pass on to the new component. In this case, the information can be passed through history states into the new component, which will then perform custom behavior based on these states:
\nWhen using <Link> component redirect, populate the to prop with an object that contains the new path as well as states, instead of just the string for pathname:
<Link\n to={{\n pathname: "/desired-pathname",\n state: {\n stateName: "state to be passed."\n }\n }}\n>\n Link text here.\n</Link>The same object can be used as argument to the history.push() call to achieve similar results:
history.push({\n pathname: "/desired-pathname",\n state: {\n stateName: "state to be passed."\n }\n})Once the state has been included with the redirection, on the receiving end, you can extract the state from the history.location.state object:
import * as React from "react";\nimport { RouteComponentProps, withRouter } from "react-router-dom";\n\nexport interface ReceivingComponentProps extends RouteComponentProps {\n // props go here\n}\nexport interface ReceivingComponentStateState {\n // states go here\n}\n\nclass ReceivingComponent extends React.Component<ReceivingComponentProps, ReceivingComponentStateState> {\n constructor(props: any) {\n super(props);\n }\n\n componentDidMount() {\n const { history } = this.props;\n if (history.location.state && history.location.state.stateName) {\n // stateName can be accessed here if it is passed in from a previous redirect action.\n console.log(history.location.state.stateName);\n }\n }\n\n render() {\n return <div/>\n }\n}\n\nexport default withRouter<ReceivingComponentProps>(ReceivingComponent);The state access is in componentDidMount in the example above.
At this point, hopefully, we have covered all the big bullet points to help you get started with navigation using React Router. I hope this write-up has been informative and helpful to your understanding of navigation in React, as well as helping you build your next React application.
\n","frontmatter":{"title":"React Router Basics: Routing in a Single-page Application","author":{"id":"Nathan Nguyen","github":"nathannguyenn","avatar":null},"date":"November 20, 2020","updated_date":null,"tags":["JavaScript","Node","React","React Router"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/a53096b6796dd3d1e3f3df8bc77a6689/ee604/index.png","srcSet":"/static/a53096b6796dd3d1e3f3df8bc77a6689/69585/index.png 200w,\n/static/a53096b6796dd3d1e3f3df8bc77a6689/497c6/index.png 400w,\n/static/a53096b6796dd3d1e3f3df8bc77a6689/ee604/index.png 800w,\n/static/a53096b6796dd3d1e3f3df8bc77a6689/f3583/index.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Nathan Nguyen","slug":"/engineering/react-router-basics/"}}},{"node":{"id":"f135d4b5-42c2-5f4f-b0fc-9b224170ec28","html":"Rendering is an essential procedure a programmer has to manage in frontend development. In React, the render() method is the only required method in a class component and is responsible for describing the view to be rendered to the browser window. Coupled with the clever way React operates around its virtual DOM concept, there are certain subtleties in how this method works. Understanding them will greatly benefit any aspiring React developer.
\nThroughout this writing, I will reference this codepen for a demonstration of discussed behaviors.
\nrender() 101First of all, render() is not user callable. It is part of the React component lifecycle. Generally, it gets called by React at various app stages when the React component instantiates for the first time, or when there is a new update to the component state. Render does not take any arguments and returns a JSX.Element which contains the view hierarchy of the current component. This view hierarchy will later be translated into HTML and displayed in the browser window.
As mentioned before, render() is not user callable as it is an event that happens in the component’s lifecycle. With that said, if it is absolutely necessary to render the view manually, you can instead call the built-in class method forceUpdate(). Keep in mind that this is considered an anti-pattern. If you were designing sensible React components, its state and props changes should naturally control the render process, and you should never feel the need to make a manual call.
Within the lifecycle, these are the scenarios where render is called:
\nconstructor() call.setState() callIf you have the Codepen opened at this point, before anything is rendered you will see 2 alert messages from the browser: \"render() is called in Parent component!\", and \"render() is called in Child component!\". These messages are invoked from the corresponding render() methods of the example's parent and child component. They serve to introduce the first case of render() invocation: when the component is first instantiated.
Once the set of alerts is dismissed, a very simple UI will render:
\nThe dotted border line distinguishes between elements that belong to the Child component of the example (inside the dotted line) versus the Parent component.
\nchildElementText state of the Parent component, which in turns updates the text prop of the Child component, triggering a render in both Parent and Child. onChildPropChange = () => {\n this.setState({\n childElementText: "I am the child element! I am updated following a prop change."\n })\n }helloWorldMessage state within Child component, triggering a render following a state change. onTextChange = () => {\n this.setState({\n helloWorldMessage: "Hello React! (state change after setState call)"\n })\n }A visual and interactive reference to the React lifecycle can be found here.
\nIt is worth noting that following a props update or setState(), the method shouldComponentUpdate() is invoked to determine whether render() should be called. By default, this method always returns true. But it can be overloaded to implement custom logic. It is the actual way to define custom render behavior in each React component.
The shouldComponentUpdate() provides you with nextProp and nextState as arguments, which allows you to compare the current state and props of the component. For example, this code block will invoke render() only when the text prop changes:
shouldComponentUpdate(nextProps: NewComponentProps, nextState: NewComponentState) {\n if (this.props.text !== nextProps.text) {\n return true;\n } else {\n return false;\n }\n }The characteristics and behaviors mentioned above made it imperative that render() is a pure function. That means inside render(), you should not make an update to the component's states or props (no setState() call nor Redux state update). This makes sense because an update to the component will then trigger a new render() call, which can potentially lock you into an infinite render loop.
In terms of return value: render() returns a single JSX element, as mentioned above. This comes with certain implications:
<div>, or a <React.Fragment>. It is worth noting that once rendered, <React.Fragment> will vanish from the DOM structure. It is only meant to be a wrapper component and does not appear in the final DOM in the browser. This makes it a more sensible choice over a <div> wrapping to avoid nesting div’s.render() method, it is helpful to think about how the entire UI will look like at a moment in time, instead of thinking about how a certain element updates over time. “Thinking about how the UI should look at any given moment, rather than how to change it over time, eliminates a whole class of bugs.”key propThe render() method in each React component then feeds into what is called the Reconciliation Algorithm. This is the primary algorithm that dictates how React renders the real DOM in your browser based on a virtual DOM maintained internally by React. To intelligently determine what needs to be rendered on every call, React compares the current state of the virtual DOM and the real one and only makes changes to the physical DOM where it recognizes that the UI has been updated.
While not every single detail is known about React’s reconciliation algorithm, the characteristics detailed in the official documentation are enough for us to start phasing out certain suboptimal rendering patterns, thus writing a more robust render() method.
For instance, given this DOM subtree:
\n<div>\n <span key="li-1">list item 1</span>\n\n <span key="li-2">list item 2</span>\n\n <span key="li-3">list item 3</span>\n</div>If a <NewComponent> is then added to the top of the list:
<div>\n <!-- previously <span>list item 1</span> - element is detached and <NewComponent /> instantiated -->\n <NewComponent />\n\n <!-- previously <span>list item 2</span> - content will be updated to "list item 1" -->\n <span>list item 1</span>\n\n <!-- previously <span>list item 3</span> - content will be updated to "list item 2" -->\n <span>list item 2</span>\n\n <!-- new <span>list item 3</span> is element created -->\n <span>list item 3</span>\n</div>If instead <NewComponent> is added to the bottom:
<div>\n <!-- previously <span>list item 1</span> - no change -->\n <span>list item 1</span>\n\n <!-- previously <span>list item 2</span> - no change -->\n <span>list item 2</span>\n\n <!-- previously <span>list item 3</span> - no change -->\n <span>list item 3</span>\n\n <!-- new instance of <NewComponent /> is added -->\n <NewComponent />\n</div> In the example above, appending <NewComponent> to the end of the list will result in 1 new instantiation, versus 1 instantiation, 3 updates and 1 tear down. In a larger application scale, this will prove to be a significant performance difference in the long run.
If you have ever tried to use the map() method to iterate over an array to render a list of elements, it is likely that you have seen React complaining about a missing key prop to each rendered list item. So what does the key actually do?
A key is React’s way to recognize elements in the DOM tree, comes reconciliation time. When React is parsing all children of an element, it can leverage keys to match elements that were present from the last update. That allows you to shuffle the order of child elements without interfering with the algorithm. As long as the key matches between updates, React will preserve the element configuration.
Coming back to the example above, let’s add keys to all the existing list items:
\n<div>\n <span key="li-1">list item 1</span>\n\n <span key="li-2">list item 2</span>\n\n <span key="li-3">list item 3</span>\n</div>In this case, if we were to add an extra “list item 4” at the top of the list, it would not come with the same performance penalty:
\n<div>\n <!-- new item - <span> is instantiated -->\n <span key="li-4">list item 4</span>\n\n <!-- matched with the old "li-1" key - element stays unchanged between renders -->\n <span key="li-1">list item 1</span>\n\n <!-- matched with the old "li-2" key - element stays unchanged between renders -->\n <span key="li-2">list item 2</span>\n\n <!-- matched with the old "li-3" key - element stays unchanged between renders -->\n <span key="li-3">list item 3</span>\n</div>In case a subtree is generated using a map() or other iterative methods, React requires that keys are provided with the element. However, even in case a DOM subtree is manually added, keys should be provided on subtrees that have complex behaviors regarding conditional rendering.
React is a clever framework that offers performance through its rendering scheme, so it follows that, as developers, we should leverage it appropriately to help build performant applications. With that said, it is not a miracle device that optimizes out inefficiencies from the developer’s end, but a tool to be utilized. Understanding the render() nd its implication to the reconciliation algorithm is the first step to make sure we are leveraging the framework instead of working against it. It is also one of the first steps to mastering React.