Latest Tutorials

Creating large, long-lived React apps, such as those required in large enterprises, poses unique challenges. Most developers lack the knowledge of how to build apps that scale gracefully and use the latest React techniques, such as React Hooks and React Testing Library, to modernize React apps in the enterprise. This course will help you master React development in the context of building for large enterprises. You will learn the latest React syntax, React Hooks, and more as you build an actual enterprise React app. You will learn: In  The newline Guide to Modernizing an Enterprise React App,  we teach you the various aspects of React development that ensure that apps vital to a company's success keep running. This is based on years of experience building and maintaining large-scale, complex, React apps in production, and will prepare you to do the same for any enterprise. By the end of the first module in the course, you'll already have started working with the sample enterprise React app, Hardware Handler, and preparing to modernize it using the latest React standards. The subsequent modules will teach you important React concepts and guide you in modernizing this React app, including: Paige Niedringhaus  is your instructor for this course. She's a Staff Software Engineer for the Internet Of Things startup, Blues Wireless, which has backing from leading investors, including Sequoia Capital and Microsoft founder Bill Gates. Paige has a strong background in React and large-scale enterprise apps, having worked in software engineering for The Home Depot for 5 years. Now she teaches you everything you need to build beautiful apps with React in a way that can support the mission-critical demands of large enterprises. You can read more details about the course over at the Modernizing An Enterprise React App website  

