Code School Week Three

React, React, React, etc.

The week began with learning React, which is a delightful not-so-little javascript framework, with which we have been making an app for a zoo to intake animals and place them in labeled enclosures.

Our React journey began with creating a folder and doing a npm install react and maybe (i forget) a npm install react-dom. Later we also installed prop-types, styled components, and uuid, as needed. Then to really begin we do npm create-react-app my-app,cd my-app, and thennpm start to launch the thing in the browser, which takes a few seconds to initially load and then it displays a slowly rotating graphic of an atom along with some placeholder text like “welcome to your new react app”. We delete out the graphic and the boilerplate, and then have a blank page to make our app on.

While all that was happening, React created for us a whole bunch of files and a handful of folders, most of which reference each other in a variety of meaningful and helpful ways. Altogether it gets a called a library, although the React documentation also calls create-react-app a frontend build pipeline. Our new folders included node_modules, public, and src. Our node_modules folder contains all our mode nodules, the public folder contains the public-facing stuff (the html page, a favicon, and a manifest.json thinggummajig which is kinda like a README but for the browser to read), and the src folder contains all the brains of the React app.

Our zoo app begins with an empty <div id=”root”></div> on the boilerplate index.html page, which gets the app put into it by its index.js with ReactDOM.render(<App />, document.getElementById(‘root’)). The app.js file referenced by <App /> is the main component of the React app, to which we can attach a variety of complementary functionalities via import Module from 'PATH_TO_MODULE' or const thing = require('PATH_TO_THING'). Each module that we import comes from another file via export default Component or module.exports = {stuff_to_export} or if it’s only one thing viaexport thing . In this way we can can connect together parts and pieces of disparate javascript files, packages, libraries, servers, etc. When our app runs, before it does what we see, it imports what it needs to do its job.

In our the code for our app.js file, after we import what we need, there lives a transcendent object that contains all our functionality, be it methods contained in app.js itself, or extraneous functions imported modularizationarily and called via JSX tags like <ModuleName />. Altogether that object is a javascript class that looks like this:

For our zoo app, the functions unique to app.js handle our event listeners and server requests. In the render method, we handle what gets displayed to the user, and we can call other components that look very similar to our app.js, with render methods of their own, each of which may present content to the user.

At this point it should be mentioned that React carries within itself a sort of meta-narrative about its “state” and its “properties”, referred to in React components via this.state and this.props. State allows us to create changes or dynamics in our app, the status of which is stored in an object. If there are important variables that change over the lifetime of using our app, they need to be in state. Props, on the other hand, don’t change — they are references that refer to one thing over the life time of our app. They exist somewhat as conveyances of information down the hierarchy of our app. For instance, if our app.js needs to pass a reference to one of its unique-to-itself functions down to a child component, it can be like <childComponent propToBeSent={functionUniqueToAppDotJs} />. The child component can then call the parent component and pass it a parameter with something likethis.props.functionUniqueToAppDotJs(parameter). This is a great way to pass information up and down the app hierarchy.

That’s basically it, as far as basic front-end manipulation goes. If we want to involve a server and a database, those calls take time (longer than it takes the react app to load), and so we must put them inside special methods called componentDidMount() and componentWillUnmount(), using calls like fetch, at which point the focus of our code has moved into the back-end, which lies beyond the scope of this article.

Stayed tuned for next week, when we might get to talking about the back-end.

Deeply inspirational. Source: