1️⃣ What happens if we make a change after undoing? Here we've pressed undo twice, then changed a box's color from blue to red.
In this case, we always trim off any pending redos...
...before we push the new patch to the stack.
After a change, the pointer should always be pointing to the last item in the stack. A user should never be able to make a change and then redo!
2️⃣ What happens if we need to "pause" the undo / redo manager? This is often necessary during "continuous" interactions like dragging, resizing, or using a color picker.
Let's say we've just paused our undo / redo manager. Apart from the fact that we're now "paused", we need to keep track of whether any change has occurred while we've been paused.
If we "resume" (aka "unpause") without any change occurring, then we can just go back to where we were.
However, if a change occurs *while* the system is paused, then we need to handle things differently.
First, we need to mark that we've now had a change while paused.
However, we can stop here—we don't have to make a new patch, just keep the previous one around. We can take additional changes too.
Finally, if we "resume" after a change has made, we just push a new patch—exactly as usual.
As far as the system is concerned, its as if we had only made the most recent change!
When we're done, we reset the "changed while paused" flag for next time.
3️⃣ What if you press undo while paused? This is kind of tricky. We always will resume the history on an undo. However, if we do have pending undos, or if we've made a change while paused...
Then we'll resume and then immediately undo.
This way, we can "redo" back to where we were when we pressed undo. ✅
Redo while paused is a little easier—it just triggers a resume. In some apps (@figma ) it does redo the last undo, which I think is weird. IMO once you start making a change, you should be at the end of the stack!
BTW, if you're looking for bugs in your favorite infinite canvas app, this is the place to find them!
For one, it's important that the system triggers some sort of event that cancels the continuous interaction that caused us to pause in the first place, or else we'll end up paused again! (@canva has this one)
Build popular open source library, train
own model on docs + examples (some private?), guarantee that model is updated with every release, sell as integration with user IDEs
Let’s say @threejs went this route. The core product is free (wedge) but AI assisted coding environments sometimes trip over out of date versions or make poor choices based on bad examples in their training data.
The threejs team announced ThreeAssist, an “expert” model fine-tuned on each minor release, fresh docs, etc. Outscores commodity models, produces better results, guaranteed to be true to the given version, etc.
I see a lot of AI uses for the @tldraw SDK. I’d say about 25% of our customers are full on AI apps and another 30% are looking to integrate AI tools into their canvas in the future
No surprise, the most shippable / effective use cases are currently where generated artifacts can augment existing use-cases
Figma has a “wireframe view” that might help here as a fallback, if it means keeping images etc out of memory, though it would be up to the app to switch into that. (And actually I’m not even sure if that would work)
For tldraw we have a limit of shapes per page and pages per project but it’s still theoretically possible to crash it out via memory depending on your browser.
Here's the full interaction, complete with hover indicators.
|
Note that you can interact with text directly either: a) when editing text or b) when the text tool is selected. This will mean you can't create text on top of other text, but I'm guessing this is okay.
In @figma, holding shift while drawing a selection box over items will: 1. select deselected items 2. deselect selected items
Is this the right behavior? Have you ever accidentally selected / deselected items while shift-selecting?
@figma I remember working out some more complicated logic here with a rule like "if any new items are being added to the selection, don't deselect any other items"
Remind me next time to migrate the database before shipping runtime validation 💀
In tldraw’s beta db, there were lots of different versions of our data scattered around, including some from the wild times before we wrote client-side migrations, and some that just included broken data, x = NaN etc.
We’d written validation in order to catch this type of bad data when it came into the app. We didn’t write any recovery from the bad data, the app would just throw as soon as it ran into it.