Security News
Weekly Downloads Now Available in npm Package Search Results
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
interactor-contracts
Advanced tools
Interactor::Contracts is an extension to the interactor gem that gives you the ability to specify the expectations (expected inputs) and promises (expected outputs) of your interactors.
Add this line to your application's Gemfile:
gem 'interactor-contracts'
And then execute:
$ bundle
Or install it yourself as:
$ gem install interactor-contracts
Let's extend the sample AuthenticateUser
from the Interactor examples with a
contract that specifies its expectations and promises.
class AuthenticateUser
include Interactor
include Interactor::Contracts
expects do
required(:email).filled
required(:password).filled
end
promises do
required(:user).filled
required(:token).filled
end
on_breach do |breaches|
context.fail!(breaches)
end
def call
if user = User.authenticate(context.email, context.password)
context.user = user
context.token = user.secret_token
else
context.fail!(:message => "authenticate_user.failure")
end
end
end
The expects
block defines the expectations: the expected attributes of the
context prior to the interactor running, along with any predicates that further
constrain the input.
The promises
block defines the promises: the expected attributes of the
context after the interactor runs and successfully completes, along with any
predicates the further constrain the output. Note, for backward-compatibility,
this is also available via the assures
method.
Because interactors can have transitive dependencies through the use of organizers, any other inputs or outputs are ignored from the perspective of the contract and are passed along to the outgoing (successful) context.
Both expects
and promises
wrap dry-validation, so you can use any
predicates defined in it to describe the expected inputs and outputs of your
interactor.
By default, contract failures, or breaches, behave like the example above:
breached keys are set on the failed context with their contract failures as
values. Note that you do not have to define an on_breach
for the behavior, but
if you do this behavior will not occur.
If there are more complicated things you wish to do with contract failures, you can define one or more breach handlers.
To hook into a failed expectation or promise, you can use the on_breach
method to defined a breach handler. It should take a 1-arity block that expects
an array of Breach
objects. These objects have a property
attribute that
will give you the key that's in breach of its contract. Breaches also have a
messages
attribute that gives the reasons that property is in breach.
By default, when an on_breach
consequence is not specified, the contract will
#fail!
the Interactor::Context
with the keys that are in breach and arrays
of messages about what the breaches are.
For example, the above interactor acts as follows:
result = AuthenticateUser.call({})
#=> #<Interactor::Context email=["email is missing"], password=["password is missing"]>
result.failure? #=> true
If you would rather have your contract breaches be aggregated into, for example,
an errors
property, you could use a breach handler like the following:
on_breach do |breaches|
context.fail!(errors: breaches)
end
You can configure the underlying dry-validation
contract by passing
a block to the config
method in your contract. This block will be evaluated on
the underlying configuration for the contract. For example, if you want to set
up the contract to use I18n in your Rails app, you might do something like this:
class MyInteractor
include Interactor
include Interactor::Contracts
config do
messages.backend = :i18n
messages.load_paths << Rails.root / 'config' / 'locales' / 'errors.yml'
messages.top_namespace = :interactor_contracts
end
end
This sets up the I18n system (assuming the delicate load-order has been done in
the right way - you have to require i18n
prior to requiring
interactor-contracts
since we load dry-validation
immediately) to use your
custom file. All lookups for error messages happen starting at the
interactor_contracts
key in this example.
See the documentation for dry-validation
for more information.
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.
When writing code, you can use the helper application Guard to
automatically run tests and coverage tools whenever you modify and save a file.
This helps to eliminate the tedium of running tests manually and reduces the
change that you will accidentally forget to run the tests. To use Guard, run
bundle exec guard
.
Before committing code, run rake
to check that the code conforms to the style
guidelines of the project, that all of the tests are green (if you're writing a
feature; if you're only submitting a failing test, then it does not have to
pass!), and that the changes are sufficiently documented.
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.
Bug reports and pull requests are welcome on GitHub at https://github.com/michaelherold/interactor-contracts.
This library aims to support and is tested against the following Ruby versions:
If something doesn't work on one of these versions, it's a bug.
This library may inadvertently work (or seem to work) on other Ruby versions, however support will only be provided for the versions listed above.
If you would like this library to support another Ruby version or implementation, you may volunteer to be a maintainer. Being a maintainer entails making sure all tests run and pass on that implementation. When something breaks on your implementation, you will be responsible for providing patches in a timely fashion. If critical issues for a particular implementation exist at the time of a major release, support for that Ruby version may be dropped.
This library aims to adhere to Semantic Versioning 2.0.0. Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, that version should be immediately yanked and/or a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions. As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision. For example:
spec.add_dependency "interactor-contracts", "~> 0.1"
The gem is available as open source under the terms of the MIT License.
FAQs
Unknown package
We found that interactor-contracts demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
Security News
A Stanford study reveals 9.5% of engineers contribute almost nothing, costing tech $90B annually, with remote work fueling the rise of "ghost engineers."
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.