Startup Submission 05: Dynamic UI

• Introduction
  • General Expectations / Assumptions
  • Database Expectations
    • Mock Database Limitations
  • Report
  • Updating Git Repository
    • Mock Database & Server
    • react-router
    • .eslintrc
  • Sanity Checks
  • Submission & Grading Rubric

While UCombinator reviews your startup’s ER diagram, it has preapproved your startup to work on a dynamic mockup! It is now time for you to set your UI in motion.

Introduction

Previous workshops describe how to translate the Facebook clone into a dynamic React application that:

• Uses React components to represent UI elements
• Uses a mock database to store its state
• Uses a mock server to update mock database state, and to expose database information to the application
• Uses react-router to create separate “pages” in your web application

Now, UCombinator wants to see your startup apply the same structure to your product. The UI components in your many HTML files should be turned into React components where appropriate. Your application should only use a single HTML file with the filename index.html. You should use react-router to link to different “pages” of your application.

Please see the grading rubric for details on how we will grade your submission.

General Expectations / Assumptions

We will be lenient on submissions that have some issues with their dynamic functionality. However, you must carefully articulate the outstanding bugs in your submission and a plan on how you intend to fix your issues. You must provide this information in your document otherwise we will assume a fully functional submission and score you accordingly. Furthermore, if the bugs that you outline in your submission for #5 are not fixed by the submission deadline of the next startup submission #6 UCombinator’s score for #5 will reflect the broken parts. As such, you are encouraged to fix any problems you might have as soon as possible.

If your product has a link or a button, it should work.

Your dynamic mockup should assume a single user is already logged in, and should be fully functional for that user. For example, if your product lets users post items for sale, we should be able to post an item for sale. If your product lets users claim items that other users put up for sale, your mock database should have mock user accounts with items that they put up for sale. Those items should show up in item listings, and we should be able to claim them as that user.

If your product supports multiple types of accounts, there should be a way to use the mockup as each type of account. You could introduce a temporary link in your product’s navigation bar that lets us use the product as a different type of user.

If a portion of the product relies on some external source of data (e.g. GitHub, Twitter…), you can choose to mock the service or use the service’s API directly if appropriate. You should aim to do whichever is easiest.

If your product has a search feature, you do not have to implement search completely. Your real database will take care of search using database queries. However, searching in your application should return results from your mock server – even if they are incorrect.

Finally, you can choose to reduce the scope of your product if the workload is too heavy. Your report should describe any features you have decided to cut.

Database Expectations

Like with the workshops, your React components should use mock server methods to retrieve state from / update state in the database. We will expect that the state changes we trigger, e.g. posting an item for sale, will still display even after we close the browser and open it up again. Doing this correctly now will save your startup from a lot of pain later when you add a real server and database to your application!

In addition, we expect that you will add a “Reset Database” button into your layout. This button will reset the mock database back to the initial set of objects you hand-define in database.js. We have coded the button for you; all you need to do is add an HTML element with id db-reset into your HTML layout, and the button will automagically appear when your product begins using the database.

Mock Database Limitations

The mock database has a maximum size of 5 megabytes. This should be fine for simple text data, but will not work well if you are trying to store images or anything large into it.

If the user provides your application with large pieces of data, such as photographs or video recordings, mock it up completely – let the user supply these pieces of data. When you go to store it in the database / render it, replace it with a standard piece of mock data.

For example, if you are writing a Facebook clone that lets users post photos, your dynamic mockup should:

• Bring up a file selection dialog when the user clicks the “Upload photo” button.
• Display a mock picture instead of the selected picture once the user selects a photo to upload.

Later on, when you attach a real database to your product, you will revisit these features and complete them in their entirety.

Report

Add a report to your repository as reports/submission_05.pdf that:

• Carefully articulate the outstanding bugs in your submission and a plan on how you intend to fix your issues
  • You must provide this information in your document otherwise we will assume a fully functional submission and score you accordingly
• Describes your product’s key React components, and what parts of the UI they are responsible for.
  • Example: Feed renders the user’s content feed on the main page
  • Example: FeedItem renders a single post within a user’s Feed
  • Example: OnlineList renders the user’s list of online friends within the product’s chat feature
