-
Notifications
You must be signed in to change notification settings - Fork 0
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
Create Policy type #1
Comments
It looks like our thinking is on similar tracks. Let's compare notes and decide how to move forward.
I like how Polly uses the builder to generate the base policy, then tacks on the concrete policy at the end. I see what you're saying about ease of contribution. I'm still leaning towards starting with the fluent syntax and giving contributors a decent foundation to start with. What do you think? const retryPolicy =
Policy
.handle(error => error implements CustomError) // returns `PolicyBuilder`
.or(error => error implements OtherCustomError) // returns `PolicyBuilder`
.retry(3); // returns `RetryPolicy`
I noticed the same thing. I think we'll have to pass functions like |
@jakehamtexas (due to the async nature that we get to experience with this project because of our relative global locations), I went through and added an untested version of the policy builder with a no-op policy as an example. Let me know what you think! Here's the branch: https://github.com/the-pat/pollyscript/tree/policy-builder |
So looking over the original polly source code, it looks like there's lots of complex C#-specific features that go into its implementation, including extension methods on the
PolicyBuilder
type defined for each type of policy. This looks to be the main thing that drives the fluent api. We might be able to get really close to the fluent api that exists in the original, but for ease of contribution, it might be better to create distinct classes for each policy type and think about how to join them together/create a fluid api that encompasses all of them later on.So my proposal for now is that we use an interface of some kind to unite them and start implementing them separately. Maybe something like the following:
Here's some pseudocode for
RetryPolicy
to continue the example:Then we can create a module as our main export that at least gives us the impression of having a static
Policy
object for initializing policies. I'm hoping this can keep API changes a bit less disruptive but I'm not 100% sure how that might play out.NOTE: I'm completely spitballing the pseudo-implementation for retry policy. This version actually doesn't allow any meaningful usage outside of typescript, due to the use of generics as the driver for giving exception types in the main API, as an additional note.
@the-pat What do you think?
The text was updated successfully, but these errors were encountered: