Given the current state of the proposal, it is hard for me to provide you with valuable feedback and help you avoid common mistakes as part of the development of your product, especially since the component hierarchy and the wireframes are missing, that particular document wires together the state, routes and overall your whole application.

Let's address the feedback detailed below ASAP.

Wiki Page Home

• Is the first page you see upon entering the wiki
• Contains a welcome message
• Contains a link/placeholder for a link to the live page
• All links in the right sidebar should contain each wiki page and link to the correct page
• Correctly formatted
  • each wiki page is listed in bullet points
  • all links route the correct page

MVP List

• Should have 7 MVPs.

  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the MVP List or they have clarified them with you

• Contains a description sentence of the app

• 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 MVP

• Each App specific MVP needs the following bullet points are added:

  • Adequate styling
  • Smooth, bug-free navigation
  • Seeded with info to demonstrate this feature

• Correctly formatted

  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points

Database Schema

• Schema represents the data to be used in the application.

  • Lets break full_name in the authors table into firstname and lastname. That way we can display the user's firstname if required.
  • In fables, to which tables does category_id point to? Or will you be using rails enums?
  • Do we need a category_id column for the comments table?
  • Will all users be authors? Or will we have users that can also be authors? If yes i would suggest renaming the table to users.
  • Your MVP's talk about bookmarking, but not table is keeping track of this.

• Contains correct datatypes.

• Contains appropriate constraints/details

  • primary key
  • not null
  • unique
  • indexed
  • foreign key

• 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

• Correctly formatted

  • schema is written in a table format
  • the table's name are back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked

Routes

• Routes accurately reflect MVPs and Component Hierarchy
  • I dont think your app has chirps, check your GET /api/authors.
  • Should the route really be authors? Or users?
  • There are no routes for bookmarking.
• Covers the frontend functionality of the site through routes that match to the wireframes
• Contains the following sections: HTML, API Endpoints(Backend), and Frontend Routes
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
  • Lets keep it consistent, lets replace the :id matcher to :fable_id on the fables endpoint.
• Frontend routes contains wildcard variables written in camelCase
• Routes does not contain superfluous routes
• Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
• Correctly formatted
  • Routes are displayed with inline coding text (backticks)

Comments:

Sample State

• State shape is flat!
• State's keys are camelCased
• All keys within the values in the state are accessible in the schema (Ex: if you create a imgUrl key in the state, make sure your database also has a column that contains an img_url)
  • What's the difference between a bitable_id and a chunkable_id?
• Correctly formatted
  • 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
  • Top level slices
    • entities
    • session
    • errors (here or in ui)
    • ui (if needed)
  • 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

Component Hierarchy with Wireframes

• All routes listed in the routes wiki page is also listed in the component hierarchy
• Each component, if necessary, has route, state, and other components it renders example
• Necessary components are wrapped in a container
• Correctly formatted
  • Bullet point hierarchy
  • Component names are displayed with inline coding text (backticks)
• Wireframes included
  • Every component listed in the component hierarchy wiki page has at least one wireframe
  • Every MVPs listed on the MVP wiki page has at least one wireframe
  • Every route listed on the route wiki page has at least one wireframe
  • Contains Containers
  • Contains multiple Index/List
  • Contains multiple IndexItems/ListItems
  • Correctly formatted
    • Wireframe images display on the page
    • Every wireframe has a header title

Comments:

This section is missing from the wiki.

• Backend: DB, model, controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components and Containers
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

• Logged in users can comment on fables
• Comments use same editor as fables (coming with editor)
• Adequate styling
• Smooth, bug-free navigation
• Seeded with info to demonstrate this feature

• There is a public main feed for all users
• Logged in users have feed based on follows (to be completed during bonus)
• Adequate styling
• Smooth, bug-free navigation
• Seeded with info to demonstrate this feature

• Logged in users can write fables
• Logged in users can edit existing fables
• Adequate styling
• Smooth, bug-free navigation
• Seeded with info to demonstrate this feature

• users can search for Fables/users
• Adequate styling
• Smooth, bug-free navigation
• Seeded with info to demonstrate this feature