Optimising large data models in SwiftUI - Attempt 1

Today, i had nothing to do, and i therefore, like every normal fellow would do, watched some Apple developer sessions. One of them was about Animations in SwiftUI, and told me about a very interesting feature i didn’t know about: the so called Transactions. As I happen to develop the [[GoXlrKit]], which is.. well a pretty complicated piece of software in terms of data models (i’m pretty sure there’s hundreds of different values to store if only one device is connected!), i wondered if i could use it to narrow down view updates and improve performances!

Well at the time i start writing that i have no idea if this will lead to anything, but i’ll write here my discoveries anyways, to help me think and maybe help anyone that faces the same problems as i do!

⚙️・How the kit works now

For now, the kit works as such:

• It provides a struct GoXLRKit with a shared object
• When you call start-daemon or connect-socket, the struct is populated, aka Status struct, which is decoded from a JSON.
• Afterwards, the kit still watches the websocket for patch calls the goxlr-daemon can send. Though, it also provides the user of the kit an auto-update function, aka when you modify a value in the status struct, a command is directly sent to the daemon to reflect the change on the device selected!

Do you see the problem here?

The Status isn’t self conscious of what device he represents, and most importantly, the auto-update feature can’t know if the user modified the value or if it’s the a patch!

Therefore, loops may occur…

So How did I solved the problem?

Well, by reducing the update scope to one level further… Let me clarify it:

As Swift don’t understand patches updates and just won’t let me use string key values (gnegnegne not type safe), i had to MANUALLY ADD EVERY PATH POSSIBLE (help 🫠🫠), but, instead of updating each value, i update its closest parent, which don’t have any didSet that can be triggered.

The big problem: it updates the whole branch of data, not only the leaf itself… Which leads - i guess ok - to too much view refresh.

🔮・Theory: how i will magically solve everything

What i understood of transactions ok, is that it allows to pass a value in a refresh.

Therefore, if i pass a value telling hEY ITS THE DAEMON NOT THE USER and check if its the user who modified it in the didSet, itll magically allow me to update the values directly and not their parents and ofc be happy and live a happy life and yes

Tho, it may not work because i suspect it to be only in swiftui view bodies. LET’S HOPE OKAY??? 🦔

🥙・Practice: “And then it didnt worked”

I’m going to do a test before on a smaller scale because i don’t wanna modify such codebase without being sure it’ll work lol

opens Xcode and opens “SillyTests.xcodeproj”

reads documentation

Apple: SURE REMEMBER THOUGH TO ACCESS THE TRANSACTION YOU NEED TO USE A VIEW MODIFIER :D

So i lost 2 hours of my life, ihihiihihihih

See you another time for the 2nd episode of “ade loosing her time to stuff that just can’t work cuz she didn’t read the notice” !!! :D