Tldraw/apps/dotcom/src/components/ShareMenu.tsx

307 wiersze
9.6 KiB
TypeScript
Czysty Zwykły widok Historia

import * as Popover from '@radix-ui/react-popover'
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
import {
GetReadonlySlugResponseBody,
ROOM_OPEN_MODE,
ROOM_PREFIX,
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
RoomOpenModeToPath,
} from '@tldraw/dotcom-shared'
import React, { useEffect, useState } from 'react'
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
import {
TldrawUiMenuContextProvider,
TldrawUiMenuGroup,
TldrawUiMenuItem,
lns,
unwrapLabel,
useActions,
useContainer,
useTranslation,
} from 'tldraw'
import { useShareMenuIsOpen } from '../hooks/useShareMenuOpen'
import { createQRCodeImageDataString } from '../utils/qrcode'
import { SHARE_PROJECT_ACTION, SHARE_SNAPSHOT_ACTION } from '../utils/sharing'
import { ShareButton } from './ShareButton'
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
const SHARE_CURRENT_STATE = {
OFFLINE: 'offline',
SHARED_READ_WRITE: 'shared-read-write',
SHARED_READ_ONLY: 'shared-read-only',
} as const
type ShareCurrentState = (typeof SHARE_CURRENT_STATE)[keyof typeof SHARE_CURRENT_STATE]
type ShareState = {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
state: ShareCurrentState
qrCodeDataUrl: string
url: string
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
readonlyUrl: string | null
readonlyQrCodeDataUrl: string
}
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
function isSharedReadonlyUrl(pathname: string) {
return (
pathname.startsWith(`/${RoomOpenModeToPath[ROOM_OPEN_MODE.READ_ONLY]}/`) ||
pathname.startsWith(`/${RoomOpenModeToPath[ROOM_OPEN_MODE.READ_ONLY_LEGACY]}/`)
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
)
}
function isSharedReadWriteUrl(pathname: string) {
return pathname.startsWith(`${ROOM_PREFIX}/`)
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
}
function getFreshShareState(): ShareState {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
const isSharedReadWrite = isSharedReadWriteUrl(window.location.pathname)
const isSharedReadOnly = isSharedReadonlyUrl(window.location.pathname)
return {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
state: isSharedReadWrite
? SHARE_CURRENT_STATE.SHARED_READ_WRITE
: isSharedReadOnly
? SHARE_CURRENT_STATE.SHARED_READ_ONLY
: SHARE_CURRENT_STATE.OFFLINE,
url: window.location.href,
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
readonlyUrl: isSharedReadOnly ? window.location.href : null,
qrCodeDataUrl: '',
readonlyQrCodeDataUrl: '',
}
}
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
async function getReadonlyUrl() {
const pathname = window.location.pathname
const isReadOnly = isSharedReadonlyUrl(pathname)
if (isReadOnly) return window.location.href
const segments = pathname.split('/')
const roomId = segments[2]
const result = await fetch(`/api/readonly-slug/${roomId}`)
if (!result.ok) return
const data = (await result.json()) as GetReadonlySlugResponseBody
if (!data.slug) return
segments[1] =
RoomOpenModeToPath[data.isLegacy ? ROOM_OPEN_MODE.READ_ONLY_LEGACY : ROOM_OPEN_MODE.READ_ONLY]
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
segments[2] = data.slug
const newPathname = segments.join('/')
return `${window.location.origin}${newPathname}${window.location.search}`
}
/** @public */
export const ShareMenu = React.memo(function ShareMenu() {
const msg = useTranslation()
const container = useContainer()
const { [SHARE_PROJECT_ACTION]: shareProject, [SHARE_SNAPSHOT_ACTION]: shareSnapshot } =
useActions()
const [shareState, setShareState] = useState(getFreshShareState)
const [isUploading, setIsUploading] = useState(false)
const [isUploadingSnapshot, setIsUploadingSnapshot] = useState(false)
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
const isReadOnlyLink = shareState.state === SHARE_CURRENT_STATE.SHARED_READ_ONLY
const currentShareLinkUrl = isReadOnlyLink ? shareState.readonlyUrl : shareState.url
const currentQrCodeUrl = isReadOnlyLink
? shareState.readonlyQrCodeDataUrl
: shareState.qrCodeDataUrl
const [didCopy, setDidCopy] = useState(false)
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
const [didCopyReadonlyLink, setDidCopyReadonlyLink] = useState(false)
const [didCopySnapshotLink, setDidCopySnapshotLink] = useState(false)
useEffect(() => {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
if (shareState.state === SHARE_CURRENT_STATE.OFFLINE) {
return
}
let cancelled = false
const shareUrl = getShareUrl(window.location.href, false)
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
if (!shareState.qrCodeDataUrl && shareState.state === SHARE_CURRENT_STATE.SHARED_READ_WRITE) {
// Fetch the QR code data URL
createQRCodeImageDataString(shareUrl).then((dataUrl) => {
if (!cancelled) {
setShareState((s) => ({ ...s, shareUrl, qrCodeDataUrl: dataUrl }))
}
})
}
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
getReadonlyUrl().then((readonlyUrl) => {
if (readonlyUrl && !shareState.readonlyQrCodeDataUrl) {
// fetch the readonly QR code data URL
createQRCodeImageDataString(readonlyUrl).then((dataUrl) => {
if (!cancelled) {
setShareState((s) => ({ ...s, readonlyUrl, readonlyQrCodeDataUrl: dataUrl }))
}
})
}
})
const interval = setInterval(() => {
const url = window.location.href
if (shareState.url === url) return
setShareState(getFreshShareState())
}, 300)
return () => {
clearInterval(interval)
cancelled = true
}
}, [shareState])
const [isOpen, onOpenChange] = useShareMenuIsOpen()
return (
<Popover.Root onOpenChange={onOpenChange} open={isOpen}>
<Popover.Trigger dir="ltr" asChild>
<ShareButton title={'share-menu.title'} label={'share-menu.title'} />
</Popover.Trigger>
Bump Yarn to 4.0.2 and add version constraints (#2481) This PR bumps Yarn to 4.0.2, adds version constraints and fixes reported problems. Current constraints (per @ds300): 1. all dependencies (both prod and dev) should have consistent versions across the project 2. only the root `package.json` should have `packageManager` set Removed 54 packages due to deduplication. ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [ ] `major` — Breaking change - [x] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [ ] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version <details> <summary>An example of a report with a bunch of problems</summary> ``` ❯ yarn constraints ➤ Errors prefixed by '⚙' can be fixed by running yarn constraints --fix ├─ @tldraw/monorepo@workspace:. │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/eslint-plugin"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/parser"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint"]; conflicting values are: │ │ ├─ '^8.37.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '8.36.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-config-prettier"]; conflicting values are: │ │ ├─ '^8.8.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.3.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-plugin-react"]; conflicting values are: │ │ ├─ '^7.32.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.28.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["prettier-plugin-organize-imports"]; conflicting values are: │ │ ├─ '^3.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^3.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ @tldraw/docs@workspace:apps/docs │ ├─ Conflict detected in constraint targeting dependencies["@types/ws"]; conflicting values are: │ │ ├─ '^8.5.9' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.5.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint"]; conflicting values are: │ │ ├─ '^8.37.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '8.36.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint-config-next"]; conflicting values are: │ │ ├─ '13.2.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '12.2.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["next"]; conflicting values are: │ │ ├─ '^14.0.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^13.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["prettier-plugin-organize-imports"]; conflicting values are: │ │ ├─ '^3.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^3.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ dotcom@workspace:apps/dotcom │ ├─ Conflict detected in constraint targeting dependencies["@radix-ui/react-popover"]; conflicting values are: │ │ ├─ '1.0.6-rc.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-router-dom"]; conflicting values are: │ │ ├─ '^6.17.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^6.9.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["vite"]; conflicting values are: │ │ ├─ '^5.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.3.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ dotcom-asset-upload@workspace:apps/dotcom-asset-upload │ ├─ Conflict detected in constraint targeting dependencies["itty-router"]; conflicting values are: │ │ ├─ '^2.6.6' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.13' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@types/ws"]; conflicting values are: │ │ ├─ '^8.5.9' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.5.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/bookmark-extractor@workspace:apps/dotcom-bookmark-extractor │ ├─ Conflict detected in constraint targeting dependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/dotcom-worker@workspace:apps/dotcom-worker │ ├─ Conflict detected in constraint targeting dependencies["itty-router"]; conflicting values are: │ │ ├─ '^2.6.6' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.13' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ examples.tldraw.com@workspace:apps/examples │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-router-dom"]; conflicting values are: │ │ ├─ '^6.17.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^6.9.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["vite"]; conflicting values are: │ │ ├─ '^5.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.3.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ huppy@workspace:apps/huppy │ ├─ Conflict detected in constraint targeting dependencies["next"]; conflicting values are: │ │ ├─ '^14.0.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^13.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-config-next"]; conflicting values are: │ │ ├─ '13.2.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '12.2.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/vscode-editor@workspace:apps/vscode/editor │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ tldraw-vscode@workspace:apps/vscode/extension │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/eslint-plugin"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/parser"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ config@workspace:config │ ├─ Conflict detected in constraint targeting dependencies["eslint-config-prettier"]; conflicting values are: │ │ ├─ '^8.8.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.3.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint-plugin-react"]; conflicting values are: │ │ ├─ '^7.32.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.28.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Missing field packageManager; expected null │ ├─ @tldraw/assets@workspace:packages/assets │ └─ ⚙ Missing field packageManager; expected null │ ├─ @tldraw/editor@workspace:packages/editor │ ├─ Conflict detected in constraint targeting devDependencies["@testing-library/jest-dom"]; conflicting values are: │ │ ├─ '^5.16.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.14.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-canvas-mock"]; conflicting values are: │ │ ├─ '^2.5.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.5.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-environment-jsdom"]; conflicting values are: │ │ ├─ '^29.4.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^28.1.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/state@workspace:packages/state │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/store@workspace:packages/store │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tldraw@workspace:packages/tldraw │ ├─ Conflict detected in constraint targeting dependencies["@radix-ui/react-popover"]; conflicting values are: │ │ ├─ '1.0.6-rc.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@testing-library/jest-dom"]; conflicting values are: │ │ ├─ '^5.16.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.14.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-canvas-mock"]; conflicting values are: │ │ ├─ '^2.5.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.5.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-environment-jsdom"]; conflicting values are: │ │ ├─ '^29.4.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^28.1.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tlschema@workspace:packages/tlschema │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tlsync@workspace:packages/tlsync │ ├─ Conflict detected in constraint targeting dependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/utils@workspace:packages/utils │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/validate@workspace:packages/validate │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ └─ @tldraw/scripts@workspace:scripts ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' ``` </details>
2024-01-18 11:09:17 +00:00
<Popover.Portal container={container}>
<Popover.Content
dir="ltr"
className="tlui-menu tlui-share-zone__popover"
align="end"
side="bottom"
sideOffset={2}
alignOffset={4}
>
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
<TldrawUiMenuContextProvider type="panel" sourceId="share-menu">
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
{shareState.state === SHARE_CURRENT_STATE.SHARED_READ_WRITE ||
shareState.state === SHARE_CURRENT_STATE.SHARED_READ_ONLY ? (
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
<>
<button
className="tlui-share-zone__qr-code"
style={{ backgroundImage: `url(${currentQrCodeUrl})` }}
title={msg(
isReadOnlyLink ? 'share-menu.copy-readonly-link' : 'share-menu.copy-link'
)}
onClick={() => {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
if (!currentShareLinkUrl) return
setDidCopy(true)
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
setTimeout(() => setDidCopy(false), 1000)
navigator.clipboard.writeText(currentShareLinkUrl)
}}
/>
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
<TldrawUiMenuGroup id="copy">
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
{shareState.state === SHARE_CURRENT_STATE.SHARED_READ_WRITE && (
<TldrawUiMenuItem
id="copy-to-clipboard"
readonlyOk
icon={didCopy ? 'clipboard-copied' : 'clipboard-copy'}
label="share-menu.copy-link"
onSelect={() => {
if (!shareState.url) return
setDidCopy(true)
setTimeout(() => setDidCopy(false), 750)
navigator.clipboard.writeText(shareState.url)
}}
/>
)}
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
<TldrawUiMenuItem
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
id="copy-readonly-to-clipboard"
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
readonlyOk
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
icon={didCopyReadonlyLink ? 'clipboard-copied' : 'clipboard-copy'}
label="share-menu.copy-readonly-link"
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
onSelect={() => {
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
if (!shareState.readonlyUrl) return
setDidCopyReadonlyLink(true)
setTimeout(() => setDidCopyReadonlyLink(false), 750)
navigator.clipboard.writeText(shareState.readonlyUrl)
}}
/>
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
<p className="tlui-menu__group tlui-share-zone__details">
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
{msg('share-menu.copy-readonly-link-note')}
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
</p>
</TldrawUiMenuGroup>
<TldrawUiMenuGroup id="snapshot">
<TldrawUiMenuItem
{...shareSnapshot}
icon={didCopySnapshotLink ? 'clipboard-copied' : 'clipboard-copy'}
onSelect={async () => {
setIsUploadingSnapshot(true)
await shareSnapshot.onSelect('share-menu')
setIsUploadingSnapshot(false)
setDidCopySnapshotLink(true)
setTimeout(() => setDidCopySnapshotLink(false), 1000)
}}
spinner={isUploadingSnapshot}
/>
<p className="tlui-menu__group tlui-share-zone__details">
{msg('share-menu.snapshot-link-note')}
</p>
</TldrawUiMenuGroup>
</>
) : (
<>
<TldrawUiMenuGroup id="share">
<TldrawUiMenuItem
id="share-project"
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
readonlyOk
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
label="share-menu.share-project"
icon="share-1"
onSelect={async () => {
if (isUploading) return
setIsUploading(true)
await shareProject.onSelect('menu')
setIsUploading(false)
}}
spinner={isUploading}
/>
<p className="tlui-menu__group tlui-share-zone__details">
{msg(
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
shareState.state === SHARE_CURRENT_STATE.OFFLINE
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
? 'share-menu.offline-note'
: isReadOnlyLink
? 'share-menu.copy-readonly-link-note'
: 'share-menu.copy-link-note'
)}
</p>
</TldrawUiMenuGroup>
<TldrawUiMenuGroup id="copy-snapshot-link">
<TldrawUiMenuItem
id="copy-snapshot-link"
Readonly / room creation omnibus (#3192) Reworks how the readonly urls work. Till now we just used a simple function that would scramble the slugs. Now we use a proper key value mapping between regular and readonly slugs: - We use two KV stores. One is for going from a slug to a readonly slug and the other one for going the other way around. They are populated at the same time. - We separate preview KV stores (dev, preview, staging) from production one. I've already created these on Cloudflare. [My understanding is ](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that ids [can be public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4) since we can only access KV from our worker. Happy to move them to env variables though. - [x] Disable creating new rooms when tldraw is embedded inside iframes on other websites (we check the referrer and if it's not the same as the iframe's origin we don't allow it) - [x] Fork a project when inside an iframe now opens the forked project on tldraw.com and not inside iframe. - [x] We allow embeding of iframes, but we now track the where they are used via the referrer. We send this to Vercel analytics. - [x] Improved UX of the share menu to make it less confusing. Toggle is gone. - [x] `/new` and `/r` routes not redirect to `/`. - [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms still live on `/v`. - [x] Brought back `dotcom-shared` project to share code between BE and FE. Mostly types. - [x] Prevent creating of rooms by entering `/r/non-existing-slug`. - [x] Handle getting a readonly slug for old rooms. Added a comment about it [here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18). - [x] We no longer expose editor on the window object for readonly rooms. Prevents the users disabling readonly rooms manually. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Make sure old readonly rooms still work. 2. Creating a readonly link from an existing room should still use `/v` path. 3. Newly created rooms should use `/ro` path for readonly rooms. Make sure these work as well. 4. `/r` room was disabled and redirects to `/` 5. `/new` should still work when not inside iframes. - [x] Unit Tests - [ ] End to end tests ### Release Notes 1. This adds new functionality for readonly rooms: - We have a new route `/ro` for newly created readonly rooms. These rooms no longer use the scrambling logic to create readonly slugs. Instead we now use KV storage from cloudflare to track the mapping for slugs -> readonly slug and readonly slug -> slug. - The old route `/v` is preserved, so that the old room still work as they did before. - For old rooms we will keep on generating the old readonly slugs, but for new rooms we'll start using the new logic. 2. We no longer prevent embedding of tldraw inside iframes. 3. We do prevent generating new rooms from inside the iframes though. `/r`, `/new`, `/r/non-existing-id` should not allow creation of new rooms inside iframes. Only `/new` still works when not inside iframes. 4. Forking a project from inside an iframe now opens it on tldraw.com 5. Slight copy change on the sharing menu. We no longer have a toggle between readonly and non-readonly links. 6. `editor` and `app` are no longer exposed on the window object for readonly rooms. Prevents users from using the `updateInstanceState` to escape readonly rooms. --------- Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
readonlyOk
Composable custom UI (#2796) This PR refactors our menu systems and provides an interface to hide or replace individual user interface elements. # Background Previously, we've had two types of overrides: - "schema" overrides that would allow insertion or replacement of items in the different menus - "component" overrides that would replace components in the editor's user interface This PR is an attempt to unify the two and to provide for additional cases where the "schema-based" user interface had begun to break down. # Approach This PR makes no attempt to change the `actions` or `tools` overrides—the current system seems to be correct for those because they are not reactive. The challenge with the other ui schemas is that they _are_ reactive, and thus the overrides both need to a) be fed in from outside of the editor as props, and b) react to changes from the editor, which is an impossible situation. The new approach is to use React to declare menu items. (Surprise!) ```tsx function CustomHelpMenuContent() { return ( <> <DefaultHelpMenuContent /> <TldrawUiMenuGroup id="custom stuff"> <TldrawUiMenuItem id="about" label="Like my posts" icon="external-link" readonlyOk onSelect={() => { window.open('https://x.com/tldraw', '_blank') }} /> </TldrawUiMenuGroup> </> ) } const components: TLComponents = { HelpMenuContent: CustomHelpMenuContent, } export default function CustomHelpMenuContentExample() { return ( <div className="tldraw__editor"> <Tldraw components={components} /> </div> ) } ``` We use a `components` prop with the combined editor and ui components. - [ ] Create a "layout" component? - [ ] Make UI components more isolated? If possible, they shouldn't depend on styles outside of themselves, so that they can be used in other layouts. Maybe we wait on this because I'm feeling a slippery slope toward presumptions about configurability. - [ ] OTOH maybe we go hard and consider these things as separate components, even packages, with their own interfaces for customizability / configurability, just go all the way with it, and see what that looks like. # Pros Top line: you can customize tldraw's user interface in a MUCH more granular / powerful way than before. It solves a case where menu items could not be made stateful from outside of the editor context, and provides the option to do things in the menus that we couldn't allow previously with the "schema-based" approach. It also may (who knows) be more performant because we can locate the state inside of the components for individual buttons and groups, instead of all at the top level above the "schema". Because items / groups decide their own state, we don't have to have big checks on how many items are selected, or whether we have a flippable state. Items and groups themselves are allowed to re-build as part of the regular React lifecycle. Menus aren't constantly being rebuilt, if that were ever an issue. Menu items can be shared between different menu types. We'll are sometimes able to re-use items between, for example, the menu and the context menu and the actions menu. Our overrides no longer mutate anything, so there's less weird searching and finding. # Cons This approach can make customization menu contents significantly more complex, as an end user would need to re-declare most of a menu in order to make any change to it. Luckily a user can add things to the top or bottom of the context menu fairly easily. (And who knows, folks may actually want to do deep customization, and this allows for it.) It's more code. We are shipping more react components, basically one for each menu item / group. Currently this PR does not export the subcomponents, i.e. menu items. If we do want to export these, then heaven help us, it's going to be a _lot_ of exports. # Progress - [x] Context menu - [x] Main menu - [x] Zoom menu - [x] Help menu - [x] Actions menu - [x] Keyboard shortcuts menu - [x] Quick actions in main menu? (new) - [x] Helper buttons? (new) - [x] Debug Menu And potentially - [x] Toolbar - [x] Style menu - [ ] Share zone - [x] Navigation zone - [ ] Other zones ### Change Type - [x] `major` — Breaking change ### Test Plan 1. use the context menu 2. use the custom context menu example 3. use cursor chat in the context menu - [x] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
icon={didCopySnapshotLink ? 'clipboard-copied' : 'clipboard-copy'}
label={unwrapLabel(shareSnapshot.label)}
onSelect={async () => {
setIsUploadingSnapshot(true)
await shareSnapshot.onSelect('share-menu')
setIsUploadingSnapshot(false)
setDidCopySnapshotLink(true)
setTimeout(() => setDidCopySnapshotLink(false), 1000)
}}
spinner={isUploadingSnapshot}
/>
<p className="tlui-menu__group tlui-share-zone__details">
{msg('share-menu.snapshot-link-note')}
</p>
</TldrawUiMenuGroup>
</>
)}
</TldrawUiMenuContextProvider>
</Popover.Content>
</Popover.Portal>
</Popover.Root>
)
})
Allow users to set document name and use it for exporting / saving (#2685) Adds the ability to change document names in the top center part of the UI. This mostly brings back the functionality we already had in the past. This is basically a port of what @SomeHats did a while back. I changed the dropdown options and removed some of the things (we are not dealing with network requests directly so some of that logic did not apply any longer). We did have autosave back then, not sure if we want to bring that back? Changes the `exportAs` api, thus braking. ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [x] `major` — Breaking change - [ ] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [ ] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Top center should now show a new UI element. It has a dropdown with a few actions. 2. Double clicking the name should also start editing it. 3. The name should also be respected when exporting things. Not if you select some shapes or a frame. In that case we still use the old names. But if you don't have anything selected and then export / save a project it should have the document name. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Allow users to name their documents.
2024-02-19 12:30:26 +00:00
export function getShareUrl(url: string, readonly: boolean) {
if (!readonly) {
return url
}
const segs = url.split('/')
// Change the r for a v
segs[segs.length - 2] = 'v'
// A url might be something like https://www.tldraw.com/r/123?pageId=myPageId
// we want it instead to be https://www.tldraw.com/v/312?pageId=myPageId, ie
// the scrambled room id but not scrambled query params
const [roomId, params] = segs[segs.length - 1].split('?')
segs[segs.length - 1] = lns(roomId)
if (params) segs[segs.length - 1] += '?' + params
return segs.join('/')
}