Improve Spree::Stock::Estimator customizability

[spaghetticode]

Currently, the criteria for selecting the appropriate shipping rates is basically a single line block included in the #shipping_rates method, which is is almost 10 lines long:

      def shipping_rates(package, frontend_only = true)
        raise ShipmentRequired if package.shipment.nil?
        raise OrderRequired if package.shipment.order.nil?

        rates = calculate_shipping_rates(package)
        rates.select! { |rate| rate.shipping_method.available_to_users? } if frontend_only # <--- this line
        choose_default_shipping_rate(rates)
        Spree::Config.shipping_rate_sorter_class.new(rates).sort
      end

so, if a store needs to customize only these criteria, at the moment the most reasonable solution is to patch the entire method or use a local subclass of Spree::Stock::Estimator that includes that method patch.

I think that extracting these criteria to a separate method, or possibly even better to a specific class with a preference would improve the extendability of the codebase. The class could live inside the Spree::Stock::Estimator namespace, something like Spree::Stock::Estimator::RateSelector, so that we don't add too much indirection by adding a dedicated file for it, especially given we're going to have just a single line of logic with the standard behavior.

On the other hand, a full revision of the whole class/process may show better solutions for improving extendability, but it would surely take more time and effort, considering also that it would probably require deprecating the existing code.

[jarednorman]

Yeah, I definitely think this part of the code warrants a redesign to make the components reasonably pluggable and open up the opportunity to rewrite some chunks of this while maintaining full support for the legacy behaviour. Definitely a big project to really do anything with this part of the code, the way it is.

[waiting-for-dev]

It makes sense, @spaghetticode. We could set that block as a Spree::Stock::Estimator constant, so we don't even need to create a custom class while still making it configurable (anything that responds to #call; users could use another proc or a full-fledged class).

[mamhoff]

FWIW we have a custom Rate Selector implemented.