This is a full-stack web application that comprises both back-end and front-end components. If deployed to production, the back-end part would run in the cloud (think Amazon Web Services or Azure), while the front-end would execute inside the user's web browser (like Chrome for Android, or Firefox for desktop).

As a front-end engineer, your focus is mainly on the files that load on the user's device. In this particular case, these files live inside the frontent folder. The backend folder contains a web server built in Node, but the project as a whole is managed as a Node application. As such, it contains a package.json file at the root, containing some meta-information like name and version, and a few useful scripts developers can use as they work on the app, like "npm test".

1. You will clone this repository to your computer, which will allow you to run the software locally for development and testing purposes.

2. You will navigate your terminal to the project folder and execute npm install. This will install the libraries declared inside package.json. Some of these packages are needed for the back-end to do its job of serving JSON data and front-end assets. Other libs help with things like testing and linting your code.

3. After successful installation you will run, in separate terminals, two of the scripts found inside package.json. To do this, execute npm start in your first terminal, and npm test in your second. On successful start, you will load the app in Chrome by navigating the browser to http://localhost:3003. The term "localhost" means "your machine", and the number is called a port, allowing multiple web servers to run on the same computer, with one server per port.

4. If you haven't already, install the Eslint extension for VSCode. It will highlight syntax errors and problems right inside your editor, which saves tons of time.

My job assisting you with local setup of the app is done! You will speak to our designer next.

Collaboration between a designer and a web developer can be very powerful. Designers excel at creating amazing user experiences and have a keen eye for beauty and usability, while developers are experts in the underlying technology of the product.

However, it's important to remember that if a design for a feature exists, it's not a suggestion. Your job as a web developer is to implement the design with as much fidelity as possible. While a developer might think they have a better way to arrange elements on the screen, the mocks and designs are the result of research and hard work. It's important to treat them with the respect they deserve.

It's crucial to use the readable texts designed for the user interface verbatim. If a design reads "Loading Doughnuts...", then "Loading Your Doughnuts..." is incorrect. Attention to detail is critical!

There are other constraints and requirements that must be followed, such as sticking to certain class names or keeping the structure of the HTML a certain way to avoid breaking the CSS.

Fortunately, you have a very detailed mock that you can load in your browser and inspect in detail, which will make your job much easier. And don't worry, you don't have to write any CSS because it's already been taken care of!

Hey! Let's make sure you're up to speed with your action items so far.

• The app is installed on your machine, with both start and test scripts running in terminals.
• You studied the mock in the Elements tab of Dev Tools.
• You saw how some text contents and some class names change as the user clicks around.

Awesome! Our back-end engineer says that the JSON data needed to build the Learner Cards comes from two endpoints:

• Endpoint A [GET] http://localhost:3003/api/learners
• Endpoint B [GET] http://localhost:3003/api/mentors

❗ You should stop now, and try out both endpoints using Postman, to see what they return.

Here's the tricky thing: each learner has a short list of mentors, but the response from Endpoint A only identifies the mentors by their ID numbers. This means you will need to match the mentor IDs from Endpoint A with the real names of the mentors, found in the response from Endpoint B.

For fetching, just await the Axios request to Endpoint A, and then await the request to Endpoint B. (Optionally, you can use Promise.all to handle both requests. We do not need the data from request A in order to start request B, so the requests can happen concurrently instead of back-to-back.)

Once you have the payloads from Endpoints A and B stored inside variables, check that they match what you saw in Postman, and then use your JavaScript skills to combine the two lists into a single data structure that is comfortable to work with. Ideally, it would look something like this:

[
  // etc
  {
    id: 22,
    email:"[email protected]",
    fullName: "Mickey Mouse",
    mentors: ['James Gosling', 'Mary Shaw'] // ❗ actual names instead of IDs!
  },
  // etc
]

Once you have the data in the right shape, you can create a component function that takes a single learner in the format above as its argument, and returns a Learner Card. Then just loop over the data, generating cards as you go, and attaching them to the DOM.

Make sure that each element you create uses the exact same class names and text contents as those in the design! Also, render the learners in the same order as they arrive from Endpoint A.

As for interactivity, all the behaviors on the page as the user clicks on the cards boil down to changes in text contents of some elements, and changes to some class names which can be observed in the mock. Do not use any other mechanisms!

It might seem like you need several click handlers on different elements inside the card, but that would just make the code more complicated. Remember, events bubble up from the target to its ancestor elements! It's easier to just attach an event listener on the card element, and then check who the target of the click is before taking the appropriate action.

