m8825 / villow

Zillow - popular real estate website clone.

WELCOME TO VILLOW

Check out the live site

Introduction

Villow Clone is a replica of the popular real estate website Zillow. Villow is a platform that allows users to buy, sell, and rent properties. It provides a comprehensive database of real estate listings, including houses, apartments, and land. Users can search for properties by location, price, and other criteria, as well as save their favorite listings. The technologies used in this project include:

• Languages: Javascript, Ruby, HTML and CSS
• Frontend: React-Redux
• Backend: Ruby On Rails
• Database: PostgreSQL
• Hosting: onRender
• Asset Storage: AWS Simple Cloud Storage (S3)

User Auth

A Villow user is able to create new profiles, which persist to both the front and backend.

Index Page

Users can browse listings on the index page using Google Maps markers based on their address.

Navigation Cards

The site features convenient navigation cards for major pages. Pixel perfect copy of navigation cards from scratch.

Villow was created within a 14 day time frame. Thank you for your time and consideration! I hope you enjoy it!

villow's Issues

Issue #05 - Frontend Routes

Frontend Routes

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

Comments

1. Apologies Malkhaz, these comments for some reason didn't get added.
2. This structure for your frontend routes looks very sparse, but solid right now. It might change in the future, but excited to see if you can give full functionality with as little URL route changes as possible.

Awesome work all around, Malkhaz! As far as I'm concerned, your design documents are approved. Please let me know if you have any concerns.

Issue #01 - Wiki Home Page

Wiki Home Page

• 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

Comments

1. Hey Malkhaz, be sure to add pages for your Sample State, Frontend Routes & Components, and Backend Routes as well. Otherwise, looking solid!

Issue #03 - Database Schema

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

Comments

1. Formatting wise, be sure to add a title of "Postgres Database Schema" above your database schema. Additionally, be sure to use backticks (`) to make your column names and foreign keys shaded. For example:

• "id" should be id
• "index on username, unique: true" should be "index on username, unique: true"

2. You've used bigint data types for a lot of columns that should be integer. bigint is mostly reserved for id and foreign key columns. Be sure to change that.
3. Should your listings' air_cond and parking columns be booleans?
4. In your favorites table, you should probably change your owner_id column to a favoriter_id. The user this foreign key refers to should be the user who favorited the listing, not the listing's owner. This makes more sense semantically.

Please let me know once you've made these corrections/additions. Thanks!

delete node_module directory in root

Issue #02 - Feature List

MVP List

• Should have 7 MVPs.
  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the Approved Apps List or your PM will 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

Comments

1. Hey Malkhaz, for your User Auth MVP, that should unofficially include your Splash Page as that will offer your users a chance to Sign Up or Login. I would also make a note that on unsuccessful sign up or login, errors will be rendered.
2. Your four Main Features' bullets are a bit sparse as of now and I'd like to see more thought on these. I can provide an example. Currently, your Google Maps feature lists that you'll be implementing the Google Maps. What I'd expect to see is more along the lines of:

• Seeded homes will be rendered on Google Map API element.
• User will be able to interact with the API to pull up a home's show modal and zoom in and out of the map.
• User will not be required to sign in/up before using the Map feature.
  Hope this gives a better idea.

3. Also, your estimated time is putting your work at 11 days (with Render Hosting and Production README). We have roughly 14 official days to work on this project, so I would reallocate to estimated time for Listings and the Google Map API maybe.

Issue #03 - Sample State

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

Comments

1. Looks solid! My only concern is that you should not reveal your users' session_token or password_digest within your frontend state. Nix those please, then feel free to close this issue.

Demo user doesn't close modal and redirects to Splash page

Issue #04 - Backend Routes

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

Comments

1. Awesome work!

User auth

• #10
• User Sign Up input fields hover doesn't change colors like in Sign In inputs
• About me links don't work
• Decide about forgetting the password. Most likely, remove it.
• SIng in button doesn't work.
• User create button doesn't work.
• Relocate close button.
• Separate LoginUser.js styling
• Sign Out doesn't re-render, and Navigation doesn't update user profile icon with sign in button