Wiki Home Page

[x] Is the first page you see upon entering the wiki
[x] Contains a welcome message
[x] Contains a link/placeholder for a link to the live page
[x] All links in the right sidebar should contain each wiki page and link to the correct page
[x] Correctly formatted
- [x] each wiki page is listed in bullet points
- [x] all links route the correct page
  Comments
  
  Feature List
[x] Should have 7 Features.
- [x] 3 of those are User Auth, Hosting and Production README.
- [x] The other 4 are unique to this project
[ ] Contains a description sentence of the app
[x] Includes two to three detailed bullets on functionality and presentation of feature
[x] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
[ ] Estimates how long it will take the code each Feature
[x] Correctly formatted
- [x] Features are listed in an ordered list
- [x] Each Feature is broken down into bullet points
  Comments
I would focus on just the pages aspect and move the tables to be a bonus feature. Doing both is going to be too much work.
You can split up the collaboration features into 2 features or other feature suggestions could be Notebooks(Journals) or Hashtags to organize your pages.

Database Schema
[x] Contains correct datatypes
[x] Contains appropriate constraints/details
- [x] primary key
- [x] not null
- [x] unique
- [x] indexed
- [x] foreign key
[x] Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
- [x] foreign key and table name are lowercased, snake_cased and back_ticked
[x] Correctly formatted
- [x] schema is written in a table format
- [x] the table's name are lowercased, snake_cased and back_ticked
- [x] the table header column names are bolded
- [x] columns names are lowercased and snaked_cased and back_ticked
  Comments
The journal_pages table is not necessary since each page already has a journal_id reference on it.
Will multiple users own the same journal? If so then the user_journals table makes sense (but this could fall into the same purpose of the team_journals) . Otherwise this could be just a favorites table.
For teams I think you will need a user_teams joins table since a users and teams will be a many to many relationship.
Using quill.js I am hoping you will be able to have a singular text string that will contain both the text and styling in one, so you will possible be able to summarize this down to one field called something like body.

Sample State
[x] State shape is flat!
[x] State's keys are camelCased
[x] All keys within the values in the state are accessible in the schema
[x] Correctly formatted
- [x] Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
- [x] Top level slices
- [x] entities
- [x] session
- [x] errors (here or in ui)
- [x] ui (if needed)
- [x] Should NOT have nested slices, aka comments inside of posts
- Some info from other tables is ok, for instance:
- the author username and imageurl for a post. basically any info that the user can't change
- like count and a boolean on whether the user likes the post instead of a likes slice
  Comments
  
  Backend Routes
[x] Contains the following sections: HTML, API Endpoints(Backend)
[x] Each route has a description
[x] API Endpoint routes contains wildcard variables written in snake_case
[x] Routes does not contain superfluous routes
[x] Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
- probably doesn't need a GET likes api endpoint because that info comes through the post show
  Comments
Will need a routes for creating, deleting and updating a page.
Some journal routes mention chirps.
Need a GET route for session.
Need routes for teams.
Need routes for comments.
Need a route for your HTML

Frontend Routes
[x] Frontend routes contains wildcard variables written in camelCase
[x] Correctly formatted
- [x] Routes are displayed with inline coding text (backticks)
  Comments

ziqi23 / Zotion

Design Docs Checklist #1

Wiki Home Page

Comments

Feature List

Comments

You can split up the collaboration features into 2 features or other feature suggestions could be Notebooks(Journals) or Hashtags to organize your pages.

Database Schema

Comments

Using quill.js I am hoping you will be able to have a singular text string that will contain both the text and styling in one, so you will possible be able to summarize this down to one field called something like `body`.

Sample State

Comments

Backend Routes

Comments

Need a route for your HTML

Frontend Routes

Comments

ziqi23 / Zotion

Design Docs Checklist #1

Wiki Home Page

Comments

Feature List

Comments

You can split up the collaboration features into 2 features or other feature suggestions could be Notebooks(Journals) or Hashtags to organize your pages.

Database Schema

Comments

Using quill.js I am hoping you will be able to have a singular text string that will contain both the text and styling in one, so you will possible be able to summarize this down to one field called something like body.

Sample State

Comments

Backend Routes

Comments

Need a route for your HTML

Frontend Routes

Comments

Using quill.js I am hoping you will be able to have a singular text string that will contain both the text and styling in one, so you will possible be able to summarize this down to one field called something like `body`.