An Overview of the create-react-app File and Folder Structure

[00:00 - 00:12] On the left-hand side in our VS Code Editor, we've actually navigated now down to the client directory that was created for us by Create React App. On the right-hand side, we have also navigated down to the client directory in our terminal.

[00:13 - 00:28] We're not going to be making any more changes to the server code for part one of this course, so our focus now is going to be on the client side. Create React App creates a series of files and folders as it instantiates and creates this Webpack bundled React application.

[00:29 - 00:44] For those who may be unfamiliar with the scaffold created from Create React App , we're going to spend a few minutes going through the generated application. The node modules directory in our app refers to all the different JavaScript libraries that have been installed into our application.

[00:45 - 00:57] The public folder holds the Fabicon asset as well as the root markup page of the application, the index HTML file. When we take a look at the index HTML file, we can see that there's not much there.

[00:58 - 01:08] In the head tag, it has standard viewport settings and references the Fabicon asset. You can also see some documentation and use of a manifest JSON file.

[01:09 - 01:25] Manifest JSON helps provide metadata for when an app is installed on a user's mobile device, which essentially helps to make a web application more progressive. This ties into some of the boilerplate code Create React App gives us to help create a progressive web application.

[01:26 - 01:37] Some more comments exist telling us how the public URL tag behaves. In this Create React App setting, public URL is replaced with the URL of the public folder during built.

[01:38 - 01:52] This helps reference assets within the public folder in a client-side routing perspective. We won't be making any changes here except for renaming the title of our application to the name of our app, TinyHouse.

[01:53 - 02:04] In the body, we're presented with a no script element. The no script tag is displayed to the user when the user has disabled scripts in the browser or is using a browser that has an unsupported script.

[02:05 - 02:16] The div element with the ID of root is where our entire React application will be mounted onto. This is the element that's referenced in our React render function with which we'll see shortly.

[02:17 - 02:35] And finally, we have some comments that tell us that this is just an HTML file and upon the build step, the bundled scripts of our application will be placed into this body tag. We'll hardly ever find the need to make any significant changes in these surrounding files that involve the setup of our application.

[02:36 - 02:50] The vast majority of time we'll be working within the source directory that contains the TypeScript React and CSS files that we'll be working directly with. Let's first take a look at the sourceindex.tsx file.

[02:51 - 03:00] The root React TypeScript file in our application. If you've never used TypeScript and React before, this .tsx file extension may seem new to you.

[03:01 - 03:13] JSX, or otherwise known as JavaScript XML, is an extension that allows us to write JavaScript that looks like HTML. We can see this use of JSX in the React DOM render function here.

[03:14 - 03:23] The first argument we're passing in is the app component. This declaration of app is JSX, XML-like syntax in our JavaScript file.

[03:24 - 03:48] In standard React, we're able to use JSX within files that have the normal .js file extension, however, certain teams prefer to use the .jsx file extension to denote that the React JavaScript files contain JSX. With TypeScript, however, if we intend on using JSX within our TypeScript files , we must name our files with the .tsx file extension.

[03:49 - 04:04] This is one requirement to use in JSX and TypeScript. The other requirement is to have the JSX option be enabled in our TypeScript configuration, which we'll see has already been done in the .tsconfig file when we actually get to that point.

[04:05 - 04:19] The React DOM render function helps render the parent app component on the root element in our public index HTML file. The React DOM render is from the React DOM library and takes up to three arguments, with which the first two is often defined.

[04:20 - 04:36] The first argument is essentially the root's level element we like a React application to render, which is currently this app component defined here. The second argument is where to render it, with which in this case we're passing in the reference to the DOM node with the ID of root.

[04:37 - 04:51] If we hover over the render function, we can take advantage of VS code's intelligence to see that it also takes a callback function as the third potential argument. If this optional callback is provided, it will be executed after the component is rendered or updated.

[04:52 - 05:06] We won't have a need to run this callback function, so we won't introduce it. The only change we'll make here is sort of a preference thing, but instead of importing the React DOM global, we can directly import the render function that's also being exported.

[05:07 - 05:24] In this root index.tsx files, there seems to be some additional references to help in the introduction of a service worker. Service workers are scripts that run in the browser to help applications be more progressive, by introducing features like asset caching, push notifications, and a lot more.

