No commit activity in last 3 years
No release in over 3 years
Extra helpers for BloodContracts::Core
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 2.0
>= 0
~> 10.0
~> 3.0
~> 0.49

Runtime

 Project Readme

Build Status Code Climate

BloodContracts::Ext

Refinement types are implemented in BloodContracts::Core, but in production we found several patterns to use with types. Let me share them with you.

Welcome, extended refinement types.

All those extensions are listed below, stay tuned.

Installation

Add this line to your application's Gemfile:

gem 'blood_contracts-ext'

And then execute:

$ bundle

Or install it yourself as:

$ gem install blood_contracts-ext

Usage

This gems consists mostly of Concerns and Refined classes that extends the powers of refinement types.

BC::ExceptionHandling

First of all sometimes it is great to replace the usual exception handling with refinement types, because inside type you have much more context then just the exception and its backtrace.

For that scenario you only need to prepend your BC::Refined class with BC::ExceptionHandling and when the StandardError happen inside your matching pipeline it will turn into BC::ExceptionCaught type (which is of course just another ancestor of BC::ContractFailure).

class JsonType < BC::Refined
  prepend BC::ExceptionHandling

  def match
    @context[:json_type_input] = value
    @context[:parsed_json] = JSON.parse(@context[:json_type_input])
    self
  end
end

match = JsonType.match(Class.new) # => #<BC::ExceptionCaught ...>
match.exception # => TypeError
match.context # => { :json_type_input => #<Class>, :exception => TypeError }

