Add Phoenix LiveView POC shell: /chat and /timetable with persistent player

[Copilot]

POC migration of datafruits off Ember/Rails onto Phoenix+LiveView, built directly in hotdog_lounge. Adds two live routes (/chat, /timetable) inside a persistent site shell with top nav and fixed bottom player — player survives navigation without reloading or stopping audio.

Routing & LiveView shell

• live "/chat", SiteLive, :chat and live "/timetable", SiteLive, :timetable — single SiteLive module handles both via handle_params/3
• New Layouts.site_shell/1 component in layouts.ex: top nav with <.link patch> links, scrollable main slot, fixed bottom player
• Player marked phx-update="ignore" + phx-hook="Player" — LiveView never re-renders it, JS hook initializes once

<div id="player-container" phx-update="ignore" phx-hook="Player" ...>
  <audio id="player-audio" src="https://stream.datafruits.fm/stream" preload="none"></audio>
</div>

Direct Postgres access (no Rails API)

• HotdogLounge.Streampusher context with list_scheduled_shows/1 replicating the Rails Api::ScheduledShowsController#index filter logic:
  • show_series_id IS NOT NULL
  • join show_series where status = 0 (active)
  • start_at >= start_dt AND end_at <= end_dt, ordered start_at ASC
• Ecto schemas (ScheduledShow, ShowSeries) mirror the existing Rails table structure with @primary_key {:id, :id, autogenerate: false} — no new migrations against the Rails DB
• priv/repo/migrations/ creates these tables in the local dev/test DB only
• Datetime handling is UTC-only for now; proper America/Los_Angeles conversion (via tz/tzdata) is a follow-up

Timetable page

• Accepts start, end, timezone query params (same interface as the Rails endpoint)
• Defaults: today UTC + 30-day window, timezone stored for display
• Grouped by day via group_shows_by_day/2

Player JS hook

PlayerHook in app.js — play/pause toggle, volume control with localStorage persistence, initializes once on mount and survives all patch navigations.

Styling

Added --df-pink, --df-dark, --df-pink-light CSS vars and corresponding Tailwind utility classes to app.css for datafruits brand colors.

Original prompt

Create a draft PR in datafruits/hotdog_lounge implementing the initial Phoenix+LiveView POC shell for migrating off Ember/Rails.

Goals (POC scope):

• Add two LiveView pages/routes: /chat and /timetable.
• Use a single LiveView “site shell” layout with top nav and persistent bottom player region.
• Ensure the player does NOT reload or stop playing when navigating between /chat and /timetable.
  • Use LiveView patch navigation (no full page reload) and make the player DOM persistent via phx-update="ignore" (or equivalent) and JS hook if needed.
• Do NOT call the Rails JSON API.
• /timetable must read scheduled shows directly from Postgres using Ecto.
  • Mirror the Rails schema (existing DB) without migrations: map tables scheduled_shows and show_series at minimum.
  • Match Rails filter behavior from Api::ScheduledShowsController#index (streampusher-api):
    • only shows with show_series_id IS NOT NULL
    • join show_series where show_series.status == 0 (enum [:active, :archived, :disabled])
    • date range start_at >= start_dt and end_at <= end_dt
    • order by start_at ASC
  • Accept query params similar to the Ember usage: start, end, and timezone (defaults:
    • timezone: America/Los_Angeles
    • start: today (use server date)
    • end: start + 30 days)
  • Render a simple timetable list grouped by day.
• /chat can initially be a placeholder page in the new shell (integration with existing chat can be done later), but route must exist.

Styling/layout:

• Hotdog lounge already has Tailwind configured; use Tailwind classes for layout.
• Create markup structure compatible with future copy of datafruits nav/player markup; for now implement:
  • a top nav with links to /chat and /timetable
  • a bottom fixed player container that persists across navigation.

Technical notes:

• This repo already depends on phoenix_ecto, ecto_sql, and postgrex. Ensure Repo config uses DATABASE_URL in runtime.
• Add new modules under lib/hotdog_lounge/streampusher/ or similar for DB schema/context.
• Ensure @primary_key {:id, :id, autogenerate: false} for schemas mapping existing tables.
• Avoid breaking existing websocket /socket chat functionality.

Deliverables:

• New LiveView shell + router wiring.
• New Ecto schemas + query function.
• Timetable page showing scheduled shows from DB.
• Player persistence across nav (patch links + phx-update="ignore").

Out of scope:

• Now-playing metadata.
• Full markup/css copy from Ember (will come later).

Reference repos (for understanding only; do not modify):

• Rails schema: datafruits/streampusher-api has db/schema.rb and ShowSeries enum mapping.

Create the PR as a draft.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Can you make a proof of concept PLAN to migrate streampusher/datafruits to use only phoenix + liveview , no rails or ember?

backend: https://github.com/datafruits/streampusher-api/
frontend: https://github.com/datafruits/datafruits/

Perhaps we could migrate directly to the chat app:

https://github.com/datafruits/hotdog_lounge/

Assistant: Here’s a proof-of-concept migration plan to get datafruits + streampusher onto Phoenix + LiveView only (no Rails backend, no Ember frontend), with an option to migrate “directly to chat” by building on hotdog_lounge.

Repos referenced:

• Rails API backend: datafruits/streampusher-api (Ruby)
• Ember frontend: datafruits/datafruits (JS/Ember; points at CHAT_SOCKET_URL and API_HOST)
• Phoenix chat server: datafruits/hotdog_lounge (Phoenix; currently a chat app + Redis)

---

0) Choose a POC target (keep it small but end-to-end)

POC goal: replace one real user journey with LiveView backed by a Phoenix app, while still talking to existing systems where necessary.

Suggested POC slice (minimal but representative):

1. Render the homepage / “now playing” area in LiveView
2. Show chat (embedded LiveView component using Phoenix channels / PubSub)
3. Authenticate user (even if it’s a temporary/simple auth for POC)
4. Call one existing API feature (initially proxy to Rails, later reimplement)

This proves:

• LiveView UX viability
• Real-time + chat integration
• Backend API + DB patterns in Elixir
• Deployment topology

---

1) Decide migration strategy: “New Phoenix app” vs “Evolve hotdog_lounge”

Option A (recommended for clarity): Create a new Phoenix umbrella/app

Create something like datafruits_web (Phoenix + LiveView) that:

• serves the website UI
• contains new APIs (JSON) as needed
• integrates chat (either by embedding hotdog_lounge as dependency or by porting it)

Pros: clean architecture, easier to incrementally port Rails endpoints without dragging old chat design constraints.
Cons: you will run two Phoenix apps during transition (new app + hotdog_lounge) unless you port chat early.

Option B (your idea): “Migrate directly to th...

This pull request was created from Copilot chat.