emmahyde/grouper

GeoCities meets the modern era.

grouper's Issues

Support Mutual Friendships

Currently, when a Friendship is made with user: user_A, friend: user_B, no reciprocal record is made in order to reflect the mutual nature of friendships in the User associations (if I am a friend to someone, they are a friend to me).

Acceptance Criteria

• friend "requests" are represented by the Friendship table, and are reflected by a single Friendship record
• Once a request is "accepted", a reflecting Friendship record is made against the request, i.e.
  Friendship(user: user_B, friend: user_A)
• Therefore, a mutual friendship is qualified by there being 2 Friendship records that reflect each other, where each User is the base :user in one record, and the :friend association in another.
• In other words, a mutual friendship is qualified by both associated Users having a "request" to the other through the medium of the Friendship table.

Thoughts

another option is that Friendships have some sort of status that indicates if it has been accepted, but I don't love this solution because the Friendship table will turn into the wild west if there is no rhyme or reason to why a user is sometimes the base :user and sometime the associated :friend in any given Friendship. This also means we have to do a lot of funky stuff in order to get the friends for a given user, since they could be in either column. It will additionally make SQL queries for finding/evaluating mutual friendships more demanding.

yet another option is that we use an entirely different data model to represent FriendshipRequests. This allows us to be more descriptive and explicit at the data model layer and in our naming conventions about our intended behavior and usage, but will similarly lead to confusion around the Friendship data model itself.

Github CI Workflow for Specs

rails/rails#50502

Authentication

We must authenticate.

Automate testing

Stretch Goal: Chat

This will probably be its own repo, but im adding it here so as not to forget.

Consistent "theme" across pages

Deploy

Gotta get it live

stimulus

Style Login Page

The login page is very sparse!

Handles

We want people to have fun names, but also unique identifying names.

Images and Media Uploads

Problem
Users need to be able to upload media (profile pictures, pictures in posts, videos, etc.).

We will need a pipeline and probably a dedicated service for handling media uploads.

Solutions?
s3 + Active Storage?
https://guides.rubyonrails.org/active_storage_overview.html

Rspec

Main Feed Page

Need a main feed page!

• Posts in chronological order
• nav menu
• "create post" form

Bug: Logging in doesn't always redirect to main page

Per the title. Seems like an issue with logging out and back in again.

Dockerize

I need docker practice, so why not baby. Get this thing in a Docker container.

Posts

https://github.com/emmahyde/sharesphere/wiki/%5BData-Model%5D-Posts

Profile Page

Need a profile page for users!

There are 2 obvious patterns for profile CRUD. The first would be to direct new users to create their profiles when they first log in or register. Filling out the form would optional, either via a "skip" button or by just letting them submit the empty form. This feels like the more professional/logical route.

The second option would be to direct users to the main feed on first login. If they want to edit their profile page, they can by visiting their own profile and clicking an "edit" button. This feels a bit more slippery, and not exactly intuitive, but I'm not certain that is a bad thing...

In the interest of time, I'm going with the second. It's faster to do and I can always add that other flow later.

Elements

• About/Description
• Slug
• Posts History
• Friends List
• Follow/Friend/Subscribe button
• Edit button (should not appear if the current user does not match the profile)
• Tests

Stretch

• Profile picture
  • "upload pfp" form
  • See: Issue #25
• Images/Media