CS计算机代考程序代写 javascript database Java flex jquery Project_ Complete Web App.pdf

Checklist

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

1. ! Project built using create-react-app in the root of the repo. Cleaned up extraneous files

2. ! Specified meta data in HTML (title, author, description, and own favicon)

3. ! Has sufficient content (about “2 web pages” worth)

4. ! Includes header element (with app name) and footer (with copyright) elements

5. ! Includes multiple separate and meaningful views of the data

6. ! Includes 2+ images or media content

7. ! Includes a form element

Details

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. 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!

iSchool Canvas Support

React Interactivity
Your app will need to use React to provide multiple well-designed interactive features. The user must be able
to provide input to the page (via e.g., button clicks, form submissions, mouse movements, etc) and see the
content of the page change over time in order to achieve some purpose. Your app will need to support at least
two (2) features (or three (3) for groups with 4 members). See “Details” below for what we mean by a “feature”.

This requirement category also covers the interactive React code needed to enable these features.

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).

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 React.renderDOM() 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.

Checklist

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 hierachy; each component reflects a “part” of the page

2. ! Components are appropriately sized/scoped (e.g., 2-3 DOM levels each)

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!

Details

iSchool Canvas Support

1. Your completed application will need to support at least two (2) significant interactive features. Groups of
4 will need to have three (3) features.

By “feature”, I mean specific set of user interactions that are used to achieve some goal (similar to a use
case (https://en.wikipedia.org/wiki/User_story) ). For example, a recipe app might allow the user to (1)
search and filter for specific recipes, and (2) save those recipes into a “recipe book” for later. A chat
application might allow the user to (1) send messages to other people and (2) organize messages into
diffent “channels” or groups.

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.

A feature is not necessarily just a single “interaction”—a button isn’t a feature.

Each feature will likley 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 “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 mostly 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 functinality 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 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.

User login. While supporting user accounts will help meet the Data Persistence 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 count as a feature.

Do not include “chat” or “comments” in your app unless you also have a way to moderate them
and/or prevent harassment, trolling, and spam. You should only provide commenting if it is truly
vital to the use of your app; in general commenting will NOT count as a feature. Don’t waste your
time on it.

iSchool Canvas Support

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 provding 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 interacion 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 aility 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 your app is required to have a form. A single form counts as a single user input, no
matter how many 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 would count as a point of
interaction.

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 componets 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!

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?”

iSchool Canvas Support

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 should be a set of
disconnected functionality, You’re doing a group project, not multiple individual projects in the same repo!

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 (https://www.cs.umd.edu/users/ben/goldenrules.html) . As with Project 1, good usability
means:

1. The interactive features of your app need to be discoverable—the user needs to know what
intractions 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
(https://en.wikipedia.org/wiki/Affordance) —clickable elements should look clickable (including aspects
like the cursor changing (https://developer.mozilla.org/en-US/docs/Web/CSS/cursor) ). 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
(https://v4-alpha.getbootstrap.com/components/alerts/) or a Snackbar
(https://material.io/develop/web/components/snackbars/) is useful for this. Do 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 (https://reactjs.org/docs/conditional-
rendering.html) (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 (https://www.npmjs.com/search?q=react+loading+spinner) 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

iSchool Canvas Support

Client-Side Routing and Navigation
Your application must be structured as a single-page application using client-side routing (specifically, using
the react-router (https://reacttraining.com/react-router/) library). Your application needs to have at least three
(3) different routes—having one per feature and for for a static “about” page is sufficient. While it’s a good idea
to make each route/url correspond to a different feature or use case to keep the app organized, this is not
required.

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!

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!

Checklist

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

1. ! App has 2+ interactive features (3+ for larger groups).
Features involve new, project-specific code

Features are complete user interactions

Features are unified

2. ! Features are interactive and state-based.
Has different user inputs (one of which is a form)

App respond to user actions/events

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

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

Details

iSchool Canvas Support

Integrates Another React Library
One of the main skills needed to write impressive web apps being able to harness the hard work done by
others, such as by using existing libraries that provide functionality for you. React’s architecture facilitates
implementing re-usable Components that allow you to easily add additional features and design elements to a
web app.

For this project, your web app must include and use at least one third-party React Component or library (other
than react-router ), rendering its provided components in the DOM.

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!

Checklist

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 s, s, etc).

2. ! Includes sufficient number of routes (3+).

3. ! Includes 1 route with a path parameter.

4. ! Handles incorrect URLs effectively.

Details

A couple of examples of possible libraries you could use:

The reactstrap (https://reactstrap.github.io/) 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 (https://material-ui.com/) for similar

effects)

Note that reactstrap is not the react-bootstrap library! The later is for older versions of Bootstrap
(though they have an update in beta). Do not mix up these two—pick one and use that!

iSchool Canvas Support

Using External Data

You can use the react-fontawesome (https://github.com/FortAwesome/react-fontawesome) library to
include Font Awesome icons as React components. This will clean up your HTML/CSS code a bit.

If your web app has a map, then you can use react-leaflet (https://react-leaflet.js.org/) to include a
Leaflet map as a React component.

You can include data charts in your app via a library such as recharts (http://recharts.org/#/en-US/) or
react-charts (https://react-charts.js.org/#/story/readme-documentation) .

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, though just using styling components from reactstrap will meet this requirement.

Libraries specified in other requirements (i.e., react-router , firebase ) cannot be used to meet this
requirement.

Only libraries that have renderable components count towards this requirement. Coding or architectural
utilities such as redux will not be sufficient (though the react-redux Provider component would let you
squeak by).

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!

Checklist

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. ! App does not mix library and non-library versions of elements (e.g., mixing Bootstrap with
reactstrap ).

iSchool Canvas Support

As part of (or in addition to) responding to user input and displaying dynamic content, your app will need to load
and use some external data (data from a file other than the .js script). This can either be a separate data file
(a .csv or .json file), or can be from a Firebase database (recommended).

Details

In this case, “external” just means “not part of the .js script. The external data used by your site can take a
couple of formats:

It can be a JSON or CSV file that was produced by someone else, such as a data set you wish to display.
Note that GitHub puts limits on the size of data files, so don’t try to load a huge data set at this point—you
can just get a subset instead (e.g., make a file that just has the first couple hundred records). If you want
to work with something bigger, you’ll need somewhere else to store that. If you use this option, your app
must contain a visible citation pointing to the source of the data set. Including a line “Data from https://…”
in the