🚧 Automatically generate data-binding types from Rive files#377
Draft
m1guelpf wants to merge 1 commit intorive-app:mainfrom
Draft
🚧 Automatically generate data-binding types from Rive files#377m1guelpf wants to merge 1 commit intorive-app:mainfrom
m1guelpf wants to merge 1 commit intorive-app:mainfrom
Conversation
Collaborator
|
This is a super cool idea, and something I think is worth further investigating / adding to the project. Thanks for opening the PR, I'll definitely dig further into your implementation and see if anything can carry over. |
|
@m1guelpf did you look into using the WIP Rive Code Generator https://github.com/rive-app/rive-code-generator-wip/tree/add-data-binding? Rather than making a swift specific one, it could make sense to use this one which already supports a lot of funcanality cross platform and use it as the plugin instead. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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