-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
Allow arbitrary non-Siesta promises in request chains #152
Comments
Manage to solve it I think. Just running So basically just letting the request fail then reload stuff when I have the new token. |
Yes, that’s the way to do it if you want resource observers to first see “no auth” failure, then success:
The request decorator is what you do if you want the whole auth reattempt to look like a single request from the outside, so that observers / requesters to just wait until the auth attempt succeeds or fails:
In your example code, where do |
@pcantrell Thanks for your answer and I'm with you , guess it doesn't "matter" that much in my case. But it would be more performant to do the "second" flow. But not sure how to solve that. Yes.
So So the problems starts with Would you have any suggestions how to integrate that with the request decorator ? :) |
Yup, then there is an issue to resolve here. Siesta uses That’s lovely if you’re staying entirely inside the world of Siesta requests, but it gives you no simple way to wait on something else (such as a PromiseKit promise) mid-chain. It’s possible to do it by writing your own |
Any update on this, Paul? 🙂 |
You can find mostly working implementation in progress on the There’s no documentation yet, not even API docs, so it may be a bumpy ride. Here are some quick tips to get started:
If you get a chance to give it a try, please let me know! I would love to get feedback before publishing the new API. |
@pcantrell, I noticed this feature in the release notes, and I'm really glad its there! I am trying to add a custom Also, my real implementation that uses this feature will open a web view and get the user to login so I can get the credentials I need for Siesta's headers. I assume that this non NSURL based request will work in a request chain? |
This means that the Synchronously calling Resource.prepareRequest(using: DummyRequestDelegate()).start()
class DummyRequestDelegate: RequestDelegate
{
func startUnderlyingOperation(passingResponseTo completionHandler: RequestCompletionHandler)
{
let dummyResponse =
ResponseInfo(
response: .success(Entity<Any>(
content: "custom",
contentType: "text/whatever")))
print(completionHandler.willIgnore(dummyResponse)) // prints false
completionHandler.broadcastResponse(dummyResponse)
print(completionHandler.willIgnore(dummyResponse)) // prints true
}
func cancelUnderlyingOperation()
{ }
func repeated() -> RequestDelegate
{ fatalError("unsupported") }
let requestDescription = "DummyRequestDelegate"
}
Yes, that should work fine, and is a good use of the feature. A more standard approach would be to accept the error and prompt a retry — but if you want parts of the UI to just sit there waiting until the user logs in, then what you describe is exactly the way to do it. |
Hello,
I'm trying to implement this example: http://bustoutsolutions.github.io/siesta/guide/configuration/#decorating-requests-via-configuration
But getting into trouble , cause I'm getting the new token async, so don't see how I should make that code work. This is how far I have gotten:
So this code does kinda nothing. I have looked at the closest issues also but don't really see an solution to my problem.
Anyway that could guide me in the right direction ? :)
Just a FYI: I'm kinda new to Swift/iOS dev, so maybe I'm missing something obvious.
The text was updated successfully, but these errors were encountered: