slackr-master-交付.zip

# Assessment 3 - Vanilla JS: Slackr 1. Background & Motivation 2. The Task 3. Getting Started 4. Constraints & Assumptions 5. Marking Criteria 6. Originality of Work 7. Submission 8. Late Submission Policy ## 0. Change Log * 8/10: Bonus marks section added (was accidentally removed); Couple of typo fixes * 9/10: Clarified which users can edit a channel's details (Only the channel's users can) * 10/10: Removed "insertAdjacentHTML" from 4.5., ReactJS from marking criteria and changed 75% -> 80% 2.8. ## 1. Before you start ### 1.1. Background & Motivation Web-based applications are becoming the most common way to build a digital capability accessible to a mass audience. While there are modern tools that help us build these rapidly, it's important to understand the fundamental JavaScript-based technology and architectures that exist, both to gain a deeper understanding for when these skills may be needed, but also to simply understand the mechanics of fundamental JS. Even when working with a high level framework like ReactJS, understanding (in-concept) the code that it is transpiled to will ensure you're a more well rounded web-based engineer. This assignment consists of building a **frontend** website in Vanilla JS (no ReactJS or other frameworks). This frontend will interact with a RESTful API HTTP backend that is built in JavaScript (NodeJS express server) and provided to you. A theoretical background on how to interface with this API can be found the "promises & fetch" lecture. The web-based application you build is required to be a single page app (SPA). Single page apps give websites an "app-like feeling", and are characterised by their use of a single full load of an initial HTML page, and then using AJAX/fetch to dynamically manipulate the DOM without ever requiring a full page reload. In this way, SPAs are generated, rendered, and updated using JavaScript. Because SPAs don’t require a user to navigate away from a page to do anything, they retain a degree of user and application state. In short, this means you will only ever have `index.html` as your HTML page, and that any sense of "moving between pages" will just be modifications of the DOM. ### 1.2. Lectures to watch You will _need_ to watch at least the following lectures before starting (it will help you get started): * Everything from assesssment 2 You will _need_ to watch at least the following lectures to finish the assessment completely: * [Local storage](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/javascript-browser-localstorage) * [Events & Callbacks](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/javascript-async-callbacks) * [Promises](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/javascript-async-promises) * [AJAX Introduction](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/ajax-intro) * [Fetch](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/ajax-fetch) * [UI Fundamentals](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/ui-fundamentals) * [Perceivability](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/accessibility-perceivability) * [Operability](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/accessibility-operability) * [Understandability](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/accessibility-understandability) * [Robustness](https://cgi.cse.unsw.edu.au/~cs6080/23T3/content/lectures/accessibility-robustness) ## 2. The Task Your task is to build a frontend for a UNSW rip-off version of the popular messaging tool [Slack](https://slack.com/). If you haven't used this application before (or similar applications like Discord, Teams), we would recommend creating your own slack workspace to place around with the tool. UNSW's rip-off of slack is called "Slackr". However, you don't have to build the entire application. You only have to build the frontend. The backend is already built for you as an express server built in NodeJS (see section 3.2). Instead of providing visuals of what the frontend (your task) should look like, we intend are providing you with a number of clear and short requirements about expected features and behaviours. The requirements describe a series of **screens**. Screens can be popups/modals, or entire pages. The use of that language is so that you can choose how you want it to be displayed. A screen is essentially a certain state of your web-based application. ### 2.1. Milestone 1 - Registration & Login (15%) This focuses on the basic user interface to register and log in to the site. #### 2.1.1. Login * When the user isn't logged in, the site shall present a login form that contains: * an email field (text) * a password field (password) * submit button to login * When the submit button is pressed, the form data should be sent to `POST /auth/login` to verify the credentials. If there is an error during login an appropriate error should appear on the screen. #### 2.1.2. Registration * When the user isn't logged in, the login form shall provide a link/button that opens the register form. The register form will contain: * an email field (text) * a name field (text) * a password field (password) * a confirm password field (password) - not passed to the backend, but an error should be thrown on submit if it doesn't match the other password * submit button to register * When the submit button is pressed, if the two passwords don't match the user should receive an error popup. If they do match, the form data should be sent to `POST /auth/register` to verify the credentials. If there is an error during registration an appropriate error should appear on the screen. #### 2.1.3. Error Popup * Whenever the frontend or backend produces an error, there shall be an error popup on the screen with a message (either a message derived from the backend error response, or one meaningfully created on the frontend). * This popup can be closed/removed/deleted by pressing an "x" or "close" button. ### 2.2. Milestone 2 - Creating and viewing channels (10%) Milestone 2 focuses on creating **channels**, and viewing the basic channel screen layout for a single channel. #### 2.2.1 Viewing a list of channels * The application should present a list of all public channels created. This will be visible on every screen for a logged-in user. * The user should also be able to see a list of all private channels they have joined. This will be visible on every screen for a logged-in user. * The two types of channels should be distinguishable visually. * Selecting a channel should take the user to the single channel screen. This single channel screen should show the channel's messages and other features (implemented in `2.3`). * If a user has logged in, but has not selected a channel yet, there are no rules around what the main body of the screen should display (reminder: the list of channels should still be visible somewhere, in some form). #### 2.2.2 Creating a new channel * Users should be able to create a new channel via some kind of form. * The trigger to display the form should be accessible on any screen with no more than 2 clicks. * Users should be able to enter the name, an optional description, and public/private channel type. * Note: the description should be optional for the user but the backend requires a description. #### 2.2.3 Viewing and editing channel details * When viewing a single channel screen, certain information should be accessible/visible within 0-1 clicks. * This information includes the name of the channel, description, public/private setting, creation timestamp (as a time/date not as an ISO string, flexible to whatever you think is user-friendly), and name of the creator of the channel. * Users should be able to edit the channel's name and description in some way. Channel details can only be edited by users who are in the channel. * If the user is not a member of the channel, they do not