Open DagAgren opened 1 year ago
Hi @DagAgren thank you for raising this, and it sounds like we may have picked up the wrong end of the stick when adding swiftUI support to rive-ios.
I think one problem
we tried to solve was letting users interact with the riveView properly, and for that we felt we needed to have the ViewModel for users to control what the riveAnimation is doing. This would let you do things like trigger play, or change state machine inputs. Looking at this right now I'm not sure we have a concrete example that really highlights this as a problem however, and I don't completely see why we should not simply be able to do that by interacting with the View directly.
Looking at some of the supplied examples:
Do you have an open source library in mind that lines up with your expectations a little bit better? I think we need to study this a little bit and come up with a structure that meets the expectations of the community.
I guess with any changes we should also take some minimum deployment target issues seriously and see we can make any change compatible with lower versions of iOS
Description
The
RiveView
/RiveViewModel
API is very strange and goes against a lot of expectations of a view-based API.RiveView
is both weak and implicitly unwrapped, which means that the code that owns the view also has to keep track of the view model, otherwise it will be deallocated and the code will crash. This introduces an extra burden which seems entirely unnecessary.