I’ve been trying to figure out how to make a document data model for an organizer app. Because of the use case, users will need to be able to make hundreds of table super-sections per document, and preferably an unlimited number. At the same time, any part of the table could be edited, and edits will likely be frequent, with new rows, and table sections being added constantly by users.
To simplify things, I want to have the users figure out where they want to store their documents, instead of using a server approach.
It is also expected behavior for this kind of app that multiple people be able to edit the same document at once. Though if that makes things way more complicated, I’m willing to shelf that as a beginner coder.
I’ve been given the advice to use classes for the data model, and then carefully control how they update, to prevent the whole thing from updating at once. Specifically by using a macro like the @observable property, for each new table section an individual user creates, which will apply to the rows, and all the other nested classes. To Lay out what the bindings update, and make sure they only update what’s needed.
Recently I was told that structs update so fast that using them wouldn’t be a problem. But from what I’ve heard I’m skeptical, and the majority of what I’ve heard are that classes are better for this application, so I’m sticking with them for now.
Somehow, as a given user scrolls, and new sections come into view, if their position has changed (meaning their respective class instance within an array in the data model - was marked for needs an update), and they need to update then only. Which would be a matter of taking an output from a lazy scroll view, and then using that to trigger the update, if I’m not mistaken.
Is this a good approach for an app like this to run okay?
Any help would be greatly appreciated!