Now you have access to both the exception (the #exception reader) and matching context (the #context reader).

BC::DefinableError

Imagine you have an error message you want to return for your validation, but you have to worry about the translations. With BC::DefineableError you don't have to. You just extend your class with BC::DefinableError.new(:translations_root) and you have simple DSL to define translatable and composable errors.

class EmailType < ::BC::Refined
  extend BC::DefineableError.new(:type_validations)
  REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  INVALID_EMAIL = define_error(:invalid_email)

  def match
    context[:email_input] = value.to_s
    return failure(INVALID_EMAIL) if context[:email_input] !~ REGEX
    context[:email] = context[:email_input]

    self
  end
end

match = Email.match("not-an-email") # => #<BC::ContractFailure ...>

# en.yml should include translation for en.type_validations.email_type.invalid_email
# e.g. "Given value is not a valid email address"
match.errors.reduce(:merge).messages # => ["Given value is not a valid email address"]

Of course you may prefer a shortcut here, when you use ::BC::Ext::Refined as a base class your failures are wrapped into BC::PolicyFailure with even better Tram::Policy integration.

class EmailType < ::BC::Ext::Refined
  extend BC::DefineableError.new(:type_validations)
  REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  INVALID_EMAIL = define_error(:invalid_email)

  def match
    context[:email_input] = value.to_s
    return failure(INVALID_EMAIL) if context[:email_input] !~ REGEX
    context[:email] = context[:email_input]

    self
  end
end

match = Email.match("not-an-email") # => #<BC::PolicyFailure ...>

# en.yml should include translation for en.type_validations.email_type.invalid_email
# e.g. "Given value is not a valid email address"
match.messages # => ["Given value is not a valid email address"]

As simple as that! Do you still remember our "patter matching" usage? It's working anyways:

case match = Email.match("not-an-email")
when Email
  # Validation succeeded
  # Use #unpack or #context to extract the data
  match # => #<Email ...>
when BC::PolicyFailure
  # You have access here to #message and #policy_errors methods
  match # => #<BC::PolicyFailure ...>
when BC::ContractFailure
  # No fancy Tram::Policy integration but anyway #unpack or #messages at your serivce
  match # => #<BC::ContractFailure>
else raise # Remember to be exhaustive
end

BC::MapValue

Another usual scenario is to transform the value of your type but when logic is too complex you prefer to use another class for that. For that case you may try BC::MapValue type which will be regular part of your pipeline.

Let's imagine you want to change transform your ActiveModel object to some json through the class. Not a big deal, look at the example:

module UPS
  class JsonRequests::Rates
    def self.call(origin_country:, destination_country:, weight:)
      JSON.pretty_generate(
        "RateRequest": {
          "Shipment": {
            "ShipFrom": origin_country,
            "ShipTo":   destination_country,
            "Service": { "Code": "65" },
            "Package": {
              "PackagingType": { "Code": "00" },
              "PackageWeight": {
                "UnitOfMeasurement": { "Code": "KGS" },
                "Weight": weight.to_s,
              }
            }
          }
        }
      )
    end
  end

  class ParcelType < BC::Refined
    prepend BC::ExceptionHandling

    def match
      parcel = value
      context.merge!(
        origin_country: parcel.origin_address.country,
        destination_country: parcel.destination_address.country,
        weight: parcel.weight
      )
    end

    def mapped
      @context.slice(:origin_country, :destination_country, :weight)
    end
  end

  RatesRequestType = ParcelType.and_then(BC::MapValue.with(JsonRequests::Rates))
end

match = UPS::RatesRequestType.match(Parcel.find(123)) # => #<BC::MapValue ...>
match.unpack # =>
# => {
#      "RateRequest": {
#        "Shipment": {
#          "ShipFrom": "LV",
#          "ShipTo":   "US",
#          "Service": { "Code": "65" },
#          "Package": {
#            "PackagingType": { "Code": "00" },
#            "PackageWeight": {
#              "UnitOfMeasurement": { "Code": "KGS" },
#              "Weight": "1.15"
#            }
#          }
#        }
#      }
#    }

UPS::RatesRequestType.match("not-a-parcel")   # => #<BC::ExceptionCaught ...>

BC::Extractable

You may notice that in huge number of cases your type is a coercer from an arbitrary object. So you may look at the Refinement type as "extractor". That only means you have to use several methods to parse the context from the value.

That best example is attempt to use single type for different types of input

class AddressType < BC::Refined
  extend BC::Extractable
  prepend BC::ExceptionHandling

  extract :city
  extract :country_code, method_name: :country
  extract :street

  def city
    return value.city if value.respond_to?(:city)
    value.to_h
         .transform_keys(&:to_s)
         .values_at("city", "City")
         .compact
         .first
  end

  def country
    return value.country if value.respond_to?(:country)
    value.to_h
         .transform_keys(&:to_s)
         .values_at("country", "country_code", "CountryCode")
         .compact
         .first
  end

  def street
    return value.street if value.respond_to?(:street)
    value.to_h
         .transform_keys(&:to_s)
         .values_at("street", "street_line", "StreetLine")
         .compact
         .first
  end
end

Address = Struct.new(:country, :city, :street)

That's just a definition, but let's take a look how it will behave in runtime:

address_model = Address.new("RU", "Moscow", "Novoslobodskaya street")
AddressType.match(address_model) # => #<AddressType ...>

json_address = '{"CountryCode": "RU", "City": "Moscow", "StreetLine": "ul. Novoslobodskaya"}'
AddressType.match(JSON.parse(json_address)) # => #<AddressType ...>

AddressType.match("anything_else") # => #<BC::ExceptionCaught ...>

BC::PolicyFailure

There is a great abstraction for validation called Policy object. I like the Tram::Policy implementation, so now you're able to delegate validation logic to an external Policy object.

But, sometimes you may prefer to use only Tram::Policy::Errors abstraction for the matching errors. For that case, you just need to use self.failure_klass = BC::PolicyFailure in your type.

class Phone < ::BC::Refined
  self.failure_klass = BC::PolicyFailure
  REGEX = /\A(\+7|8)(9|8)\d{9}\z/i

  def match
    context[:phone_input] = value.to_s
    clean_phone = context[:phone_input].gsub(/[\s\(\)-]/, "")

    # translation key is: en.tram-policy.phone.invalid_phone
    return failure(:invalid_phone) if clean_phone !~ REGEX
    context[:clean_phone] = clean_phone

    self
  end
end

Not a big difference? But, now all your failure calls generate Tram::Policy::Error, which easily translates using I18n.

BC::Ext::Refined

You just saw several fancy tools around the BC::Refined. So, why don't we have everything inside that class? Because we try to keep things simple and transparent. But.

If you prefer to have all that tooling in your types - "easy-peasy", use brand new BC::Ext::Refined.

BC::Ext::Refined - is just extended version of BC::Refined (extended by concerns mentioned above).

BC::ExpectedError

Finally, when you validate responses from API, sometimes "error" is just one of expected scenarios. That is why you may prefer special base class for those matching cases.

Welcome - BC::ExpectedError, it's just ancestor of BC::Ext::Refined and by default it maps the context to Tram::Policy::Errors.

module RubygemsAPI
  class PlainTextError < BC::ExpectedError
    def match
      @context[:parsed] ||= JSON.parse(value)
    rescue JSON::ParserError
      @context[:plain_text] = value.to_s
      self
    end
  end

  class JsonType < BC::Ext::Refined
    def match
      @context[:parsed] ||= JSON.parse(value)
      self
    end

    def mapped
      @context[:parsed]
    end
  end

  Response = JsonType.or_a(PlainTextError)
end

RubygemsAPI::Response.match('{"project": ...}') # => #<JsonType ...>

match = RubygemsAPI::Response.match('Project not found!') # => #<PlainTextError ...>

# translation key: en.contracts.rubygems_api/plain_text_error.message
match.unpack # => "Service responded with a message: `Project not found!`"

Summary

That covers all the relevant scenarios for types and contract validations. If you have a case that is not covered and you find it useful - feel free to open an Issue

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/sclinede/blood_contracts-ext. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

License

The gem is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the BloodContracts::Ext project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.