Feedback Request - 1.0.0.rc

[invisiblefunnel]

Hello users and contributors!

I've made a push to get StripeEvent to a 1.0 release and would appreciate feedback from the community (even a :+1: helps). If you have any suggestions or concerns about the changes please comment so we can discuss them. The readme now covers many of the questions previously raised in issues and elsewhere. Feedback about documentation and ways to make development easier is especially appreciated. Since this is a major release some of the changes break behavior of previous releases, but I've taken care to document them in the changelog. Here is a quick look:

• Internally namespace dispatched events to avoid maintaining a list of all possible event types.
• Subscribe to all event types with StripeEvent.all instead of StripeEvent.subscribe.
• Remove ability to subscribe to many event types with one call to StripeEvent.subscribe.
• Subscribers can be an object that responds to #call.
• Allow subscriber-generated Stripe::StripeError's to bubble up. Thank you to adamonduty for the patch.
• Only depend on stripe and activesupport gems.
• Add rails as a development dependency.
• Allow StripeEvent to be used outside of a Rails application!

One of the goals for this gem is to keep things as simple as possible, basically just routing and dispatch with arbitrary event handling (oh, and authentication.) Would anyone be interested in autoloading a directory (for Rails apps) so subscriber classes can be treated as first class citizens? Say app/events or lib/events? Does app/webhooks make sense? I haven't put much thought into this, but similar gems take this approach.

Also, there's an open issue related to Stripe Connect that I could use some help with. Let me know if you have ideas for a solution. This is not a blocker for 1.0.0 release though.

This pull request refers to the 1.0.0.rc branch, which I hope to finalize and release as 1.0.0 soon. You can use it now:

gem 'stripe_event', github: 'integrallis/stripe_event', branch: '1.0.0.rc'

/cc @mattgoldman @adamonduty

[mattgoldman]

This all looks and sounds great, I don't have time for a while to test - and I'm no longer using this in HookFeed. It became too messy to have two separate implementations so I stuck with my own. Looking forward to keeping an eye on the project and using it in other apps of ours. Thanks for including me :+1:

[invisiblefunnel]

@mattgoldman thanks!

[PeteMichaud]

I came here considering submitting a pull request to allow subscribe to take an arry of events, but I see that you actually removed that functionality. Why is that?

[invisiblefunnel]

@PeteMichaud I couldn't find a clean way to handle subscribers that are not blocks but respond to call and subscribing to a list of event types with one call to subscribe. Here are some failing test cases and the corresponding travis build to demonstrate. Can you describe your use case so I can get a feel for what you're thinking?