=> Re: "State diffing for undo?" | In: s/programming
For such an approach to work, your whole application needs to work like a pure function: you provide a state (ideally represented as a single object) and your application renders exactly the same user interface. This is a good approach for building user interfaces where changing one variable in the state can affect multiple things on the screen (being able to undo is a bonus, rather than the main aim). This is the approach taken by frameworks such as React. Desktop application frameworks are sadly years behind in terms of state management. In regards to memory management, it will depend on how large is your state, and how much memory you expect to have available, and how many undo steps you want to provide. You don't necessarily have to run a diff algorithm over the whole state: you can just store individual increments for every user action: what data is modified by the action, what was it's previous value, what's the new one.
2024-12-20 ยท 4 weeks ago
=> ๐ undefined [OP] ยท Dec 20 at 08:54:
@alice-sur-le-nuage
for this approach to work, your whole application needs to work like a pure function
I don't think so? Not everything needs to work with the undo system, ui doesn't need to (and it'd be kind of annoying if it would), project loading doesn't need to (it just replaces the whole undo list), moving around doesn't interact with it.
you can just store individual increments for every user action
And that's exactly what I'm trying to avoid doing: instead of writing a function like undo_bleh() for every bleh, I just want to write one function set_undo_point(action_name) and then call that one function every time and have it automate everything. Or a pair of functions, like start/end_undo_block() or something like that.
=> ๐ต random-elephant ยท Dec 20 at 23:13:
I wasn't suggesting you write a function undo_action_X for every action. I was suggesting you don't need to do a full diff of two copies of your state, because every action is in itself a diff applied to your state. Whenever your state change, that's your diff. Value X changed from A to B. You can capture that if all state modifications are done via a function that then also stores the diff.
=> ๐ undefined [OP] ยท Dec 21 at 04:30:
Oh ok I think I get it. So anybody that wants to modify the state, instead of doing it directly, uses an auxillary function, and it does whatever paperwork needs to be done. I've thought about that, and it seems like a pretty good solution if every action is atomic, but the way I'm doing things now is that some actions can be partially conplete if they require user input. Maybe I could convert those to be atomic, but I'm not sure if that would work for all of them.
State diffing for undo? โ Let's say I can identify all the parts of the program that need to interact with undo/redo system, and put all of them into a single contiguous chunk of memory. Then, when someone creates an undo point, I just calculate a diff over that memory, more or less. What I'm interested in is, in your experience, is there a downside to this approach? The program doesn't do any network requests or database connections (and won't, for the forseeable future). Rn I'm using a system...
=> ๐ฌ undefined ยท 7 comments ยท 2024-12-19 ยท 4 weeks ago This content has been proxied by September (ba2dc).Proxy Information
text/gemini; charset=utf-8