Project: Complete Web App

1. This requirement includes the project structure. Your app will be need to be built using Vite, as described in the "Getting Setup" section. Note that you'll need to have "cleaned up" the auto-generated files; there should not be anything extraneous in your repository!

2. You'll need to specify the meta data (author and description) for your page in the HTML, modifying the index.html file provided by Vite.

   You'll also need to specify your favicon—do not use the default React icon!

   Note that you will not have more than 1 HTML file—your app will be built as a single-page application (and you'll use client-side routing to show multiple different pages.

3. Your page content can be structured however you wish, but must include a header Links to an external site. with appropriate content (including the name of your app) and a footer Links to an external site. with appropriate content (e.g., copyright and contact info).

4. Overall, your web app needs to have sufficient content to make its layout and styling necessary. Just having a single data table won't be sufficient.

   One way to ensure you have sufficient content is to make sure your app displays multiple different views of your data. For example, you could display a list of cards as one view, and then allow the use to select (click) on a card to see further details on that record as a second view. You can also display your data in different formats (such as a table and a chart), as long as the different views are meaningful and there is a point to having them both! An interactive map (such as one created with Leaflet Links to an external site.) or chart (such as created with Plotly Links to an external site.) are other ways of presenting content, though will not likely count as "interaction" (see below).

5. Your web site will need to include both text content and at least three (3) notable images or other media content (videos, etc). You are welcome to use stock images if appropriate. Unsplash Links to an external site., Morgue File Links to an external site., and Pixabay Links to an external site. are all good places to start looking for free images. Make sure you have the rights to any images you use, and include appropriate attribution Links to an external site..

   Note that the text and images on your page will need to be actual content, not just lorem ipsum placeholder text! You're developing a "real" app!

6. Your app will need to include a form (using the <form> element) allowing the user to submit some input to the app to interact with it. This can be a "search" or "filter" form. I suggest you aim to have at least two inputs (not just a single text query) in the form to help make your interaction sufficiently complex.
7. Your app's content needs to be meaningful: it must be complete and real. Any buttons or links on your site need to go somewhere or do something; if they are not functional, remove them! While it's okay to have some "seed" data, user-specific content should not be automatically populated. For example, a new user joining the site should not see a list of "friends" that they haven't actually specified.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Project built using Vite in the root of the repo. Cleaned up extraneous files
2.   Specified meta data in HTML (title, author, description, and own favicon)
3.   Includes sufficient content (e.g., multiple views of the data)
4.   Includes header element (with app name) and footer (with copyright) elements
5.   Includes 3+ images or media content
6.   Includes a form element
7.   Content is meaningful (no "junk" data)

1. You will need to organize your app into appropriate Components (with informative and semantically-meaningful names!). You will need to have more than one Component (lots more!), with each Component representing a small, self-contained portion of DOM. You should design Components around the different data views of your app—you do not need to create a new Component for each HTML element, unless there is some specific logic/data that the element uses. Build a clear Component hierarchy!

   Tip: Think about what are the different "parts" of your webpage (that change in response to user interaction), and make a Component for each one! Or for each piece of "data" think about how that datum will be rendered—that's a Component!

   A good rule of thumb is that each component should render 2-3 levels of the DOM tree (so have 2-3 levels of nested elements). Less than that and maybe it shouldn't be a separate component; more than that and you should consider breaking it up. This is not a hard rule, just a guideline.

   Components will need to be self-contained. They should render based purely on their props, without caring about where they are used in the DOM or what else is around them.

2. Your components will need to use props and state appropriately—pass data between components as props, and use state to keep track of any dynamic values. Remember that state should be kept minimal; use props whenever you can! (That said, your app will need to track some state somewhere—it can not be all props). Note that we will not be learning or using Contexts in this course, so you should not use them in your application.

3. Your app should only use Components to render content. You must NOT use DOM methods or jQuery—all rendering and DOM manipulation must happen via React state manipulation and render calls. There should be no references to document or $ in any of your Components or any of your code (other than the ReactDOM.createRoot() call).

While there aren't a lot of details in this requirement, it is central to fulfilling all the rest of the requirements (you need to effectively use the framework), making it a vital piece of your project.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   App is broken up into a meaningful component hierarchy; each component reflects a "part" of the page
2.   Components are appropriately sized and scoped around data props
3.   Components are defined as self-contained entities
4.   Data is passed through the app via props to components; props and state are appropriately distinguished.
5.   Content is only rendered on through components—no DOM calls!

1. Your completed application will need to support at least "two and a half" significant interactive features—the "half" can be a smaller feature, so long as it still demonstrates the full range of the course material.

   By "feature", we mean a specific set of user interactions that are used to achieve some goal (similar to a use case Links to an external site.). For example, a recipe app might allow the user to (1, small) search and filter for specific recipes, (2) organize (and reorganize!) those recipes into a "recipe book" for later use, and (3) upload new recipes the site. A chat application might allow the user to (1) send messages to other people, (2, small) organize/filter messages from different "channels" or groups, and (3) organize groups of people/friends who can receive messages.

   • Note that all of these examples involve complex interactions. A feature is not just a single button to press. "Viewing" content isn't a feature, nor is navigating to different content. An interactive feature involves the user providing input in order to change some of the data displayed in the app.
   • Think about features not in terms of code, but in terms of the task that the user is able to complete! The interaction needs to actually do something meaningful. You are not being graded on "business value", but there should be a point to this interaction.
   • Each feature will likely have its own "view" and URL route (see below). If the features don't seem like different "pages" of the app, then they may not be different!
   • Integrating Firebase's database is a good way to drive a feature, but is not a feature in itself. "User login" is also not a sufficient feature on its own. There has to be some purpose to the user logging in! That is, the app needs to behave differently depending on who is logged in.

2. Each feature needs to be involve new, project-specific implementation (code). A feature only counts if it's something you created. Functionality that is copied or substantially adapted from problem sets does not count as a feature. For example, you could include a "search filter" or a "comment" system if that is vital to your app's functionality, but it wouldn't count as a "feature" if you just copy the functionality from the exercises—you will need to go beyond that and do more. Similarly, functionality that is offered entirely through an external library is not sufficient (e.g., showing a Leaflet or Google map is not a feature, no matter how much interactivity they provide).

3. The following are not considered sufficient features on their own:

   • A search form. Just displaying the results of a user search will not be considered a complete feature. The user would need to do something meaningful with the result of that search—such as view additional details for each result, interactively filter the data, or interactively visualize/graph the results. Your feature needs to be more than "just" a search form. A simple filter will be covered in an exercise; your app will need to support something more complex than that for it to count.
   • User login. While supporting user accounts will help meet the Firebase requirements below, just providing a login form is not a feature on its own. User accounts will need to be used in support of some other interaction. That said, almost any actual use of user accounts will probably count as a feature.
   • Generic comments or chat. We'll build a basic chat app as a demo; your project needs to be something else (or something beyond that). If you want your app to include some kind of social communication as its primary purpose (e.g., you're making a Slack clone), then you need to support social interactions by providing some kind of moderation or other ways to avoid spam/trolling/harassment—just letting people post messages isn't sufficient for a feature.