Testing is basically a requirement for modern software today, not a nice-to-have. In the past, end-to-end testing was hard to set up, flaky, and generally a pain to deal with, but it's the best automated testing option to confirm software works. Cypress.io continues to improve the e2e testing experience and its new feature Cypress Studio takes it a step further to make writing tests quicker and easier too.Photo by Farzad Nazifi on Unsplash When Cypress.io first hit the scene in 2015, it made a splash because it fixed so many of the issues that existed with other end-to-end testing (e2e) competitor frameworks. Between good documentation, intuitive syntax, improved debugging, and no reliance on Selenium under-the-hood - everything about Cypress was a major step forward for e2es, but it wasn't content just to stop there. The team behind Cypress regularly keeps releasing new features and functionality to make it more and more useful for devs, and make e2e testing (traditionally kind of a pain) easier and easier as well. One recent release that's currently tucked behind a feature flag is called Cypress Studio , and it's an absolute game changer. Today, I'll show you how to add Cypress to an existing JavaScript project, enable Cypress Studio, and let it help do the heavy lifting of writing end-to-end tests. It's such a cool feature to help dev teams save time on testing, deliver new features faster, and still ensure the mission critical functionality of the app continues to work as expected. Although Cypress is kind enough to provide a host of sample scripts to show many of its features in action, it really shines with a local app to test against, and I just so happen to have one that fits the bill. The app I'm using is a React-based movie database that allows users to see upcoming movies and movies in theaters now, browse movies by genre, and search for movies by title. This will be a good app to demonstrate Cypress Studio's power. Once we've got an app to add Cypress to, the first thing we'll need to do is download Cypress to it. This is another reason Cypress stands head and shoulders above its competitors: one npm download gives you all the tools you need to start writing e2es. No dev dependencies, no extra libraries with mismatched package versions, none of that nonsense to deal with. At the root of your project, where your package.json  file lives, run the following command from the terminal: This will add a bunch of new Cypress-based folders and files to your app, and with just a few small configuration changes we'll be ready to go. See all those new folders under cypress/ ? That's what you should see after initial installation. For ease of use, I like to add npm scripts for the two main Cypress commands we'll be using: In your package.json  file, add the following two lines in your "scripts"  section. Now when we need to run the tests, a simple npm run cy:run  or npm run cy:open , straight from the command line, will do the trick.  Ok, before we get to writing our own tests, let's run the pre-populated tests in Cypress to get familiar with the its Test Runner. From your command line, run the following shell command: This should open the Cypress Test Runner, and from here, click the Run integration spec button in the top right hand corner to run through all the pre-made tests once. After all the Cypress tests run and pass, we're ready to delete them and get to work on our own tests for our app. Go ahead and clear all the files out of the Cypress folders of fixtures/ and  integration/ . You'll probably also want to add the folders of cypress/screenshots/  and cypress/videos/  to your .gitignore  file just so you don't commit those screenshots and videos that Cypress automatically takes during test runs to your GitHub repo (unless you want to, of course). Add baseUrl variable With that taken care of, let's set up a baseUrl  in our cypress.json file and enable Cypress Studio there too. Turn on experimentalStudio To enable Cypress studio, just add "experimentalStudio": true  to our cypress.json  file. So here's what the cypress.json  file will end up with. Now we can write our first test file and test. Inside of the cypress/integration/  folder in your project, create a new test file named movie-search-spec.js . This folder is where Cypress will look for all your e2e test files when it runs. Give it a placeholder test: we have to tell Cypress where we want it to record the test steps we're going to show it. So just create a typical describe  test block and inside of that, create an it  test. A good first test would be to test that a user can navigate to the movie search option, search for a particular movie name, and click into the results based on that search. Here's what my empty testing placeholder looks like in the movie-search-spec.js  file. I think we're about ready to go. One thing you must do before starting up Cypress to run tests against your local app is to start the app locally. For Cypress, it's an anti-pattern to start the app from a test, so just fire it up in a separate terminal, then open up the Cypress Test Runner. Start the movie app In one terminal run our movie app: Start the Cypress Test Runner And in a second terminal, open the Cypress Test Runner: In Cypress, Add Commands to Test When the Cypress Test Runner is open, enter our test file and click the tiny blue magic wand that says  Add Commands to Test  when you hover over it. And from here, go for it - test the app. For me, I clicked the Movie Search link in the nav bar, typed "Star Wars" into the search box, clicked into one of the results, etc. When you're satisfied with what your test is doing, click the Save Commands button at the bottom of the test, and Cypress will run back through all the commands it's just recorded from your actions. Tell me that's not cool. If you go back to your IDE now, you'll see all the actions Cypress recorded, along with a few comments to tell you it was Cypress generating the code and not a developer. This is what my test now looks like: Just wow, right? Although our test is good, Cypress can't be expected to test for all the things a developer might know are important. Things like the number of movies returned from searching "star wars" or checking the title of the movie being clicked into and the contents inside of the movie page itself. I'll fill in some of those details myself now.  If you look at my code above, I added comments after the extra assertions I added - mainly small things like checking for search text, the count of movies returned, the movie info like rating and release date in this specific movie. I didn't add a ton of extra code, just a few extra lines of details. Now run the test again and check the results. And we're done! Congrats - our first Cypress Studio-assisted e2e test is written.  Just repeat these steps for as many end-to-end tests as you need to write and prepare to be amazed at how much time it saves you. In modern software, testing is a critical piece of any solid enterprise application. It helps ensure our app continues to function as expected while adding new functionality, and end-to-end testing is the closest we can get to mimicking exactly how a user would use the app with automation. Cypress broke the mold of what e2e testing frameworks are capable of when it debuted back in 2015, and it's only continued to improve with time. My favorite new feature of late is the ability to show  Cypress how a test should act instead of writing it yourself with Cypress Studio - the time saving possibilities are immense. And more time saved means finishing features faster and getting new functionality into the hands of users quicker. Win win win. In 10 modules and 54 lessons, I cover all the things I learned while at The Home Depot, that go into building and maintaining large, mission-critical React applications - because it's so much more than just making the code work. From tooling and refactoring, to testing and design system libraries, there's a ton of material and hands-on practice here to prepare any React developer to build software that lives up to today's high standards. I hope you'll check it out.