❗ Only make changes to the frontend/index.js file.

Reach out if you get too stuck, and have fun!

You submit via Codegrade. Check the assignment page on your learning platform.

This project requires Node correctly installed on your computer in order to work. Your learning materials should have covered installation of Node. Sometimes Node can be installed but mis-configured. You can try executing npm run fixit (check package.json to see what this does), but if Node errors are recurrent, it indicates something wrong with your machine or configuration, in which case you should request assistance from Staff.

No. Everything you need should be installed already, including Axios.

The CSS is the domain of a different team, and in this particular project we're not supposed to touch it. Do not use inline styles to get around this limitation! It will only make the CSS team angry. And believe us, you want CSS specialists happy because they can write CSS twenty times faster than you.

This particular part of the product is a Single Page Application, so the HTML is mostly empty and the page is generated automatically using JavaScript. We would not want to manually edit HTML files in a website that changed all the time! It would be untenable.

Save your changes, and reload the site in Chrome. If you have a syntax problem in your code, the app will print error messages in the Console. Focus on the first message. Place console logs right before the crash site (errors usually inform of the line number where the problem is originating) and see if your variables contain the data you think they do. If there are no errors but the page is not doing what it's supposed to, the debugging technique is similar: put console logs to ensure that the code you are working on is actually executing, and to check that all variables in the area hold the correct data.

Execute npm test in your terminal. These are the same tests that execute inside Codegrade. Although this never crossed your mind, tampering with the test file won't change your score, because Codegrade uses a pristine copy of the original test file, mvp.test.js. If a particular test is giving you grief, don't jump straight to the code to try and fix it. Go to Chrome first, and make sure you can replicate the problem there. A problem we can reliably replicate is a problem mostly fixed.

On occasion the test runner will get stuck. Use CTRL-C to kill the tests, and then npm test to launch them again. Try to reproduce the problem the test is complaining about by interacting with the site in Chrome, and do not code "to make the test happy". Code so that your app does exactly what the mock does. The tests are there for confirmation. Although it's possible that a particular test be flawed, statistically it's more likely that the bug is in your own code. If the problem persists, please request assistance from Staff.

If you need to disable all tests except the one you are focusing on, edit the mvp.test.js file and, as an example, change test('👉 focus on this', () => { etc }) to be test.only('👉 focus on this', () => { etc }). (Note the "only".) This won't affect Codegrade, because Codegrade runs its own version of the tests.

As web developers, we often don't have control over our sources of data, and it's common to have to combine JSON from various sources into a data structure that works for the front-end. Even if the endpoints were under our control, and the back-end team were willing to build a new endpoint or improve existing ones, bug fixes and features sometimes can't wait that long.

Do NOT delete your repository from GitHub! Instead, commit frequently as you work. Make a commit whenever you achieve anything and the app isn't crashing in Chrome. This in practice creates restore points you can use should you wreak havoc with your app. If you find yourself in a mess, use git reset --hard to simply discard all changes to your code since your last commit. If you are dead-set on restarting the challenge from scratch, you can do this with Git as well, but it is advised that you request assistance from Staff.

Although a small, "old-fashioned" website might be made of just HTML, CSS and JS files, these days we mostly manage projects with Node and its package manager, NPM. Node apps typically have a package.json file and several other configuration files placed at the root of the project. This project also includes automated tests and a web server, which adds a little bit of extra complexity and files.

Web projects can be organized in a million ways, there aren't many standards. Some developers like it like this, while others prefer to use opinionated frameworks, which do a lot of magic but prescribe that folders and files be structured and named just so.

This way we can easily import your code as a single function in the mvp.test.js test suite. The export syntax is at the bottom of index.js. The function declaration is prefixed by the async keyword to allow you to use await inside it.

The package.json file contains meta-information about the project like its version number, scripts that the developer can execute, and a list of the dependencies that are downloaded when you execute npm install. There can be some wiggle room to allow newer versions of the dependencies to be installed, so the package-lock.json file, when present, makes sure the exact same versions of everything are used every time the project is installed from scratch.

This file works in combination with the Eslint extension for VSCode to highlight syntax errors and problems in your code. By editing this file you can customize your linting rules.

Jest is a framework that allows you to write tests and execute them, to alert you very quickly of problems with the code. Jest can do in seconds what an entire Quality Assurance team would take hours or even days. In the context of the Sprint Challenge, Jest is used to check your code against specification and give you a grade (% of tests passing).