Widoki issues (List / Board / Calendar / Activity)

Issues projektu renderują się jako sortowalna tabela, pogrupowana po statusie tablica Kanban, kalendarz ułożony wg dat issue, albo chronologiczny feed aktywności — ta sama tablica issues.data (a dla Calendar i Activity dodatkowo własne propsy calendarIssues i activityLogs) prezentowana na cztery różne sposoby, przełączane bez przeładowania strony przez płaski typ string IssuePageLooks. Ta kategoria dokumentuje, jak działa przełącznik i co trzeba zrobić, żeby dodać piąty widok.

Przewodniki, w kolejności, w jakiej faktycznie będziesz ich potrzebować

1. Dodaj nowy widok issuesWidoki issues (List / Board / Calendar / Activity)Dodaj nowy widok issuesPrzećwiczony przykład: dodanie piątego widoku, Timeline, obok istniejących czterech List/Board/Calendar/Activity. Sześć miejsc go potrzebuje — pomiń jedno,… — przećwiczony przykład dodania piątego widoku, Timeline, w każdym miejscu, gdzie podłączone są istniejące cztery: typ, switch renderujący, przycisk nawigacji (plus jego skrót klawiszowy), oraz selektor domyślnego widoku w Ustawieniach konta.

2. Leniwe ładowanie danych widokuWidoki issues (List / Board / Calendar / Activity)Leniwe ładowanie danych widokuStrona projektu nie wysyła danych każdego widoku przy każdej wizycie. Tabela i tablica czytają issues (jedna strona), Activity czyta activityLogs, a dane k… — opcjonalne propsy Inertia, zapytanie kalendarza z zakresem dat i dlaczego dashboard dostaje tylko liczby.

Architektura w jednym akapicie

IssuePageLooks (resources/js/types/Issues.ts) to 'List' | 'Board' | 'Calendar' | 'Activity' — zamknięta unia bez żadnej tablicy-rejestru za nią (w przeciwieństwie do SETTINGS_TABS z zakładek ustawieńZakładki ustawień/settings to nie jedna strona — każda zakładka pod nim (Preferences, Profile, Notifications, Security & access, Export w sekcji Account; Labels, Issue Type…), więc każdy konsument koduje na sztywno własną listę czterech wartości. Pages/Projects/Show.tsx posiada faktyczny stan selectedLook dla wizyty na stronie projektu, zasiewany raz z localStorage.getItem('selectedLook') przy montowaniu i renderowany przez płaski łańcuch ternarny (selectedLook === 'List' ? <IssueTable /> : selectedLook === 'Board' ? <IssueBoard /> : selectedLook === 'Calendar' ? <CalendarView /> : <ActivityLogs logs={activityLogs.data} />) — List i Board dostają to samo issues.data, po prostu prezentowane inaczej, Calendar czyta własne, opcjonalne calendarIssues ograniczone zakresem dat (zobacz przewodnik 2Widoki issues (List / Board / Calendar / Activity)Leniwe ładowanie danych widokuStrona projektu nie wysyła danych każdego widoku przy każdej wizycie. Tabela i tablica czytają issues (jedna strona), Activity czyta activityLogs, a dane k…), a Activity czyta zamiast tego activityLogs (paginator wpisów ActivityLogEntry, podłączony z ProjectController::show() przez ActivityLogService::paginateForProject() — zobacz ../activity-log/README.mdLog aktywnościKażda zmieniająca projekt akcja w całej aplikacji zapisuje zwykły tekstowy wiersz ActivityLog — "Changed Jane's role to admin", "Deleted the \"Owner\" role…, skąd bierze się ta ścieżka odczytu). Nieoczywiście, przełączenie widoku z nagłówka strony projektu aktualizuje tylko stan Reacta tej strony — nigdy nie zapisuje z powrotem do localStorage — robi to tylko selektor widoku issues w Ustawieniach konta → Preferencje (AccountSettingsPreferencesTab), co jest powodem, dla którego przełączenie widoków w trakcie sesji nie "trzyma się" po przeładowaniu w taki sposób, w jaki robi to zmiana domyślnego widoku w Ustawieniach. 1/2/3/4 są zarejestrowane jako globalne skróty klawiszoweSkróty klawiszoweKażdy skrót klawiszowy w Orbicie — ? po pomoc, mod+k, alt+p, scope'owane do strony p po "utwórz projekt" — przechodzi przez jeden system: ShortcutContext.… dla czterech widoków bezpośrednio wewnątrz Layouts/MainLayout.tsx, skategoryzowane jako 'View', który buduje też tablicę tabs renderowaną przez PageHeader dla przełącznika List/Board/Calendar/Activity.