Web development is tough enough as it is, something as mundane as mismatched versions of Node in development versus production shouldn't be another thing you have to keep in mind. Volta can prevent this sort of issue and so much more for you and your dev team automatically, and it's easy to set up to boot. Read on to get started using it yourself.Photo by Felix Mittermeier on Unsplash When you're working with a team of developers, especially on a team responsible for managing multiple applications, you very well might have JavaScript apps that run on different versions of Node.js. Some might use Node 10, others Node 12, some may use Yarn as their package manager, others might use npm - and keeping track of all that is really hard. Ensuring every developer on the team is developing with the correct versions all the time is even harder. But it's essential. While the consequences might be relatively minor during local development: it works on one dev's machine and throws an error on another's, this sort of lack of standardization and clarity can have devastating effects when it comes to production. And it could have all been avoided if we'd been using a handy little tool called Volta.  I want to introduce Volta to you today so you can avoid the stress we went through - it's simple to get started with and can prevent catastrophes like this. What this means in practice is that Volta makes managing Node, npm, yarn, or other JavaScript executables shipped as part of packages, really easy. I've told you what Volta is, but you're probably still wondering why I chose it in particular - it's certainly not the only game in town. NVM's another well known option for managing multiple versions of Node. I used to use Node Version Manager (NVM)  myself. Heck, I even wrote a whole blog post about how useful it was. NVM is good, it does exactly what it sounds like: it allows you to easily download and switch versions of Node.js on your local machine. While it does make this task simpler, NVM is not the easiest to setup initially, and, more importantly, the developer using it still has to remember themselves to switch to the correct version of Node for the project they're working on. Volta, on the other hand, is easy to install and it takes the thinking part out of the equation: once Volta's set up in a project and installed on a local machine, it will automatically switch to the proper versions of Node. Yes, you heard that right. Similar to package managers, Volta keeps track of which project (if any) you’re working on based on your current directory. The tools in your Volta toolchain automatically detect when you’re in a project that’s using a particular version of the tools and takes care of routing to the right version of the tools for you. Not only that, but it will also let you define yarn and npm versions in a project, and if the version of Node defined in a project isn't downloaded locally, Volta will go out and download the appropriate version. But when you switch to another project, Volta will defer to any presets in that project or revert back to the default environment variables. Cool, right? Ready to see it in action? For ease of getting started, let's create a brand new React application with Create React App, then we'll add Volta our local machine and our new project. First things first, create a new app. Run the following command from a terminal. Once you've got your new React app created, open up the code in an IDE, and start it up via the command line. If everything goes according to plan, you'll see the nice, rotating React logo when you open up a browser at http://localhost:3000 . Now that we've got an app, let's add Volta to it. Installing Volta to your development machine is a piece of cake - no matter your chosen operating system. Unix If you're using a Unix based system (MacOS, Linux or the Windows Subsystem for Linux  - WSL) to install Volta, it's super easy. In a terminal, run the following command: Windows If you've got Windows, it's almost this easy. Download and run the Windows installer and follow the instructions. Once Volta's finished downloading, double check it installed successfully by running this command in your terminal: Hopefully, you'll see a version for Volta like my screenshot below. If you don't try quitting your terminal completely, re-opening a new terminal session and running that command again. The current version of Volta on my machine is now v1.0.5. Before we add our Volta-specific Node and npm versions to our project, let's see what the default environment variables are. Get a baseline reading In a terminal at the root of your project, run the following line: For me, my default versions of Node and npm are v14.18.1 and v6.14.15, respectively. With our baseline established, we can switch up our versions just for this project with Volta's help. Pin a node version We'll start with Node. Since v16 is the current version of Node, let's add that to our project. Inside of our project at the root level where our package.json  file lives, run the following command. Using volta pin [JS_TOOL]@[VERSION]  will put this particular JavaScript tool at our specified version into our app's package.json . After committing this to our repo with git, any future devs using Volta to manage dependencies will be able to read this out of the repo and use the exact same version. With Volta we can be as specific or generic as want defining versions, and Volta will fill in any gaps. I specified the major Node version I wanted (16) and then Volta filled in the minor and patch versions for me. Pretty nice! When you've successfully added your Node version, you'll see the following success message in your terminal: pinned [email protected] in package.json (or whatever version you pinned). Pin an npm version That was pretty straightforward, now let's tackle our npm version. Still in the root of our project in the terminal, run this command: In this particular instance, I didn't even specify any sort of version for npm, so Volta defaults to choosing the latest LTS release to add to our project. Convenient.  The current LTS version for npm is 8, so now our project's been given npm v8.1.0 as its default version. To confirm the new JavaScript environment versions are part of our project, check the app's package.json  file. Scroll down to the bottom and you should see a new property named "volta" . Inside of the  "volta" property should be a "node": "16.11.1"  and an "npm": "8.1.0"  version. From now on, any dev who has Volta installed on their machine and pulls down this repo will have their settings for these tools automatically switch to use these particular node and npm versions. To make doubly sure, you can also re-run the first command we did before pinning our versions with Volta to see what our current development environment is now set to. After this, your terminal should tell you it's using those same versions: Node.js v16 and npm v8. Now, you can sit back and let Volta handle things for you. Just like that. 😎 If you want to see what happens when there's nothing specified for Volta (like when you're just navigating between repos or using your terminal for shell scripts), try navigating up a level from your project's root and checking your Node and npm versions again. In the screenshot below, I opened two terminals side by side: the one of the left is inside of my project with Volta versions, the one on the right is a level higher in my folder structure. I ran the following command in both: And in my project, Node v16 and npm v8 are running, but outside of the project, Node v14 and npm v6 are present. I did nothing but switch directories and Volta took care of the rest. Try and tell me this isn't cool and useful. I dare you. 😉  Building solid, stable apps is tough enough without having to also keep track of which versions of Node, yarn and npm each app runs best with. By using a tool like Volta, we can take the guesswork out of our JavaScript environment variables, and actually make it harder for a member of the dev team to use the wrong versions than the right ones. And remember to double check your local Node version matches your production server's Node version, too. In 10 modules and 54 lessons, I cover all the things I learned while at The Home Depot, that go into building and maintaining large, mission-critical React applications - because it's so much more than just making the code work. From tooling and refactoring, to testing and design system libraries, there's a ton of material and hands-on practice here to prepare any React developer to build software that lives up to today's high standards. I hope you'll check it out.