[05:25 - 05:46] We're not going to spend a lot of time in this course explaining how service workers or progressive web apps behave, so we'll just leave this as is for now, which is essentially the unregistered state of this particular service worker defined in the service worker.ts file. In the source folder also exists a react app and declaration file.

[05:47 - 05:57] As we've mentioned earlier, declaration files are files that describe the typ ings of a JavaScript file that exists elsewhere. declaration files are usually denoted with the d.ts file extension.

[05:58 - 06:15] A triple slash directive is being specified here, which is a unique typescript capability that pertains to single line comments that contain a single XML tag. Triple slash references instructs the typescript compiler to include additional files in the compilation process.

[06:16 - 06:36] In this instance, this instructs the compiler to include and reference the type declarations of the react scripts library, which is the library used to build, test, and run our application. With that said, there has been discussion among the community as to why this particular declaration file is placed exactly in the source folder and not in a types folder of sorts.

[06:37 - 06:48] An open GitHub issue currently exists where the react team is going to place a comment here to better explain the purpose of this file. So we're just going to leave this file here as is.

[06:49 - 07:03] The rest of the source folder contains a few of the other files responsible in setting up the UI we see when we actually start our client application. There's the index CSS file, which has a little bit of styling and is being imported in the main index of TSX file.

[07:04 - 07:13] There's the parent app component app.tsx that contains basically the structure of the boilerplate UI. It also imports and uses its CSS file of its own.

[07:14 - 07:35] And there's also a test file that's also been set up that shows us that create react app actually has just as the testing framework already set up where we can actually begin writing tests right away. With that said, what we're going to do is we're going to remove the index CSS file, the app, TSX, the app.test.tsx and the app.css file for now.

[07:36 - 07:41] We're going to get rid of all of this. We're also going to get rid of the logo SVG file given to us of the react logo.

[07:42 - 08:01] And the only thing we're going to do now is in our render function in the source index file is basically render a single div element that says hello world. Create React app gives us a git ignore file that dictates the files we don't want to check in with Git.

[08:02 - 08:20] This includes the node modules folder, a bundled build folder, etc. As we've discussed in our server, the package lock.json file is an automatically generated JSON file that stores the exact dependency tree that highlights the dependencies installed from the package.json file at that moment in time.

[08:21 - 08:31] It should be committed to source code, but we'll never make changes it to it directly. The package.json file lists all the locally installed NPM packages in our React application.

[08:32 - 08:38] The scripts portion dictates the NPM commands that could be running our app right now. At this moment, we have four script commands.

[08:39 - 08:46] The start build test and eject command. The start script runs our local Webpack server for development.

[08:47 - 09:00] The build script bundles our application in a build folder ready for deployment . And the test script runs the test files in our workspace with the help of the just testing framework available in our app.

[09:01 - 09:22] And finally, the eject script is pretty unique because the eject script enables us to abandon the configuration that create React app provides, which allows us to tweak the Webpack configuration to our liking. Things often done either when one feels that their project outgrows the configuration create React app sets up or need some special type of configuration.

[09:23 - 09:35] It's always important to remember, once a create React app is ejected, we can never go back to its original state. We won't ever find the need to eject our application workspace, so we won't run this command.

[09:36 - 09:48] All our application script commands use the React script dependency available in our app. Next scripts is essentially the core service that's installed into every create React app project.

[09:49 - 10:02] React scripts specifies all the app's development dependencies, like Webpack, Babel, and ESLint. In addition, it contains scripts that glue these dependencies together to help us start build test and eject our application.

[10:03 - 10:14] In the dependencies section of our package JSON file, we see all the locally installed dependencies in our application. We react in React DOM libraries, which help us create and render our React components in the browser.

[10:15 - 10:30] The React scripts library, which is used to run our application script commands , and TypeScript to be able to use TypeScript in our application. Up above exists the @types libraries, which refer to the TypeScript declaration files that come from the definitely typed GitHub repository.

[10:31 - 10:46] We usually tend to place them as dev dependencies, but create React app seems to place them here as actual dependencies. The ESLint's config property in the package JSON file is one way to specify the ESLint configuration within an application.

