Formatter registration #1027
Formatter registration #1027
Conversation
|
Thanks for getting this started! |
ghost
assigned
|
Hey, I finally got around to completing this. WDYT @myronmarston @soulcutter ? |
|
I've added a This is part of #944 (for referencing). |
| @@ -51,4 +51,115 @@ | |||
| # @see RSpec::Core::Formatters::BaseTextFormatter | |||
| # @see RSpec::Core::Reporter | |||
| module RSpec::Core::Formatters | |||
|
|
|||
| class Collection | |||
There was a problem hiding this comment.
👍 This is defintitely a good abstraction -- thanks for taking the time to pull it out. It needs some YARD doc comments though -- could be as simple as # @api private (I think this should not be part of the public API).
|
Looking good so far. I have to go get ready for work. I'll try to circle around on the rest of the review later tonight or tomorrow. |
| @@ -45,7 +45,7 @@ Feature: read command line configuration options from files | |||
| """ruby | |||
| describe "formatter set in custom options file" do | |||
| it "sets formatter" do | |||
| expect(RSpec.configuration.formatters.first). | |||
| expect(RSpec.configuration.formatters.to_a.first). | |||
There was a problem hiding this comment.
I can see why the to_a is necessary with your current implementation. However, I think it would be better to include Enumerable in the FormattersCollection class (and define an each to delegate to the wrapped formatters array) -- then no to_a would be needed here and it would preserve the existing enumerable interface of RSpec.configuration.formatters. (I suspect some users may rely on it being an array-like/enumerable object as well).
There was a problem hiding this comment.
Hmm, I didn't really want to end up in another metadata situation where we have to support the full enumerable interface.
There was a problem hiding this comment.
include Enumerable; def each; end is all that's needed to support the full enumerable interface.
That said, I think there's a better solution I just thought of. The majority of the code in Formatters::Collection has nothing to do with the collection of formatters. It has to do with loading formatters. So, what do you think of this?
- Rename it to
Formatters::Loader. - Remove the collection-style methods from it (
empty?,clear,to_a), but retainformatters, which returns the formatters it has loaded. - Keep an instance of
Formatters::LoaderinRSpec.configurationcalledformatter_loader. - Change
RSpec::Core::Configuration#formattersto returnformatter_loader.formatters.
Then RSpec.configuration.formatters will just be an array like it's always been. Your existing Formatters::Collection class gets paired down to a primary responsibility of loading formatters rather than having a secondary responsibility of presenting a collection interface (which is an SRP violation, I think). No APIs break :).
|
I think I've addressed the last few concerns... |
|
I left one comment about your last refactoring -- but looks good otherwise. Merge away when you're ready. |
|
Woohoo! Now onwards with part 2... Expect to see something on that front over the weekend. |
Reworking formatter registration, this moves the configuration of formatters out of
RSpec.configurationinto a new objectRSpec::Formatters::Collectionand now all formatters are registered as listeners according to their interface specification.This is step 1 in my proposed refactoring for formatters. Step 2 is converting all the notifications into value objects (I've made a start on this) so we can then extract common logic about notifications into those rather than having massive base classes.
I still need to work on the LegacyFormatter, but I wanted to get some review on this whilst I do that.