New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AnyView implementation for SwiftUI Presenter #57
Comments
EOD: We created the spike branch for the millionth time here: swiftUI-again-spike This approach started with just testing ViewInspector to determine how to leverage that to test our views. It then implemented the code from previous spikes with Finally, we started a little investigation into ViewBuilder.buildIf as that looks like it could be something for a solution without AnyView. https://developer.apple.com/documentation/swiftui/viewbuilder/buildif(_:) |
EOD: Today we reimplemented complete and abandon, and we confirmed that animations are supported. Up next, we will implement backup functionality and assess the viability of ViewBuilder.buildIf as a replacement for AnyView |
Second EOD: Animations needed more work to actually animate abandoning and proceeding. I also copy pasted in backup so we could see what happens when you animate and when you don't when moving back and forward. Still need to investigate ways of not using AnyView and there is an interesting issue around a workflow being launch multiple times. |
EOD: We realized we needed to take a step back and consider the whole API before continuing forward with this implementation. Because that decision is so big, we started a discussion: #61 . |
EOD: Today we looked further into the possibilities for the Swift UI DSL. Tomorrow, we will continue this in pairs. |
EOD: We continued to look into options and reviewed some of the older concepts that the team had been trying. Updated the discussion with answers for each of the proposals with code snippets and pros/cons or comments. There is a lot for an EOD, so dropping links to the analysis for each option that has been reviewed. SwiftUIResponder2 |
EOD: We added a playground to test out compiling of the API to the spike branch on Friday. Today we continued that research and discovered that with a small modification, we would support what seems to be all ViewModifiers including custom ones. We, however, do not yet have compile time safety on the types passed into |
EOD: Work is continuing in the spike branch to continue validating the API will work. Modifications are being made and those changes will be reported back to the discussion as we narrow in on an implementation. |
EOD: Everything is looking very promising and the team needs to sync up to ensure we have consensus on moving forward with the API. At that point we will update the discussion with an Answer on what we are moving forward with and what that API will look like. There is a key change we are making to the API which will enable the ability to apply transition modifiers to your FlowRepresentable views and have them respect that animation. Some type safety has been regained but we have lost some in the |
ACTUAL EOD: I've made some key changes that are in line with what I heard the team wanted. First off the only thing that needs ALSO @wiemerm was right, |
EOD: We have decided on our API direction as noted in this answer and will begin the process of implementing it. We will retain our spike branch as reference as we continue to develop this. Expect updates to move to a referenced PR before long (there are still some updates to be done before we create a PR). |
REAL EOD: It's like @Richard-Gist Doesn't know what the end of the day is. I've created a draft PR for folks to follow (on Richard's suggestion, because that way everybody but me can approve it). Just for kicks I added one test (marked with a warning) that I am very confident fails/passes for the right reasons. I added a bunch more that likely pass/fail for the right reasons but may need a little tweaking. I added warnings and comments everywhere so that the team can succeed asynchronously. I did not test all the things, but I tested a good number of things (for example For additional information and a frankly amazing SwiftUI testing framework check out ViewInspector |
EOD: With SwiftUI implementation merged into trunk and released as Beta, we are now focusing on Documentation and Example App. |
[x] Testing
[x] Implementation
[x] Docs
[x] Example app
LIMIT: We do not need Modals or Navigation. Just view swapping.
This card is not getting merged into trunk until we have completed our investigation into NOT using AnyView (the card: Don't use AnyView for SwiftUI Presenter).
The text was updated successfully, but these errors were encountered: