mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-28 05:46:58 +02:00
* fix(desktop): open in-app links in a tab instead of the browser (MUL-5208) A link written as an absolute URL on this deployment's own origin (`https://<app-host>/acme/issues/1` — what "copy link" produces, and what agents paste into chat) fell through openLink's external branch to window.open, which Electron routes to shell.openExternal. Clicking an issue link in Desktop chat therefore opened a browser window instead of a tab. openLink now resolves such a URL back to its in-app path and takes the same route a relative path does. Backend-served prefixes (/api/, /_next/) stay external so attachment downloads keep working. Two supporting fixes the change depends on: - The `multica:navigate` event had no listener on web, so in-app paths in content were dead links there; normalizing app URLs would have extended that to every pasted app URL. The web platform layer now answers the event with a router push. - The desktop handler opened every path inside the active workspace's tab group. A cross-workspace link now goes through switchWorkspace, matching what the navigation adapter already does for pushes. Co-authored-by: multica-agent <github@multica.ai> * fix(desktop): scope in-app link conversion to workspace pages, answer it in issue windows Review follow-ups on MUL-5208. 1. The non-page exclusion list only covered /api/ and /_next/, so a same-origin /uploads/* link — local-storage attachments, served by the backend and proxied by web — was routed as an app page, opening a dead tab instead of the file. Replaced the deny-list with the app's own routing model: an absolute URL converts to an in-app path only when its first segment is a slug a workspace could own, which the existing reserved-slug list (shared with the backend) already answers. /api, /uploads, /_next, /favicon.ico and the pre-workspace routes all stay external without a second list to keep in sync. 2. A dedicated issue window derives the same app origin from its adapter but had no multica:navigate listener, so a same-origin link there became a silent no-op (it used to reach the browser). The window now answers the event: another issue opens in place — matching what its adapter push and mention chips already do — and any other app page, which this single-route window cannot host, goes to the browser. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <agent@multica.ai> Co-authored-by: multica-agent <github@multica.ai>
60 lines
2.0 KiB
TypeScript
60 lines
2.0 KiB
TypeScript
"use client";
|
|
|
|
import { createContext, use, useMemo, useTransition } from "react";
|
|
import type { NavigationAdapter } from "./types";
|
|
|
|
const NavigationContext = createContext<NavigationAdapter | null>(null);
|
|
const NavigationPendingContext = createContext<boolean>(false);
|
|
|
|
export function NavigationProvider({
|
|
value,
|
|
children,
|
|
}: {
|
|
value: NavigationAdapter;
|
|
children: React.ReactNode;
|
|
}) {
|
|
// Wrap push/replace in startTransition so any caller of useNavigation()
|
|
// (sidebar AppLink, command palette, modal post-create jumps) gets a
|
|
// React pending signal during route commit. On web this stays true until
|
|
// Next.js commits the new RSC payload; on desktop it flips off quickly
|
|
// because react-router commits synchronously — both are correct.
|
|
const [isPending, startTransition] = useTransition();
|
|
const wrapped = useMemo<NavigationAdapter>(
|
|
() => ({
|
|
...value,
|
|
push: (path: string) => startTransition(() => value.push(path)),
|
|
replace: (path: string) => startTransition(() => value.replace(path)),
|
|
}),
|
|
[value],
|
|
);
|
|
return (
|
|
<NavigationContext.Provider value={wrapped}>
|
|
<NavigationPendingContext.Provider value={isPending}>
|
|
{children}
|
|
</NavigationPendingContext.Provider>
|
|
</NavigationContext.Provider>
|
|
);
|
|
}
|
|
|
|
/**
|
|
* Non-throwing read of the adapter. For components that legitimately render
|
|
* outside a provider — leaf editor UI mounted in isolation, and the tests that
|
|
* exercise it — where the navigation-dependent behaviour has a sane fallback.
|
|
* Anything that must navigate should use `useNavigation()` and keep the throw.
|
|
*/
|
|
export function useOptionalNavigation(): NavigationAdapter | null {
|
|
return use(NavigationContext);
|
|
}
|
|
|
|
export function useNavigation(): NavigationAdapter {
|
|
const ctx = use(NavigationContext);
|
|
if (!ctx)
|
|
throw new Error("useNavigation must be used within NavigationProvider");
|
|
return ctx;
|
|
}
|
|
|
|
/** True while a transition-wrapped push/replace is committing. */
|
|
export function useIsNavigating(): boolean {
|
|
return use(NavigationPendingContext);
|
|
}
|