peter
6d8b7be6d8
The demo account — one shared user that whitelisted emails entered from the login page, reset on a schedule — goes end to end (owner decision, E34): demo.py and the reset job, users.is_demo and demo_whitelist (migration 0098 deletes the demo user, its audit rows, the reset job's override and notices, then drops the column and table; the downgrade restores the empty schema), the /auth/demo entry, the admin whitelist and reset, the Demo tab, the banner, the login page's "Try the demo", and every is_demo branch in routes, userscope, scheduler and the UI. require_human only ever refused the demo account, so its 87 uses become current_user (owner-approved); require_write_scope keeps its own check. The login page's "or" divider now shows only beside the Google button: without the demo entry under it, an instance without Google would have said "or" to nothing. A contract test (removedFeatures) fails on the word anywhere in the backend, frontend, e2e or scripts — seen red on a planted hit. Size ceilings tightened for the modules that shrank; admin.py is back under the limit.
44 lines
1.9 KiB
TypeScript
44 lines
1.9 KiB
TypeScript
import { lazyWithPreload } from "../lib/lazyWithPreload";
|
|
import { useMe } from "../lib/useMe";
|
|
import { useFeedFilters, useFeedFiltersActions } from "./feedFiltersContext";
|
|
import { useFeedView, useFeedViewActions } from "./feedViewContext";
|
|
import { useNavigation, useNavigationActions } from "./navigationContext";
|
|
import PersonalViewsModal from "./PersonalViewsModal";
|
|
import { useSavedViews } from "./savedViewsContext";
|
|
|
|
// The two module-registry pages that need per-render wiring (see moduleRegistry), split out of it so
|
|
// that file exports only data and this one only components (Fast Refresh). Their lazy chunks are
|
|
// exported alongside so the registry can attach each chunk's preload to the wrapper that renders it.
|
|
export const Feed = lazyWithPreload(() => import("./Feed"));
|
|
|
|
// The GLOBAL feed page: wires <Feed> to the app-wide feed filters / view / live-search. (The channel
|
|
// page renders <Feed> itself with its own channel-scoped filters, so those two never share state.)
|
|
export function FeedPage() {
|
|
const me = useMe();
|
|
const filters = useFeedFilters();
|
|
const { setFilters } = useFeedFiltersActions();
|
|
const view = useFeedView();
|
|
const { setView } = useFeedViewActions();
|
|
const { ytSearch } = useNavigation();
|
|
const { enterYtSearch, exitYtSearch } = useNavigationActions();
|
|
// The Personal Views modal lives at the feed-page level (always mounted while on the feed, unmounts
|
|
// on navigation) rather than inside the collapsible filter rail — otherwise opening it from the
|
|
// always-visible toolbar view chip while the rail is unpinned would render nothing and latch open.
|
|
const { modalOpen } = useSavedViews();
|
|
return (
|
|
<>
|
|
<Feed
|
|
filters={filters}
|
|
setFilters={setFilters}
|
|
view={view}
|
|
setView={setView}
|
|
canRead={me.can_read}
|
|
ytSearch={ytSearch}
|
|
onYtSearch={enterYtSearch}
|
|
onExitYtSearch={exitYtSearch}
|
|
/>
|
|
{modalOpen && <PersonalViewsModal />}
|
|
</>
|
|
);
|
|
}
|