• Describes what each startup founder contributed to in this submission
• Describes any product features you have decided to cut
• If your mock objects are different from your previously submitted ER diagram, include an updated ER diagram in the report

Updating Git Repository

Your startup will need to make a few changes to your Git repository to prepare for this submission.

Mock Database & Server

The previous workshops used a repository that comes equipped with a basic mock database and a helper function for a mock server. Your startup needs to add similar files to your product for this submission.

Download the mock database module here, and place it into your app/ folder. Modify the startupName variable at the top of the file to be your startup’s name as a JavaScript string (e.g. "TikTak"), and modify initialData with mock data as we did in the workshops.

Download the mock server here, and place it into your app/ folder. As in the previous workshops, add server methods to this file. This is the only file that should interact directly with your mock database. All of the exported methods you add into this file should use the emulateServerReturn function to return data to the main application. We will dock points if you do not do this.

One member of your startup should add, commit, and push both of these files to your Git repository.

react-router

To use react-router in your product, one person from your startup needs to add it to your package.json with the following command, which they should run within your repository folder:

$ npm install --save-dev react-router

Then, that person needs to commit and push the change to package.json.

The other people in the startup need to pull that change, and run npm install within the repository folder to install the new dependency.

Now, you can reference react-router like the code in the previous workshops.

Your startup can add additional npm dependencies using this command if you want to use them in your mockup.

.eslintrc

You will want to modify your ESLint file to add additional rules for React. These should help you write bug-free React code.

Have one member of your team replace the contents of your .eslintrc with the following text:

{
  "extends": "eslint:recommended",
  "ecmaFeatures": {
    "arrowFunctions": true,
    "binaryLiterals": true,
    "blockBindings": true,
    "classes": true,
    "defaultParams": true,
    "destructuring": true,
    "forOf": true,
    "modules": true,
    "octalLiterals": true,
    "restParams": true,
    "spread": true,
    "templateStrings": true,
    "unicodeCodePointEscape": true,
    "jsx": true
  },
  "env": {
    "browser": true,
    "node": true,
    "commonjs": true
  },
  "plugins": [
    "react"
  ],
  "rules": {
    // Rules for React (see list here: https://github.com/yannickcr/eslint-plugin-react)
    "react/no-unknown-property": 1,
    "react/jsx-no-duplicate-props": [1, { "ignoreCase": true }],
    "react/jsx-no-undef": 1,
    "react/jsx-uses-react": 1,
    "react/jsx-uses-vars": 1,
    "react/no-deprecated": [1, {"react": "0.14.6"}],
    "react/no-direct-mutation-state": 1,
    "react/no-is-mounted": 1
  }
}

Remember to commit and push this change.

Sanity Checks

Before the deadline, make sure your product works from a fresh git clone of the repository with the following commands:

$ git clone [repository]
$ cd [repository folder]
$ npm install
$ npm run serve

If it does not, then UCombinator will have trouble evaluating your product!

Submission & Grading Rubric

• 20% Written report
  • 10% Contains a clear, understandable description of your product’s key React components, and what parts of the UI they are responsible for.
  • 10% Contains a clear explanation of what each startup founder contributed to the submission
• 10% Product is completely dynamic using React
  • HTML files should not contain any hardcoded mock data
  • React components should only hardcode something like the ID of the “current user” and fixed UI components – the rest should come from the mock server
• 10% Product uses client-side routing via react-router to make key pages linkable
  • If your startup has prior experience with alternative client-side routing libraries, you are free to use those
• 30% Product uses the mock database appropriately to store its state
  • 1% Product contains the “reset database” button from the mock database
  • 9% Interactions with the product persist across browser sessions
    • In other words, if we do things on the product, close the browser, and re-open it, they should still be there!
    • If your product doesn’t do this, then you are likely using the database incorrectly
  • 10% Product communicates with the database properly through a mock server
    • …including using emulateServerReturn to return data from all exported functions
  • 10% Contains an initial set of objects in the database that match the structure of the ER diagram from the prior submission
    • If you end up deviating from the previously submitted ER diagram, please include an updated diagram in your report
• 30% [Individually] Transitioned the static UI of a major product feature into a dynamic UI using React, and accurately portrayed contribution in report.

Please submit a URL to Moodle of your startup’s repository by the due date of this assignment