forked from solidusio/solidus
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
We're deprecating `Spree::Event::Adapters::ActiveSupportNotifications` for a couple of reasons: - It uses the same bus that standard Rails notifications. It forces us to try to normalize the event names given through `Spree::Event.fire` & `Spree::Event.subscribe` to add a `.spree` suffix. However, it's not a complete solution as we're missing subscriptions placed through a regular expression (like `Spree::Event.subscribe /.*/`, which subscribes to all events, including Rails ones). - It relies heavily on global state. Besides not being able to create two different buses (see the previous point), it makes it cumbersome to test events in isolation. This commit introduces a new `Spree::Event::Adapters::Default` adapter, which instances make for independent event buses. As our implementation of the event bus system relies on a global bus for all Solidus events, the idea is to initialize a single instance and configure it as `Spree::Config.events.adapter`. However, we've added a new optional `adapter:` parameter to all relevant methods in `Spree::Event` to inject other buses when testing. E.g.: ```ruby bus = Spree::Event::Adapters::Default.new Spree::Event.subscribe('foo', adapter: bus) { do_something } Spree::Event.fire('foo', adapter: bus) ``` The old adapter is still the default one due to backward compatibility reasons. However, we display a deprecation warning to let users know that they're encouraged to change. There're two critical updates that they need to be aware of (they're also described in the deprecated message): - Event name normalization won't happen anymore. E.g. in order to subscribe to all Solidus events probably users will need to change from `Spree::Event.subscribe /\.spree$/` to `Spree::Event.subscribe /.*/`. There's no way to reliably warn when the `.spree` prefix is used, as users can still decide to use it as far as they're consistent when performing different operations. On top of that, we still can't inspect regular expressions with confidence. - The old adapter allowed to provide a block on `Spree::Event.fire`, like in: ```ruby Spree::Event.fire 'foo', order: order do order.do_something end ``` As this block is entirely unnecessary and it can lead to confusion (is it executed before or after the subscribers?), it's no longer supported in the new adapter. To provide a safer upgrade experience, we raise an `ArgumentError` when the new adapter is being used, and a block is provided. We also show a warning when provided on the legacy adapter. The new `Default` adapter will be made the default one on the next major Solidus release. The old adapter is leaking the abstraction through the returned values (`ActiveSupport::Notifications::Fanout::Subscribers::Timed` instances). In the new adapter, we introduce `Spree::Event::Event` & `Spree::Event::Listener` objects that the adapters need to return. The main `Spree::Event` module will still keep a copy of the subscriptions when the legacy adapter is used. This behavior was introduced to differentiate Solidus events from others, but it can cause inconsistencies if we compare it with the copy on the adapter. As something no longer needed, we're branching to don't perform the logic when the adapter is the new one. We're also adapting the dummy app used in testing to use the future default adapter not to see the deprecation messages. However, the old tests that went through the legacy adapter are still in place.
- Loading branch information
1 parent
7118543
commit e1662c2
Showing
12 changed files
with
879 additions
and
75 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.