-
-
Notifications
You must be signed in to change notification settings - Fork 716
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
Robustness of @Query in the SwiftUI demo app #955
Conversation
@steipete I'll try to reproduce your initial issue, so that I can increase my confidence that May I ask you a question? Do you have any hint, a web page I could look at, so that I can start writing tests for those heavily SwiftUI-dependent objects? I admit I'm totally clueless today. |
Sure! I‘ll write up a PR today. Have a bit of experience in that area. |
I've added two UI tests to the target. I'm not 100% happy about the "initialOrdering" and this could be a binding too, but it illustrates the issue - if we late-change the value after view has been displayed, the StateObject is created and (unless my fix) can't be changed anymore. Hit me up on Twitter if you wanna chat, my DMs are open. |
Documentation/DemoApps/GRDBCombineDemo/GRDBCombineDemo.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
Documentation/DemoApps/GRDBCombineDemo/GRDBCombineDemo.xcodeproj/project.pbxproj
Show resolved
Hide resolved
Documentation/DemoApps/GRDBCombineDemo/GRDBCombineDemoUITests/GRDBCombineDemoUITests.swift
Show resolved
Hide resolved
} | ||
|
||
// Given default sorting, Henriette must be on top | ||
XCTAssertEqual(getFirstCell().label, "Craig, 8 points") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test fails here without my query change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much, so much, for this.
Now... I have ruined your efforts in a5ffc52, in order to make the demo app... a demo app, and not a test case. This test is still there, but it no longer checks for your setup, because I have removed the conditions where your @Query
bugfix expresses itself 😅
But I hope I have clearly expressed what we are talking about in c34615c. I quite intend to support your use case in the future, and setup stable tests.
Until then, this does not prevent this pull request from being merged.
This helps readers understand the purpose of those lines, and remove them if they are not interested.
Tests succeed on 14.4, and 14.0 target does not generate any Xcode warning
Leave the AppView(initialOrdering:) initializer, though, so that readers can get some inspiration.
We don't 100% need to address this now, but we 100% need to remember this in the future.
Welcome to the GRDB contributors, @steipete :-) Would you accept an invitation to be able to push to the repository? This would not create any obligation, of course! |
@groue I'd be honored! This is an important part of the app I'm building so I have a vested interest in helping making it better! |
Well, consider yourself onboarded :-) |
When a query is replaced in a view, the
@StateObject
keeps theCore
class alive, and it might still use the previous query. This additional bool tracks this case and ensures the base query is updated.Example where this caused issues:
The query always ran with
userId = 0
(the early state while parent is resolving a suer) despite me updating the binding in init.