stickies: edit on type, part 2: place cursor at intended position in general

[mimecuvalo]

This is what we discussed this morning! Places the cursor at the intended position. This is doing some magic with opacity to still capture the cursor position and we show it when we're actually editing.

The discussion offline was that select all, being the current behavior implies that editing = 'replace all text' as the default behavior, requiring a third-click to deselect the entirely selected text. The previous 'edit on type' PR that this is stacked on top of start shifting that paradigm to at least choose append to text instead of replace - but! We can still do better. This PR goes the next logical step and places the cursor where the user would probably expect it to go.

(This obviously also ties in with the textfields PR work in general as well.)

Kapture.2024-03-12.at.16.51.46.mp4

Change Type

• sdk — Changes the tldraw SDK
• 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

• bugfix — Bug fix
• feature — New feature
• 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. Add a step-by-step description of how to test your PR here.

• Unit Tests
• End to end tests

Release Notes

• Add a brief release note for your PR here.

[linear]

TLD-2273 Edit on type

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
examples	✅ Ready (Inspect)	Visit Preview	Mar 27, 2024 3:01pm

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
tldraw-docs	⬜️ Ignored (Inspect)	Visit Preview	Mar 27, 2024 3:01pm

[SomeHats]

would this be easier if we already had #3050? if yes, we should maybe work on just getting that landed as it doesn't really touch user facing stuff

also, i would loooove to see some tests for this stuff

[SomeHats]

how come we can't make this a normal controlled component? this current approach has some kind of weird quirks when it comes to multiplayer:

(in the rhs window i've made the textarea semi-transparent green to show the issue)

also, if we're going to have the text area there anyway, do we need to have the<p> as well? could we use the textarea for normal display

[SomeHats]

(ditto for other instances of this pattern)

[mimecuvalo]

that's not a bad idea/point on maybe just using the textarea in general — i like it, it's bold!
we can perhaps maybe lean into the readonly property of textareas, if need be.

i'll give it a go 👍

[mimecuvalo]

I tried just using the textarea and it seems untenable at the moment to remove the elements — it'd require a bigger rethink of things if we went that route.

actually the issue you raised @SomeHats seems to already been in production? it might be a slight variation but it's the same issue at the moment really. so i don't think it's quite a regression for the multiplayer quirk.

[mimecuvalo]

would this be easier if we already had #3050? if yes, we should maybe work on just getting that landed as it doesn't really touch user facing stuff

haha, yes, i had just said the same thing on that PR as the latest comment :) #3050

also, i would loooove to see some tests for this stuff

definitely, the base PR that this is stacked upon has tests added. i didn't add new tests yet to this PR. in general, because there are so many sticky PR's and I don't know which ones we actually want to go forward with, i was waiting for the go ahead and then start adding tests to PRs we want to take past the 'prototype' phase in the Linear sticky notes project.