Maintaining and refactoring a large codebase requires lots of development time and effort. Issues, such as inconsistencies in variable naming or passing incorrect arguments in function calls, tend to happen more frequently in larger codebases. As you scan your codebase for these issues, you may observe some of them emerging repeatedly in different parts of your codebase. Manually sifting through tens and hundreds of files to apply the same set of changes in multiple places is simply not feasible. Anytime you have to manually make many repetitive changes, the likelihood of a mistake occurring increases. To automate this entire process, you need tooling that draws upon abstract syntax trees to audit code, report the findings and, if warranted, immediately resolve them. Abstract syntax trees are not only used for compilers; they are also present in other types of development tooling. By parsing source code into an abstract syntax tree, we can traverse the nodes of the tree to interact directly with each and every literal, identifier, etc. in the source code. For React applications, auditing with abstract syntax trees lets us understand the current state of our components' source code and get information about our components' contents. For example, if we notice <button /> elements scattered throughout our application, then we can write a tool to list the CSS classes assigned to their className attributes. Using this list, we can check if there are any incorrectly spelled CSS classes and/or invalid CSS classes and fix them. Additionally, we can refactor the <button /> elements into a <Button /> component and consolidate the CSS classes within this single component. Therefore, if we decide to rename/remove any of the CSS classes, then we only need to visit and edit one component instead of many. Writing development tooling based on abstract syntax trees takes little time thanks to Babel's large ecosystem of packages and plugins. Babel comes with packages for parsing source code ( @babel/parser ) and traversing abstract syntax trees ( @babel/traverse ). Below, I'm going to show you how to write an auditing tool for React applications using Babel. To get started, initialize a new Create React App project: For this tutorial, we will be writing an auditing tool that generates a report of the <button /> elements used within the React application. The report will list the attributes (i.e. type , className and onClick ) set on these elements and the values assigned to them. If the report shows many many <button /> elements sharing the same CSS classes, then we can refactor them into a single <Button /> component that renders a <button /> element with those CSS classes. Within the new project, create three components that contain <button /> elements with type , className and onClick attributes: ( src/components/Modal.tsx ) ( src/components/LoginForm.tsx ) ( src/components/Card.tsx ) While the components are not actively used within the application, you can still audit them since the auditing tool statically analyzes the components' source code. It does not run the React application. The auditing tool uses two Babel packages: Let's install these two packages: To find all the relevant component files, the auditing tool uses a glob pattern to search for files by their name. Let's install the glob package: Since this tool will be written with TypeScript, we will need to install ts-node to run it and type definition files for the glob and Babel packages. Note : @babel/parser provides its own type definitions. Therefore, you don't need to install any extra dependency for its type definitions. At the root of the project directory, create a new directory named audits . Within this directory, create a buttons-audit.ts file. Within this file, start by synchronously glob searching for the component files and reading their content. ( audits/buttons-audit.ts ) Add an npm script to package.json to execute this script: ( package.json ) Note : The module compiler option suppresses the warning message Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension. . For larger projects, you should define compiler options within a tsconfig.json file. Run this npm script to verify that ts-node properly runs the audits/buttons-audit.ts file. Now, parse the source code of each file into an abstract syntax tree. ( audits/buttons-audit.ts ) Call the traverse function from the @babel/traverse package to traverse the abstract syntax tree. Pass it the abstract syntax tree generated by the parser and an object with the nodes to execute code when visited. In this case, we would like to execute code whenever Babel finds a <button /> JSX element. Since an element's attributes are assigned to its opening, not closing, tag, we should execute code on JSXOpeningElement nodes. A JSXOpeningElement node represents any opening JSX element (i.e. opening <a /> element tags), so how do we narrow down to opening <button /> element tags? Anytime Babel encounters a node of type JSXIdentifier with a name of button , this indicates that we have reached a node that represents an opening <button /> element tag. This is where we want to execute code to retrieve the <button /> element's attributes and corresponding values. ( audits/buttons-audit.ts ) To check whether an opening <button /> tag has the className attribute, we must iterate the node's attributes for a className attribute: ( audits/buttons-audit.ts ) If the <button /> element does not have a className attribute, then we should skip it. ( audits/buttons-audit.ts ) Next, record the button's attributes and their corresponding values to an object named propsAndValues , which we declare in the outer scope of the script: ( audits/buttons-audit.ts ) Once the audit finishes, we can log our findings. ( audits/buttons-audit.ts ) Altogether... ( audits/buttons-audit.ts ) If you re-run the audit, then you will see that there are four buttons with the CSS class btn . Since these buttons either have a btn--primary or btn--secondary CSS class, we may consider refactoring these buttons into a <Button /> component that centralizes these CSS classes in one file. If we ever decide to rename these CSS classes during a redesign, then we would only need to make the changes within this file only. For larger codebases, this approach allows you to quickly audit your code, saving you lots of development time that can be allocated towards other important tasks. Best of all, you can export this report into a separate file to share these results with other team members. Try auditing your own React applications with abstract syntax trees. You can also check out our new course,  The newline Guide to Practical Abstract Syntax Trees , for more practical techniques you need to maintain any size codebase. 