4. Your features should be complete, in that the user should be able to use your app to achieve their goal—not to only get halfway. We shouldn't use your app and be left thinking "now what?" or "but what do I do with this?". For example, a recipe app can't just have a button to "save recipes" without providing anything to do with those saved recipes! Note that just "seeing results of a search" is rarely a satisfying end point (and often won't meet the interaction requirements). What do people do with their results? What's the next step?

5. Features need to be interactive—they involve the user providing input to the page, which then changes its display in response. Static content (e.g,. a "resources" page) is not considered a feature for this assignment.

   Each feature will need at least its own form of user input in order to be interactive. The user needs to be able to interact with or provide input to different DOM elements to perform different actions for each feature. For example, you could have a form that that lets the user filter the data displayed (one feature), and then the ability to save data records into a sublist (second feature).

   • Inputs that influence the display in the same way—such as two different filter buttons, or "on" and "off" buttons that toggle a single change, or a "switch views" button—will not count as distinct features. Remember that a "feature" is larger than a single button or "interaction"/
   • Remember that your app is required to have a form. A single form counts as a single user input, no matter how many <input> elements make up that form.
   • It is also possible to have a feature in which the content automatically change periodically (e.g., having something update every minute to provide a "live feed" of data). This can count as a form of input (provided it is dynamically changing).

6. In React, this means that the page needs to re-render and display different Components/props in response to user actions/events. Thus you will need to have some event handling defined in your components.

   Interactions need to be state-based: interactions need to both read and write to a Component's state. Your app must use Component state in a legitimate and significant way. There should be multiple interactions that modify the state, and there should be at least some part of the state that is modified by multiple different interactions (considering the previous state value). If your interactions don't require storing any state data, then they won't meet the project requirements!

   • State information must be stored in the "lowest common ancestor" of the hierarchy as possible—do not save all of your state in the top-level App component! Lift the state up only when necessary, passing callback functions so child components can manipulate the lifted state.

   • Interactions must be visible in the page itself, not just in the developer console! Note that "reloading" a page (such as from following a hyperlink) is not considered a form of interaction for these purposes. Links are not features!

   IMPORTANT: The fundamental pieces of an interaction are: (1) handling user input events, (2) updating state based on that user input, and (3) rendering content based on the updated state. If you don't have that cycle, then you haven't implemented an interactive feature.

7. Each feature's interaction (the user input and display change it causes) needs to be purposeful—they need to manipulate the displayed content in a way that helps the user better understand the information or achieve some goal. Do not add inputs just for the sake of adding inputs! A button that just reveals more buttons isn't a feature or a worthwhile interaction. We should never left asking "why did I have to click this?"

   This is to some extent a usability requirement, but it's also intended to make sure your features are within scope. Note that interactions that change the display based on a user input will almost certainly be purposeful.

   Similarly, all your features need to be unified and connected in some way. Your app must not be a set of disconnected functionality, You're doing a group project, not multiple individual projects in the same repo!

   Features need to be unique within the project. For example, multiple "filter" forms that that filter different parts of your data would not be considered a single feature (because they'll use the same code).

You may need to think hard about how to make your data meaningfully interactive. If you get stuck or are having problems, please check in with us and we can help you brainstorm!

8. Interacting with your app should be a pleasant and frictionless user experience. Your app should have good usability Links to an external site.. For this project, good usability means:

   1. The interactive features of your app need to be discoverable—the user needs to know what interactions are available. This includes instructions for usage and clear labels on elements is needed to make the page intuitive to use. The user should never wonder "where do I click now?" or "what does this button do?"

      This also means that elements should be clear about their affordances Links to an external site.—clickable elements should look clickable (including aspects like the cursor changing Links to an external site.). Note that this should apply even to screen readers—use semantic HTML and ARIA attributes for clickable components when appropriate!

      We should be able to figure out how to use your app without needing a manual! If more details are needed, make sure your app provides them.

   2. Your app needs to provide feedback to the user about their actions (so the app doesn't look like its broken). For example, there should not be noticeable delays between user input and the site's response (you can work around slow responses by giving feedback such as a progress spinner).

      Similarly, inform users of any errors that occur; your app should not "silently crash". Provide such feedback by rendering an element to the DOM—a framework component such as an Alert Links to an external site. or a Snackbar Links to an external site. is useful for this. You may not use the window.alert() function; all displayed content must remain in the browser.

      • In React, if an error occurs you can save that error value in the state, which will then re-render the component. Have the component conditionally render Links to an external site. (using an if statement) an "alert" component or element to display the error.

      Be sure to show users some kind of visual feedback while your code is performing asynchronous network actions (e.g., communicating with the Firebase servers). This can be a simple "working..." message, or you can use something more professional like an animated spinner icon. There are a number of libraries Links to an external site. that might make this easy.

      • One basic strategy: right before you send a request (e.g., to sign in a user or post some data), begin showing the spinner. Once that request is finished (the .then() is executed), stop showing the spinner.
      • You must also inform the user of any errors when using Firebase. For example, if the user attempts to sign in with invalid credentials, you should .catch() and display the error message from Firebase, and then make sure that they can try again!

      Note that all any feedback or alerts to the user need to be rendered "in-page". You cannot use the window.alert() (often just written as alert()) function; use conditional rendering through React instead.

There are a lot of details for this requirement, but in short: include sufficient interactive features, use component state, and make sure the interactions are smooth to use!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   App has 2.5 interactive features.
   • Features involve new, project-specific code
   • Features are complete user interactions
   • Features are unified
2.   Features are interactive and state-based.
   • Features respond to different user inputs (one of which is a form)
   • Interactions both read and write to state variables
   • Interactions are visible in the page (not just console log); they change displayed content depending on user input
   • Features provide interaction via the event-state-render cycle.
3.   State information is stored at appropriate levels (in the "lowest common ancestor")
4.   Interaction is pleasant and frictionless:
   • Interactions are discoverable (include instructions)
   • Interactions provide feedback, including on errors—particularly for Firebase

• Remember that you will need to install the react-router-dom library and import its provided Components in order to use them!

• To receive full credit for this portion of the project, you must include at least one route that uses a path parameter (e.g., /route/to/:itemId) in a meaningful way. Note that having both /items (which shows a list of items) and /item/:itemId (which shows a single item's details) counts as two different routes.

  Firebase database ids make great (if not human readable) path parameters!

• When implementing routes, be careful to test all paths of navigation that a user might take to make sure that no data is being lost (such as the user being logged out of your website). If the user mistypes a url, your app should not break!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Correctly integrates react-router (specifying <Route>s, <Link>s, etc).
2.   Includes sufficient number of routes (3+).
3.   Includes 1 route with a path parameter.
4.   Handles incorrect URLs and changes in access (e.g., login/logout) effectively.

A couple of examples of possible libraries you could use:

• The react-bootstrap Links to an external site. library provides React implementations of Bootstrap components, from Component versions of things like Buttons and Forms to interactive elements such as Carousels. (For a Material Design site, you can use e.g. Material-UI Links to an external site. for similar effects). To meet this requirement, you will need to include an interactive widget such as a Carousel or Dropdown, not just a styled <Button> element.

• If your web app has a map, then you can use react-leaflet Links to an external site. to include a Leaflet map as a React component.

• You can include data charts in your app via a library such as recharts Links to an external site. or react-charts Links to an external site..

And there are many, many more possible libraries; you are encouraged to search around and explore! Thing about what kind of functionality/component you need, and do a search for {TOPIC} react—you'll probably find something! Note that you may need to tweak the functionality of your app to provide a place to use an external component.

• Libraries specified in other requirements (i.e., react-router, firebaseui) do not count towards meeting this requirement.

• Only libraries that have renderable components count towards this requirement. Coding or architectural utilities such as lodash or redux will not be sufficient.

When searching for other libraries, be sure to evaluate their quality before you use them! Look at the documentation on GitHub: can you understand how to use the library in a few minutes? Has the repo been updated recently? Does it have lots of stars and forks suggesting it is popular? If the answer to any of these questions is "no", you may want to look at something else to do the same work.

In order to use a library in your application you will need to install it with npm, import the provided Components, and instantiate them with appropriate props when you render() them. Part of this requirement is to be able to install, load, and use a library cleanly!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Project imports another library (included in the package.json list of dependencies).
2.   App imports external components.
3.   App renders imported components (they do something).
4.   Library components are used in a meaningful way (support the functionality of the app)

You will be using Firebase to store data.

• You should use the realtime database to store data for this course; do not use the Firestore database. It is acceptable to also use Firebase Storage if you wish to store images or media.
• You are not required to support user authentication, but most projects will want to have some kind of user-specific data.
• You can store site-based data (e.g., recipes, chat messages), or you can store user-specific data (e.g., a person's favorite recipes or chat preferences). Be sure that any user-specific data is isolated to that user! Remember that such data separate from user accounts (the accounts themselves are not data).

Your app will need to both read from from and write to the Firebase database (the data needs to be dynamic and changeable!) Remember that these are two separate processes: you read from the database by registering a value listener (usually when the component loads), and you write to the database by pushing or setting values (e.g., in response to user actions).

• Reading data from Firebase is an asynchronous process, so will need to be specified in an event hook. When the data has been loaded, you can process it and assign it to a state value, which will be rendered by the component.
• Writing data to Firebase is an asynchronous process; you will need to include catch() clauses to handle any errors that may occur (and will be produced by the Promise).
• Be sure to properly handle any errors that occur and provide feedback to the user that something went wrong.

You can display the data you load directly, or use it to otherwise customize the interactions the user makes—but your app needs to actually use the data in a significant way! Also make sure that your app remains usable while you want for the data to load (such as by showing a spinner).

The primary purpose of using something like Firebase is to provide data persistence—data inputted by the user will be available even when the page has been refreshed, visited a second time, or accessed from a separate computer. Persisting data to e.g., local storage will not meet this requirement.

You will want to connect to and download data from Firebase when the app loads.

This also means that your page will need to be able to load and render correctly whether hte data has been created or not!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   App integrates Firebase web service
2.   App both reads from and writes to a Firebase (realtime) database
3.   Firebase access is properly integrated with React (e.g., through effect hooks)
4.   Catches and manages (e.g., displays) errors, from both data writing and authentication
5.   Firebase data is rendered in the app in a meaningful way
6.   Completed app successfully deployed to Firebase hosting

It is acceptable to use a CSS framework such as Bootstrap when styling your app, though if you do so you must use the most recent version (v5 for Bootstrap) as introduced in class. Moreover, even if you use a framework to help style your app, you will need to include some additional CSS rules of your own to demonstrate your mastery of this material.

As a simple heuristic, something at the design complexity of the iSchool home page or Twitter Links to an external site. would be worth full credit, while something that looks as nice as reddit Links to an external site. would be around 80% credit (satisfactory). And remember: just duplicating features and effects from the exercises will not be worth full credit—do something on your own!

1. You must use CSS to style the page. Define an external stylesheet (e.g., style.css) to contain your rules.

   We expect you to have a few dozen (20-30+) different CSS rules for this project; you will need that much complexity for the work to be satisfactory. These rules would be in addition to any framework provided styling.

   Your page design should include modifications to all of the following: typography (fonts), colors (text or background), spacing (margin/padding), and layout (see below). It's fine if many of these changes are provided by Bootstrap, but you will need to include custom rules yourself. Note that you can use a a tool such as the Material Design Color Tool Links to an external site. to help determine an accessible color palette (and avoid contrast issues). (Adobe Color CC Links to an external site. is another nice color palette tool).

   You are welcome and encouraged to go all-out on the artistry—just make sure that the page's content remains navigable, readable, and usable!

2. In order to demonstrate your development skills, your app must not entirely follow the default "flow" of content. You must also use a flexbox or grid to provide substantial "non-standard" layout structures. A multi-column layout is sufficient for full credit (and see Responsiveness below for related requirements). Note that simply using a flexbox to make elements horizontally "inline" will not be sufficient; you should use something like a multi-column layout.

   It's acceptable to use a Bootstrap grid to meet this requirement.

   Best practice is NEVER use the float or position properties! Use a flexbox instead!

3. Your design (read: CSS styling) needs to be deeply considered with a high level of polish and refinement. This means that you've thought about (and customized!) aspects of the appearance like the color, typography, positioning, etc. While this course does not focus on visual design, we want to make sure that you've actually considered how to use CSS to make a modern and pleasant looking webpage.

   You've all visited popular web sites; you should have a sense for what pages "look good" and what pages don't!

   For us, a polished app design is:

   • readable and navigable: we are able to see all the content, and move through the content without getting confused. Text is large/clear enough to read, buttons say what they do, links are obvious, etc.
   • consistent: colors, borders, fonts, spacing, etc. should be consistent throughout and across pages. Ideally, pages should have a shared visual language: for example, elements that are both "cards" should have similar purposes/meanings (see e.g. the explanation here Links to an external site.).
   • "clean": make sure that images or text content doesn't overshoot its container, that elements line up with each other, etc. There shouldn't be any visual "bugs".

4. You must use Vite's build system for loading external libraries and CSS files (import the CSS files through your JavaScript). You should not need to include any <link> elements in your HTML, and will definitely not have any additional script elements!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Loads an external CSS style sheet
2.   Stylesheet includes sufficient number of rules (20+)
3.   CSS changes:
   • colors
   • fonts/sizes
   • margins/padding
4.   Uses flexbox or grid for non-standard layout (via Bootstrap is fine)
5.   Has a polished appearance
   • readable & navigable
   • consistent
   • clean
6.   CSS files and libraries are imported through JavaScript

1. For semantic html, this means appropriately using elements such as <main> and <section> (though you don't need the latter if there are no sections), headings are used for headings (not to change font size), that you don't use <i> when you mean <em>, etc. Also remember that <a> elements are for links (navigation), while <button> elements are for interactive elements. Choose the element that reflects what happens when you click on it (and then style it to look however you want).
2. For navigable html, make sure that your headings form a clear hierarchy. Don't skip heading levels. Think of them as producing a "table of contents" for your content!
3. There are particular elements (such as <label>) that you will need to use for forms. Be sure to include them! Links to an external site..
4. Don't forget your alt attributes! If you have an image or graphic that is included via a div or something, make sure to give it an aria-label.
5. If necessary, make sure to use ARIA attributes (particularly if you utilize components of a CSS framework). Remember: ARIA attributes are for when HTML isn't sufficient! Specify role Links to an external site. attributes for interactive elements (such as when you have a div that acts like a button). But don't over-use it; you don't need to specify ARIA attributes for elements that are already semantic!
6. Also make sure that your color choices have sufficient contrast to be accessible. You can use WebAIM's contrast checker Links to an external site. to check.

You can run your web page through an accessibility checker such as WAVE Links to an external site., AChecker Links to an external site., or Chrome Lighthouse Links to an external site. to confirm it is accessible. Or better yet, open up a screenreader such as Voice Over and try listening to your work!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Uses elements semantically (no <i>; <a> for links, etc)
2.   Correctly uses sectioning elements (<main>, <section>, etc); not needed if no sections
3.   Uses hierarchical headings; doesn't skip levels
4.   Includes alt attributes on all images
5.   Form includes <label> elements (with for attribute)
6.   Includes aria-label and role attributes when necessary (and only when necessary!)
7.   Colors have sufficient contrast

Note that just using a CSS framework such as Bootstrap is not sufficient for this requirement; your CSS must include some media queries to receive full credit.

1. Your site needs to be optimally styled for two categories of screen size: small mobile screens and large desktop screens. In particular, your site needs to be styled to look noticeably and meaningfully different on different screen sizes to accommodate their different affordances. For example, your site could switch to multiple columns as the screen gets large, change the size of cards, add additional images or content, etc. Your media queries need to do something meaningful!

   Styling differences can include layout, white-space, font-sizing, media presence, and more.

   Just having content "wrap" on smaller screens—even if that wrapping is performed with a flexbox—is not sufficient. We need to see that you've used responsive CSS to purposefully and intentionally customize the page for both small and large displays. This may feel a bit forced, but it's part of demonstrating your mastery of the material! Note that using responsive Bootstrap elements (like a responsive grid) can help meet this requirement.

   Remember that you need to do something beyond what is in the exercises to get credit!

2. You must follow mobile-first design principles Links to an external site. when implementing your page. In fact, I encourage you to take a "mobile-first" approach to both your design and to your implementation: make it work on mobile, and then expand to work on desktops.

   Remember to specify the viewport meta so that your page will actually be responsive!

   Using a CSS Reset file such as normalize.css Links to an external site. or Bootstrap Reboot Links to an external site. is a good idea for making sure your site looks the same across browsers.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Specifies a viewport meta
2.   Includes media queries to handle 2+ sizes (at least small screens and large screens)
3.   Mobile-first CSS: media queries at the bottom (modify the small-size default)
4.   Styling changes on media and large screens
5.   Layout is noticeably and meaningfully different on different screen sizes
6.   Page content is polished on all screen sizes

1. All your code needs to be well-organized in your repo. You should use multiple files (modules) and folders to organize your React Components to make sure your structure is clear and readable. DO NOT put your entire app into a single App.js file with thousands of lines of code! Break it up into parts so it's easy to understand the organization of your app.

2. HTML code needs to be valid and well organized. For example: only use block elements inside of block elements, etc.

   Please also use clear and consistent indentation/spacing when writing your HTML (in React!) so it's easy to read.

3. CSS code needs to be well designed and organized. Use descriptive class names (not just .thing1). Only use id selectors when accessing DOM elements from the JavaScript; otherwise use class selectors for styling (they are cleaner). Avoid duplicating CSS rules/properties; use a shared class or group selector instead. Be sure and use comments to help organize your CSS (e.g., "block out" which rules apply to which part of the page).

   Remember to use a "mobile-first" approach! That means that your media queries should be at the bottom, after you've defined the "normal" rules.

4. Your JavaScript code (apart from the React framework) needs to show good programming style.

5. You should effectively use the React framework when implementing your site. This includes:

   • Developing effective and well-scoped and named Components (see above for details)
   • Using function components and hooks as taught in this course. If you find other examples/tutorials that use class components, you should switch them to match the overall style of your app if at all possible.
6. If you inline a .map() function inside of a return statement your project will not be considered satisfactory. Do not do that! This is very messy practice; use a separate variable to help with testing and readability!
7. Whenever the code becomes difficult to understand (or just very long), be sure and include comments and documentation explaining how it works. There are not specific commenting requirements and you do not need to comment every line of code (in fact you probably don't need many comments at all!), but you should provide comments whenever the code does anything complex to help the reader follow what is going on.

8. Be sure to check the developer console for warnings and errors, including linting/styling warnings, and to address those! Your code should run cleanly without any warnings or errors.

   (There are no provided Jest tests for linting; you'll need to just check the developer console of your running app).

9. When in doubt, consult the course text style guide Links to an external site. or ask us!

Coding style is important for readability (so we can understand your work!) and for maintainability (so you can iterate on this in the future). Thus it is vital that your code is well-written per the requirements of this class. Poorly written code may make a project unsatisfactory until the problems are fixed, regardless of the quality of the site produced.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Follows all the guidelines in the course text style guide Links to an external site..
2.   Organized files in repo
3. Valid HTML
   •   No invalid usage
   •   No redundant elements
   •   Clean and consistent indentation
4. Well-designed CSS
   •   Informative class names
   •   Effective selectors (e.g., no id selectors)
   •   No inappropriate duplication of rules
   •   Organized in file, with comments to "group" sets of rules
5. Well-written JavaScript
   •   Informative variable and function names
   •   Uses let and const instead of var
   •   Functions avoid side effects (pure-ish)
   •   Sensible variables and data types (especially arrays vs. objects)
   •   Remove extraneous console.log calls
6.   Correct and idiomatic usage of React framework
7.   Uses well-scoped and informatively-named function components and hooks
8.   Does not define functions (including inline .map()) inside of a return statement or inline expression!
9.   Includes comments if and only if necessary for understanding the code.
10.   Running app does not present any errors or warnings in the developer console.