🚧 Automatically generate data-binding types from Rive files #377
+397
−14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Warning
This PR is not currently functional, and is more intended as a showcase of what's possible than a real feature that might get merged any time soon.
What does this do?
This PR adds a SwiftPM/Xcode plugin which, when enabled, will try to parse all
.rivfiles on the project's directory and auto-generate types to work with them.This is achieved by adding a
rive-codegencli tool (which takes care of generating the types), and a SwiftPM/Xcode "build tool", which automatically runs the plugin at build time and makes the generated types available to your project. The generated file is not written to the filesystem (preventing outdated types), but can be inspected in Xcode.What DX could this enable?
(This is obviously subjective, and represents my personal opinion, which is why it's collapsed)
What is currently missing?
Currently, the
rive-codegencli builds and works as expected when it's ran independently (viaswift buildor therive-codegentarget in Xcode. However, when running the plugin, the CLI is not able to find theRiveRuntimeframework, and fails to run.Error logs
The reason for this seems to be that the CLI looks for
RiveRuntime.xcframeworkinsidePackageFrameworks, while the framework is outside.I haven't been able to find a way to fix this (but like, there has to be, right?) and haven't been able to find any other repos on GitHub search using a CLI-based plugin that requires an
xcframework.The lazy way around this would be to distribute the build
rive-codegenbinary as abinaryTarget, which seems relatively common (widely used for SwiftLin or SwiftGen) so shouldn't run into the same issue.Naming for Enums (and ViewModels)
There seems to be no way to get the Rive name for an Enum. The name seems to be somewhere inside the
.rivfile (strings file.riv | grep EnumNameworks), but I can't find any APIs for reading it. Exposing it as part ofRiveDataBindingViewModel.Instance.EnumPropertywould work best.Same for ViewModels. Those I can at least get a name for by building a dictionary via
riveFile.viewModel(at:), but exposing the name atRiveDataBindingViewModel.Instancewould make life easier.The rest of the glue code
The code in this PR currently just generates structs and enums for data binding for each artboard. Once the above issues are fixed, you'd ideally also want to generate
RiveViewModelclasses, andget/setaccessors on those to manipulate the properties directly. And, if you wanna be fancy, hook up listeners to theObservableframework, to listen for changes in a more intuitive way.I don't expect any of these to be hard at all once the above issues (specifically the build issue) are fixed.
Other fixes
Package@swift-5.9.swiftto maintain Swift 5.9 compatibilityRiveRuntimesource from./Sourceto./Sources/RiveFrameworkTODOs in code