Design Docs To Do List

[mwmadsen67]

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
• Includes two to three detailed bullets on functionality and presentation of feature
• 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
• Correctly formatted
  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points

---

Database Schema

• 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
  • foreign key and table name are lowercased, snake_cased and back_ticked
• Correctly formatted
  • schema is written in a table format
  • the table's name are lowercased, snake_cased and back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked

---

Sample State

• State shape is flat!
• State's keys are camelCased
• All keys within the values in the state are accessible in the schema
• 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

---

Backend Routes

• Contains the following sections: HTML, API Endpoints(Backend)
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
• 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:
  • probably doesn't need a GET likes api endpoint because that info comes through the post show

---

Frontend Routes

• Frontend routes contains wildcard variables written in camelCase
• Correctly formatted
  • Routes are displayed with inline coding text (backticks)

[mwmadsen67]

Hi Everett, here are a few notes on your design docs so far:

MVP List:

• Formatting is solid
• Search is often it's own MVP in people's projects (although personally I think it is a very quick MVP), so that is something to keep note of for your trail guide MVP. I would recommend keeping it to searching by trail name at the beginning and add additional search query options later. This MVP will likely take more than 2 days. I would also potentially push back trail saves as a bonus MVP. In general each table is typically it's own MVP for most projects, since you have to build it from models to controllers and jbuilders to actions, reducers, and components.
• Adding and deleting photos should be one MVP, and trail notes should be a separate MVP, in my opinion. In that case I would probably make comments a bonus MVP, since it wouldn't be too difficult to add after doing reviews.

Schema:

• locale might be something you want to add after trails are complete. Your trail MVP is going to be extensive so starting simple will save you potential headaches.
• My biggest concern here is how you will mark/display your trail route on a map. I would imagine something like your waypoint table except it is just for marking lat and long along the map, is associated with a trail route, and has some kind of ord column so that you can connect the dots.
• Otherwise everything else looks great and is well thought out.

State-Shape:

• Looks great, nothing really to add here.

Happy to meet and talk about the schema again at some point, also feel free to comment here with any questions.

[mwmadsen67]

Sidenote about marking locations along a route: Another way that I've seen this done is by making a column in your trail_route which is a string of a bunch of points like so: "[[90.123, -111.938], [89.234, -112.845], ...]"

[evrtt]

Hey Mike,

Thank you for the comments, they are very helpful.
I am going to update my design docs today at lunch with the following recommendations you have made (the projects the last couple days have really drilled home the need for simplicity here, at least to start).

1 - make searching its own MVP,
2 - limit search to trail name,
3 - make trail saves a bonus,
4 - make adding and deleting photos its own MVP,
5 - make trail notes its own MVP,
6 - make comments a bonus feature
7 - make locale a bonus feature
8 - address the route issue by adding a trail_route_coords column in my trail table with a nested array of coordinate pairs as strings.

I am going to use the mapbox api for my map and plan to get more familiarized with that this weekend.
I also plan to get familiarized with AWS Hosting.
I may make some slight adjustments to my design docs this weekend as my understanding how these two external pieces will fit into my project changes, if that is okay. But I will not be expanding the complexity or making any major changes beyond what you have suggested.

Will you have time to touch base this afternoon or on Monday after the assessment?

Thanks!