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 Types, Priorities, Documents, Members, Roles & management, Integrations w sekcji Workspace) ma własną trasę, własną akcję kontrolera i własną stronę Inertii, więc wejście na zakładkę ładuje wyłącznie dane tej zakładki. Jedna tablica-rejestr, SETTINGS_TABS, wciąż opisuje każdą zakładkę na potrzeby nawigacji. Ta kategoria dokumentuje ten rejestr oraz trójkę trasa/kontroler/strona za nim, a także dwa różne kształty "dodaj zakładkę": włączenie już zbudowanego placeholdera i dodanie zupełnie nowej od zera.

Przewodniki, w kolejności, w jakiej faktycznie byś ich potrzebował

1. Włącz placeholder zakładkę na żywoZakładki ustawieńWłącz placeholder zakładkę na żywoPrzećwiczony przykład: zamiana Export (sekcja Account) z nieosiągalnego elementu nawigacji w prawdziwą zakładkę. Jej komponent, AccountSettingsExportTab.ts… — przećwiczony przykład włączenia już zbudowanej zakładki Export, ten sam kształt "UI już istnieje, po prostu spraw, żeby był osiągalny i prawdziwy", co przykład Slacka w ../integrations/01-add-a-new-integration.mdIntegracjeDodaj nową integracjęPrzećwiczony przykład: zamiana Slacka z zablokowanej karty "coming soon" w katalogu w w pełni działającą integrację, dokładnie tak, jak dziś działa Discord….
2. Dodaj zupełnie nową zakładkę ustawieńZakładki ustawieńDodaj zupełnie nową zakładkę ustawieńPrzećwiczony przykład: dodanie zakładki billing do sekcji Account — id zakładki, które jeszcze nigdzie w kodzie nie istnieje, w odróżnieniu od Export z prz… — przećwiczony przykład dodania zakładki billing, która jeszcze w ogóle nie istnieje: typ, wpis w rejestrze, trasa, akcja kontrolera, strona i komponent zakładki.

Architektura w jednym akapicie

SETTINGS_TABS (resources/js/types/Settings.ts) to płaska tablica każdej zakładki — id, path (jej URL), etykieta, ikona, section ('account' albo 'workspace'), opis oraz boolean enabled. Każda włączona zakładka ma odpowiadającą jej trasę w routes/web.php (/settings/<id>, nazwa trasy settings.<id>) wskazującą na własną akcję SettingsController, która renderuje własną stronę pod resources/js/Pages/Settings/ i przekazuje tylko te propy, które ta zakładka renderuje — Settings/Members nigdy nie wysyła ustawień integracji, a Settings/Preferences nigdy listy członków. Samo /settings to już tylko przekierowanie na domyślną zakładkę (settings.preferences). Wyłączone zakładki nie mają trasy w ogóle: pokazują się w nawigacji z plakietką "Soon", a Sidebar.tsx renderuje je jako zwykły div, nie link, więc są nieosiągalne zarówno przez kliknięcie, jak i przez URL. Każda strona jest cienką otoczką: deklaruje swoje propy i renderuje swój komponent zakładki wewnątrz SettingsLayout (resources/js/Components/Organisms/SettingsLayout/SettingsLayout.tsx), który rysuje Sidebar oraz breadcrumb/nagłówek/opis czytane prosto z wpisu zakładki w rejestrze — dlatego każda strona dostaje też prop projects (potrzebuje go Sidebar) i dlatego żadna strona nie powtarza własnego tytułu. Same komponenty zakładek wciąż żyją w Components/Organisms/AccountSettingsContent/ i Components/Organisms/WorkspaceSettingsContent/, po jednym *Tab.tsx na zakładkę, nietknięte przez ten podział — przeniosło się tylko to, co decyduje, który z nich się renderuje: z łańcucha if po stronie klienta do routera. Zakładki Workspace działające w kontekście projektu biorą dodatkowo memberProjects / selectedProjectId dla przełącznika projektów i rozstrzygają wybrany projekt ze stringa zapytania ?project=<id>, który jest jedynym parametrem zapytania, jakiego ustawienia jeszcze używają; przełączenie projektu odwiedza tę samą ścieżkę zakładki z nowym ?project=.