A React application written with JSX. A style guide written with SASS. E-mail templates written with Pug. Such projects involve a compilation step that takes source code written in a language that a browser cannot understand and turns it into HTML/CSS/JavaScript code that a browser can parse and execute. Anytime you tell the compiler to build a React application, you expect the compiler to process and transform the JSX source code into pure JavaScript code with React function calls. Often, we treat the compiler as a black box, and very rarely do we look underneath its hood to see how exactly it performs this transformation. The magic behind the compiler lies in the data structure it uses to convey the structural patterns of the source code: abstract syntax trees (AST). By analyzing the syntax of the source code and breaking it down into its constituent tokens (i.e. keywords, literals, operations, etc.), we can represent the code as a tree data structure. Being able to generalize the constructs and rules of the source code with an abstract syntax tree gives the compiler a high-level blueprint to follow when transforming the code. It's up to the compiler to traverse the abstract syntax tree (via the depth-first search traversal algorithm), extract information from it and output code of equivalent functionality, but written in a different language and/or optimized for performance. In some respects, you may say abstract syntax trees for compilers serve a similar role as pseudocode for algorithms. Abstract syntax trees are not limited to compilers. In fact, they can be applied in a variety of use cases, such as: Below, I'm going to show you: JSX in React describes a component's UI by using syntax that resembles HTML markup. Like other JavaScript-based templating languages (e.g., Handlerbars and Pug), JSX requires a compiler to compile down to JavaScript for the code to run on browsers. For example, a browser cannot recognize code that looks like this: Browsers only natively support the syntax of the JavaScript language (i.e. official features of the ECMAScript specification). Therefore, markup syntax within JavaScript code is not valid and will result in a runtime error. To avoid this problem, we must compile the above code down to pure JavaScript code that the browser understands: JSX serves as syntactic sugar for the React.createElement method. For larger components with lots of nested elements, JSX provides greater readability and clarity. For the compiler to convert JSX to JavaScript, the original source code must be... If we want to preview the abstract syntax tree generated by different parsers, then we can type the above JSX code into the AST Explorer editor. Most JavaScript-based abstract syntax trees follow the ESTree specification , which defines properties categorized grammars. Below is an abbreviated version of the abstract syntax tree (in JSON format) generated by a parser for the JSX code. Check out the complete abstract syntax tree here . Below is a visualization of this abstract syntax tree: Note : The leaf nodes represent actual identifiers, keywords and literals from the code itself. The remaining parent nodes represent the token types discovered by the parser. Here's a diagram that illustrates how the compiler works: The parser responsible for outputting the above abstract syntax tree for the JSX code is the Babel parser , which parses source code for the Babel compiler . Babel uses an abstract syntax tree based on the ESTree specification. React applications written with next-generation JavaScript and JSX rely on the Babel compiler to transform code into JavaScript that is compatible with the browsers you choose to target. With plugins, Babel applies specific code transformations to the source code. For example, if you want to use the arrow function syntax, but need your application to run in Internet Explorer, then enable the Babel plugin @babel/plugin-transform-arrow-functions in the configuration file. Whenever Babel encounters any instances of the arrow function syntax, it will transform them with this plugin. For JSX code, the Babel plugin @babel/plugin-transform-react-jsx parses and transforms JSX code to React function calls. To understand how the plugin works, we must first see how Babel parses JSX code. Babel is not just one single package. Rather, its core functionality is divided up into several different packages: Babel's parser @babel/parser provides a parse method that reads source code (as a string) and generates an abstract syntax tree from it. Here's a simple program for printing the abstract syntax tree (in JSON format) of a snippet of JSX code: ( index.js ) Note : This program only needs @babel/parser installed. The parser option plugins tells the Babel parser which plugins ("jsx," "flow" and/or "typescript") to enable. The Babel parser supports JSX, Flow and TypeScript out of the box. The Babel plugin @babel/plugin-transform-react-jsx parses the JSX code in this exact way. It delegates the responsibility of parsing the JSX code to the Babel plugin @babel/plugin-syntax-jsx : All this plugin does is modify the parser's options. The declare helper method maintains backwards compatibility with Babel v6. The plugin checks whether or not the TypeScript plugin ( @babel/plugin-transform-typescript ) has already ran. If so, then the plugin does nothing since the code (presumably written in TSX, the TypeScript variant of JSX) will have already been parsed and transformed by the TypeScript plugin. If there is no TypeScript plugin, then the plugin simply adds the "jsx" plugin to the parser's plugins option like in our previous example. Both the @babel/plugin-transform-react-jsx and @babel/plugin-syntax-jsx plugins are included in the @babel/preset-react preset, which is the most commonly used Babel preset for compiling React applications. Note : A preset is a collection of plugins. Instead of manually listing the individual plugins you want to enable for the Babel compiler, you just need to list one preset that contains these plugins. In fact, create-react-app uses this preset for compiling your React application. To transform JSX Code with the Babel plugin @babel/plugin-transform-react-jsx : ( .babelrc.json ) ( package.json ) That's it. When you run this npm script for the following JSX code: Then the outputted build.js file will contain only React function calls. Since the output contains only valid JavaScript, the code can be run within any browser (as long as the browser already has the React library loaded). As the JavaScript language continues to evolve and new specifications and proposals are introduced, Babel comes out with new plugins to add support these features even if they are not yet present in the target browsers. Think about ways you can use abstract syntax trees to automate tasks like code auditing/linting. Explore Babel's ecosystem of plugins and presets to use exciting new features like the optional chaining operator within your project's today regardless of browser support. You can also check out our new course,  The newline Guide to Practical Abstract Syntax Trees , for the practical techniques you need to maintain any size codebase.