Performance and side effects
I looked at the LibrarySearchView that has changed to MVC.
What I saw is the Debounce code about SearchQuery.
Using the Debounce of Combine in ViewModel, you can easily handle code than that.
And, if LastSearchTime is used within this View, the View is updated, which can bring up another side effect.
I simply converted the LibraryView to MVVM architecture and reduced meaningless View updates, and tested it,
This made quite a difference.
I checked with the instrument.
Core Animation Commits was a 25% difference (130ms, 170ms,)
And Time Profiler was 20% difference (700ms, 870ms)
In addition to this, it seems that it can be further improved by removing the more business logic of View .
The examples above are just direct examples.
For now, although the number of business logic in View isn't that high (in fact, I still feel View is heavy).
In the future, if we use more requests or conditions on one screen,
The role of View will become increasingly important and the View will become slower.
I want you to think about that many other examples and open-source has what kind of structure and why it was written like that.
SwiftUI has components that are suitable for MVVM such as StateObject, ObservedObject, and Published.
We will be able to make good use of it.
SWIFTUI IS NOT MAGIC
Testability
As everyone knows, unlike MVC, if you only test the input and output of the ViewModel of MVVM, you can test the coverage of all views covered by the ViewModel, which is easy.
Swiftfin is open source and many contributors will merge the code in the future, which will require test automation.
MVVM will make this easier.
Reusability
In addition to the iOS app, I know that the tvOS app is also planned.
I think the business logic required for each view will be the same except a specific screen, and this can be easily written by reusing the ViewModel.
EnvironmentObject
I think it's better not to use EnvironmentObject for business logic like GlobalData.
EnvironmentObject passed after init in View, it is difficult to pass to ViewModel.
It is also difficult to inject when EnvironmentObject is updated.
I think seems better to just use Singleton.
And Currently, pendingAPIRequests is in GlobalData, which will not be released until the app shuts down, causing memory leaks.
It's ridiculous to code separately for release.
This will be solved naturally with MVVM.
Of course, I know that we don't have the resources to change the structure of all views at once.
You can apply it when you create a new screen and slowly change the existing view.
I can help by spending a lot of time on this.
I don't mean to harass you.
I'm just saying that I hope this project goes in a good direction.
Of course, I could be wrong. If so, please provide a rationale for that.
Thanks.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "github-actions[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
