Closed Harry-KNIGHT closed 2 months ago
This is a great idea! I'd be curious why these can't be pulled out to separate views entirely, rather than leaving them as methods.
This is a great idea! I'd be curious why these can't be pulled out to separate views entirely, rather than leaving them as methods.
I have used methods that return views because what they do is quite explicit. This limits the number of files and previews to be added in addition to putting fewer lines to the file.
If it's better for the project, I can use structs to keep the homogeneity of the app
Once we move over to @Observable
(when macOS 15 is likely to be released around October), it's more efficient to create smaller views than one big one, even when methods are involved. So, let's plan ahead, just like we're moving towards Swift 6 already ๐
Once we move over to
@Observable
(when macOS 15 is likely to be released around October), it's more efficient to create smaller views than one big one, even when methods are involved. So, let's plan ahead, just like we're moving towards Swift 6 already ๐
Yeah for sure we can take get ahead, the problem with my extension of the view is the coupling of subview with the main view, I think it's better to use separate view entirely.
I'll make the changes soon ๐
This works as expected, if you see some improvements do not hesitate to told me @twostraws
https://github.com/twostraws/ControlRoom/assets/63256761/560978ef-870f-4b68-be89-d1c86aa2e7ae
This is perfect โย thank you!
I found that settings view was really big, so I decided to extract them on method returning
some View
for a better readability.If you have any feedback do not hesitate to reach me or comment the PR.
I think we can have a better naming for methods but I am not much inspired now