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

Need a main feed page!

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

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

We must authenticate.

          🤣 I know, it looks awful, and the connection with the actual controller actions is so tenuous. 

I was thinking of writing a helper module for stuff like this to make it more readable. It would be really cool if we could make something like Phoenix's verified_routes. That way we wouldn't need to have magic strings. We could round up all the controller actions in the JS at compile time and set a global verified_stimulus_actions map. The tough part would be somehow generating all the valid event triggers to go with them... maybe we wouldn't have to though. Ending up with something like this:

$verified_stimulus_actions = { 'modal': ['closeEnd', 'submitEnd'] }

... then have a macro/resolver of some kind check if the action exists and fail more visibly if it does not:

module StimulusHelper
  def verify_action (action)
    check_for_action($verified_stimulus_actions)
  end
end

...Something like that anyway.

In the meantime, I was thinking something like this just for readability:

module StimulusHelper
  def action_list(actions)
    actions.join(' ')
  end
end

...
### modal_component.html.erb
<tag.div id:'modal-overlay;
  data: {
    controller: 'modal',
    action: StimulusHelper.action_list(["turbo:submit-end->modal#submitEnd", "keydown.esc@window->modal#closeWithEscape"])
  } do %>
  <%= content %>
  <% end %>

Originally posted by @Shaka-n in #44 (comment)

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

Main Site: https://viewcomponent.org
Github Repo: https://github.com/viewcomponent/view_component
Extension Gem (Great Documentation): https://github.com/palkan/view_component-contrib

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

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

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.

Not sure what's causing it, my hunch is something is wonky in the asset pipeline. Doesn't seem to affect functionality:

When routing to one's own profile:

Specific Error:
ActionController::RoutingError (No route matches [GET] "/assets/application.js-ce8c17eeebb9b11cacb863a7e968d703ae8ee0625ac2f1406725887ca5eb6c4e.map"):

Full Trace:
Finished "/cable" [WebSocket] for 127.0.0.1 at 2024-03-22 11:42:42 -0400
Hotwire::Livereload::ReloadChannel stopped streaming from hotwire-reload
Started GET "/assets/application.js-ce8c17eeebb9b11cacb863a7e968d703ae8ee0625ac2f1406725887ca5eb6c4e.map" for 127.0.0.1 at 2024-03-22 11:42:42 -0400
Started GET "/cable" for 127.0.0.1 at 2024-03-22 11:42:42 -0400
Started GET "/main_feed.turbo_stream" for 127.0.0.1 at 2024-03-22 11:42:42 -0400

ActionController::RoutingError (No route matches [GET] "/assets/application.js-ce8c17eeebb9b11cacb863a7e968d703ae8ee0625ac2f1406725887ca5eb6c4e.map"):

Started GET "/cable" [WebSocket] for 127.0.0.1 at 2024-03-22 11:42:42 -0400
Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE: websocket)
Processing by FeedsController#main_feed as TURBO_STREAM
User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
↳ app/controllers/application_controller.rb:5:in `current_user'
Rendering feeds/main_feed.turbo_stream.erb
SQL (0.5ms) SELECT posts.*, users.id as user_id, users.name as user_name, "posts"."id" AS t0_r0, "users"."id" AS t1_r0, "users"."name" AS t1_r1, "users"."email" AS t1_r2, "users"."created_at" AS t1_r3, "users"."updated_at" AS t1_r4, "users"."password_digest" AS t1_r5, "users"."unique_name" AS t1_r6, "users"."display_name" AS t1_r7 FROM "posts" INNER JOIN "users" ON "users"."id" = "posts"."user_id" ORDER BY "posts"."created_at" DESC LIMIT $1 OFFSET $2 [["LIMIT", 15], ["OFFSET", 0]]
↳ app/views/feeds/main_feed.turbo_stream.erb:2
Rendered collection of posts/_post.html.erb [12 times] (Duration: 8.3ms | Allocations: 6672)
Rendered feeds/main_feed.turbo_stream.erb (Duration: 16.0ms | Allocations: 13051)
Completed 200 OK in 20ms (Views: 16.8ms | ActiveRecord: 0.6ms | Allocations: 15810)

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

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

rails/rails#50502

Gotta get it live

The login page is very sparse!