[10:47 - 11:11] The Create React app scaffold sets the ESLint configuration to extend a specific package known as React app, originally created for Create React app projects. And finally, browser's list, without going into too much detail, works with a few other tools such as the applications, post-css configuration, as well as auto-prefect s to dictate which browsers our application is intended to support.

[11:12 - 11:22] The ReadMe file explains the Create React app project, as well as provides details behind each of the available script commands. We're going to leave the ReadMe file as is.

[11:23 - 11:30] And finally, we have the TSConfigJSON file. Create React app creates a TSConfigJSON file for our project by default.

[11:31 - 11:51] But when we mention this in our server as we're building it for the server project, the TSConfig file essentially guides the compiler with options required to compile the TypeScript project. Though we're not going to alter any of the configuration options Create React app sets up for us, we'll quickly summarize the options that have been declared here.

[11:52 - 12:02] Target specifies the target JavaScript version the compiler will output. Here we see the target output is ES5 which would be compatible for both modern and older browsers.

[12:03 - 12:13] Lib indicates the list of library files to be included in the compilation. Lib is important because it helps us decouple the compiled target and the library support we would want.

[12:14 - 12:22] For example, the promised keyword doesn't exist in ES5. And if we intend to use it, TypeScript will complain since our compiled target is ES5.

[12:23 - 12:44] By specifying a lib option of ESNext, we can still have our compiled target down to ES5 while still being able to use the promised keyword without any TypeScript issues. DOM allows us to directly manipulate the DOM while DOM iterable gives us the ability to iterate over a list of DOM nodes without making the TypeScript compiler complain.

[12:45 - 12:53] Allow JS allows JavaScript files to be compiled. Skip libcheck, skip the type checking of all declaration files.

[12:54 - 13:13] ES module interrupt and and allows synthetic default imports combined gives us the ability to allow default imports of modules that have no default exports. Strict enables a series of striped strict type checking options such as no implicit any, no implicit disk, strict and all checks and so on.

[13:14 - 13:25] Force consistent casing and file names disallows inconsistently case references to the same file names. Module refers to the module manager to be used in the compiled JavaScript output.

[13:26 - 13:37] System JS, common JS among other options can be specified here, but ESNext is defined. Module resolution refers to the strategy used to resolve module declaration files.

[13:38 - 13:46] That is to say the type definition files for external JavaScript code. With the node approach, they're simply loaded from the node modules folder.

[13:47 - 13:55] Install JSON module includes the modules with .json extension. Isolated modules transpiles each file as a separate module.

[13:56 - 14:06] No emit specifies we don't want the emitting of any output during the compilation process. JSX allows us to state the support of JSX within TypeScript files.

[14:07 - 14:20] The preserve or react option states that JSX should be supported within Type Script JSX files. The node specifies the files and folders that we would want included during the TypeScript compilation process.

[14:21 - 14:35] Here we see source being specified which states that any TypeScript code within source will be compiled to normal JavaScript. Everything outside of the source folder example node modules won't be included within the TypeScript compilation process.

[14:36 - 14:55] If include and files those two options aren't specified, the compiler will default to including all TypeScript files, this is where you could also use the root directory and the output directory options. But in this case these particular options are specified in addition the exclude option also exists to exclude files we wouldn't want to compile.

[14:56 - 15:17] Now if you haven't fully understood all the options here, that's really not a problem. The main takeaways is the TS config file dictates the details behind how we want to compile our TypeScript code and create React tab provides a detailed configuration right out of the box and 99% of the time if you're just using create React tab for the very first time you probably won't make any changes here.

[15:18 - 15:39] If you're interested in seeing all the different possible compiler options or even understanding the options here in more detail, be sure to check out the TypeScript compiler options in the TypeScript documentation. The only change we've made is the rendered output from the source index file since we've removed the parent app component and simply wanted to render a hello world message.

[15:40 - 15:54] So let's go to the terminal, start our client webpack server and once running we'll head over to the browser at low close 3000 and we can see the hello world message. Awesome.

[15:55 - 16:14] his soul has yet to get ready for it and that many people will >think about it, one