{"id":42856,"date":"2024-04-15T16:00:55","date_gmt":"2024-04-15T20:00:55","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42856"},"modified":"2024-12-10T11:48:41","modified_gmt":"2024-12-10T16:48:41","slug":"nstableview-with-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/04\/15\/nstableview-with-swiftui\/","title":{"rendered":"NSTableView With SwiftUI"},"content":{"rendered":"

Edvinas Byla<\/a> (via Dave Verwer<\/a>):<\/p>\n

The [LazyVGrid<\/code>] user experience isn’t great, but it’s still probably okayish for a version 1.0.0 release. The performance issues are less noticeable with fewer items unless you’re used to high-quality apps. But then there was this one thing that bugged me: the behavior of the context menu.<\/p>

On macOS, right-clicking an item usually selects it and shows the context menu. SwiftUI’s .contextMenu<\/code> shows the menu but doesn’t select or give you any callback for selecting the item. This can be confusing because you don’t know if you’re seeing the menu for the right item.<\/p><\/blockquote>\n

You’re supposed<\/em> to be able to use the contextual menu to interact with a list item without<\/em> changing the selection.<\/p>\n\n

Damn, did [NSTableView<\/code>] feel buttery.<\/p>\n

[…]<\/p>\n

But the main reason for this overhaul wasn’t just the scroll performance. It was also fixing that annoying context menu issue.<\/p>\n

[…]<\/p>\n

On top of all this, I managed to get rid of some extra code for keyboard navigation, clean up the layout mess, and now I can easily adjust and rearrange columns.<\/p>\n

[…]<\/p>\n

The remaining part of this post will go over some challenges and gotchas of replacing LazyVGrid<\/code> with NSTableView<\/code> while still reusing SwiftUI views.<\/p><\/blockquote>\n\n

Lots of good stuff there about using SwiftUI views inside the column headers and table cells.<\/p>\n\n

I don’t want the takeaway to be that SwiftUI is slow and AppKit is fast, or that SwiftUI on macOS isn’t ready for serious apps. In reality, the very complex template editor for this app is almost entirely written in SwiftUI, which handles it impressively well.<\/p><\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

SwiftUI is part of the future, it is not “the” future. It is still unclear how sth basic like a text editor can work with the scalability constraints of SwiftUI. Or a List w\/ more than 1k items.\nEverything becomes easier if you start to acknowledge that SwiftUI is a convenience extension to Cocoa, not a replacement in any way. And miraculously SwiftUI also allows super easy integration w\/ Cocoa, making sure it is no either or 🙂<\/p><\/blockquote>\n\n

Malcolm Hall<\/a>:<\/p>\n

having a constant number of View<\/code>s per row (i.e. no if<\/code>s) is one of the performance secrets recently explained at 16:25 here<\/a>.<\/p>

Another is no sorting\/filtering in body, e.g. it could be bounced through onChange<\/code> and saved in another state<\/p><\/blockquote>\n\n

Previously:<\/p>\n