interaktor 0.5.0 → 0.6.0.pre

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 6937b87e9844c597a62670ffe90e7d2abba7a7559bc42254d195973e685b109f
-  data.tar.gz: 2d6f4b42e049de1d271b42118118a1a847f7fb71f21ce03c87394549af710419
+  metadata.gz: d3821ddb2f6707bec7ea45c0a7043b193cd7623be4c51bd83268806d76c652db
+  data.tar.gz: 0bc4cfb698d304703ad26e9aeb3130485a7fa77fa0d29e309224e191755d2c1f
 SHA512:
-  metadata.gz: 3c68b887ff7cd0888d165ef5468029225b20f046f339bbea9184cd072ee221d7a1bb7bf37dbfff8b24c06ffc17c11839333172000d277d17a07307d788ad2530
-  data.tar.gz: 3b6546acf884222f52472887ddd2af0439a891486aa542a7410ef787ed7b8ac2e662c728068d7f2852ee8cc3bf83610fa4c3f97410c19ac764d04a6a81457575
+  metadata.gz: a3af0ae98c859a81df86bd02ca3eb085d053e9a436f27755cec325ec5a83ed782bb5ceffae3ce2e37cdecb780eefe72c217eecaac3ef0759ea13c0a127c9a1d8
+  data.tar.gz: 34223391e17c7c74a575b66e3ab70aca05e4effedd511f5b458d4e61fecbfd790776bce72c2cd53d85712fa29a73ef3e11377a622cf262a1362ebc866b750aca

data/README.md

@@ -1,7 +1,6 @@
 # Interaktor
 
-[![Gem Version](https://img.shields.io/gem/v/interaktor.svg)](http://rubygems.org/gems/interaktor)
-[![Build Status](https://img.shields.io/travis/collectiveidea/interaktor/master.svg)](https://travis-ci.org/taylorthurlow/interaktor)
+[![gem version](https://badge.fury.io/rb/interaktor.svg)](http://rubygems.org/gems/interaktor)
 
 **DISCLAIMER: Interaktor is considered to be stable, but has not yet reached version 1.0. Following semantic versioning, minor version updates can introduce breaking changes. Please review the changelog when updating.**
 
@@ -9,10 +8,10 @@
 
 Fundamentally, Interaktor is the same as Interactor, but with the following changes:
 
-- Required explicit definition of interaktor "attributes" which replaces the concept of the interaktor context. Attributes are defined using a schema DSL provided by [dry-schema](https://github.com/dry-rb/dry-schema), which allows for complex validation, if desired.
+- Explicit definition of interaktor "attributes" which replaces the concept of the interaktor context. Attributes are defined using the DSL provided by [ActiveModel](https://rubygems.org/gems/activemodel), which allows for complex validation, if desired. This is the same DSL used internally by ActiveRecord, so you will be familiar with validations if you have experience with ActiveRecord.
 - The interaktor "context" is no longer a public-facing concept, all data/attribute accessors/setters are defined as attributes
 - Attributes passed to `#fail!` must be defined in advance
-- Interaktors support early-exit functionality through the use of `#success!`, which functions the same as `#fail!` in that you must define the required success attributes on the interaktor
+- Interaktors support early-exit functionality through the use of `#success!`, which functions the same as `#fail!` in that you must define the success attributes on the interaktor
 
 ## Getting started
 
@@ -30,21 +29,44 @@ Interaktors are used to encapsulate your application's [business logic](http://e
 
 ### Attributes
 
-#### Input attributes
+Attributes are defined using the DSL provided by ActiveModel, whose documentation can be found [here](https://api.rubyonrails.org/classes/ActiveModel/Attributes.html). The same DSL is used to define _input_ attributes, _success_ attributes, and _failure_ attributes.
+
+The aforementioned documentation provides a reasonably comprehensive overview of the DSL is used. But generally a definition block looks like this:
+
+```ruby
+attribute :name, :string
+attribute :email, :string
+attribute :date_of_birth
+
+validates :name, presence: true
+validates :email, presence: true, allow_nil: true
+validates :date_of_birth, presence: true
+```
 
-Depending on its definition, an interaktor may require attributes to be passed in when it is invoked. These attributes contain everything the interaktor needs to do its work.
+Defining an attribute requires a name, and optionally a type. The available types are not currently well documented, but can be found clearly in the source code of ActiveModel. At the time of writing (activemodel `8.1.1`), the following types are available: `big_integer`, `binary`, `boolean`, `date`, `datetime`, `decimal`, `float`, `immutable_string`, `integer`, `string`, and `time`.
 
-Attributes are defined using a schema DSL provided by the [dry-schema](https://github.com/dry-rb/dry-schema) gem. It allows the construction of schemas for validating attributes. The schema is typically provided as a block argument to the `input` class method as seen below.
+Defining a type will allow ActiveModel to perform type-specific validation and coercion. This means that when a value is assigned to an attribute, ActiveModel will attempt to convert it to the specified type, and raise an error if the conversion is not possible.
 
-This example is an extremely simple case, and dry-schema supports highly complex schema validation, like type checking, nested hash data validation, and more. For more information on defining an attribute schema, please see the [dry-schema documentation website](https://dry-rb.org/gems/dry-schema). This link should take you to the latest version of dry-schema, but be sure to check that the version of dry-schema in your application bundle matches the documentation you are viewing.
+The type argument can also be a class constant, but that class will need to define certain methods that ActiveModel relies on in order to work properly - the errors raised by ActiveModel should illustrate which methods are required.
+
+Validations should look familiar to Rails developers. They are defined using the `validates` method, which takes a hash of options. The options are the same as those used in Rails, so you can refer to the Rails documentation for more information.
+
+In general, it is recommended to be careful with validations. These are not database records - they are simply a way to ensure that the data passed into an interaktor is valid and consistent before it is processed. Consider thinking twice before adding validations more complicated than typical `nil`/`blank?` checks.
+
+#### Input attributes
+
+Input attributes are attributes that are passed into an interaktor when it is invoked. The following interaktor defines a required `name` attribute and an optional `email` attribute.
 
 ```ruby
 class CreateUser
   include Interaktor
 
   input do
-    required(:name)
-    optional(:email)
+    attribute :name, :string
+    attribute :email, :string
+
+    validates :name, presence: true
+    validates :email, presence: true, allow_nil: true
   end
 
   def call
@@ -55,33 +77,37 @@ class CreateUser
   end
 end
 
-CreateUser.call(name: "Foo Bar")
+CreateUser.call!(name: "Foo Bar")
 ```
 
-`input` will also accept a `Dry::Schema::Params` object directly, if for some reason the schema needs to be constructed elsewhere.
+#### Success and failure attributes
 
-**A note about type checking**: Type checking is cool, but Ruby is a dynamic language, and Ruby developers tend to utilize the idea of [duck typing](https://en.wikipedia.org/wiki/Duck_typing). Forcing the attributes of an interaktor to be of a certain type in order to validate might sound like a good idea, but it can often cause problems in situations where you might like to use duck typing, for example, when using stubs in tests.
+Based on the outcome of the interaktor's work, we can define attributes to be provided.
 
-#### Output attributes
+The use of `#success!` allows you to early return from an interaktor's work. If no `success` attributes are defined, and the `call` method finishes execution normally, then the interaktor is considered to to have completed successfully. Conversely, if `success` attributes are defined, and the `call` method finishes execution normally (i.e. without a raised error, and without calling `success!`), then an exception will be raised.
 
-Based on the outcome of the interaktor's work, we can require certain attributes. In the example below, we must succeed with a `user_id` attribute, and if we fail, we must provide an `error_messages` attribute.
-
-The use of `#success!` allows you to early-return from an interaktor's work. If no `success` attribute is provided, and the `call` method finishes execution normally, then the interaktor is considered to to have completed successfully.
+In the example below, we must succeed with a `user_id` attribute, and if we fail, we must provide an `error_messages` attribute.
 
 ```ruby
 class CreateUser
   include Interaktor
 
   input do
-    required(:name).filled(:string)
+    attribute :name, :string
+
+    validates :name, presence: true
   end
 
   success do
-    required(:user_id).value(:integer)
+    attribute :user_id, :integer
+
+    validates :user_id, presence: true
   end
 
   failure do
-    required(:error_messages).value(array[:string])
+    attribute :error_messages # string array
+
+    validates :error_messages, presence: true
   end
 
   def call
@@ -104,6 +130,8 @@ else
 end
 ```
 
+The returned object is an instance of `Interaktor::Interaction`. Depending on whether the interaction was successful or not, the object will have different attributes and methods available. These methods are determined by the success and failure attributes defined on the interaktor. It is not possible to access input attributes on the Interaction object.
+
 #### Dealing with failure
 
 `#fail!` always throws an exception of type `Interaktor::Failure`.
@@ -254,29 +282,13 @@ There are two kinds of interaktors built into the Interaktor library: basic inte
 A basic interaktor is a class that includes `Interaktor` and defines `call`.
 
 ```ruby
-class AuthenticateUser
+class PrintAThing
   include Interaktor
 
-  input do
-    required(:email).filled(:string)
-    required(:password).filled(:string)
-  end
-
-  success do
-    required(:user)
-    required(:token).filled(:string)
-  end
-
-  failure do
-    required(:message).filled(:string)
-  end
+  input { attribute :name }
 
   def call
-    if user = User.authenticate(email, password)
-      success!(user: user, token: user.secret_token)
-    else
-      fail!(message: "authenticate_user.failure")
-    end
+    puts name
   end
 end
 ```
@@ -285,18 +297,16 @@ Basic interaktors are the building blocks. They are your application's single-pu
 
 ### Organizers
 
-An organizer is an important variation on the basic interaktor. Its single purpose is to run _other_ interaktors.
+An organizer is a variation on the basic interaktor. Its single purpose is to run _other_ interaktors.
 
 ```ruby
-class PlaceOrder
+class DoSomeThingsInOrder
   include Interaktor::Organizer
 
   input do
-    required(:order_params).filled(:hash)
-  end
+    attribute :name, :string
 
-  success do
-    required(:order)
+    validates :name, presence: true
   end
 
   organize CreateOrder, ChargeCard, SendThankYou
@@ -326,14 +336,12 @@ class OrdersController < ApplicationController
 end
 ```
 
-The organizer passes its own input arguments (if present) into first interaktor that it organizes, which is called and executed using those arguments. For the following interaktors in the organize list, each interaktor receives its input arguments from the previous interaktor (both input arguments and success arguments, with success arguments taking priority in the case of a name collision).
+The organizer passes its own input arguments (if present) into first interaktor that it organizes (in the above example, `CreateOrder`), which is called and executed using those arguments. For the following interaktors in the organize list, each interaktor receives its input arguments from the previous interaktor (both input arguments and success arguments, with success arguments taking priority in the case of a name collision).
 
-Any arguments which are _not_ accepted by the next interaktor (listed as required or optional input attributes) are dropped in the transition.
+Any arguments which are _not_ accepted by the next interaktor (listed as an input attribute) are dropped in the transition.
 
 If the organizer specifies any success attributes, the final interaktor in the
-organized list must also specify those success attributes. In general, it is
-recommended to avoid using success attributes on an organizer in the first
-place, to avoid coupling between the organizer and the interaktors it organizes.
+organized list must also specify those success attributes.
 
 #### Rollback
 
@@ -346,11 +354,15 @@ class CreateOrder
   include Interaktor
 
   input do
-    required(:order_params).filled(:hash)
+    attribute :order_params
+
+    validates :order_params, presence: true
   end
 
   success do
-    required(:order)
+    attribute :order
+
+    validates :order, presence: true
   end
 
   def call
@@ -380,17 +392,25 @@ class AuthenticateUser
   include Interaktor
 
   input do
-    required(:email).filled(:string)
-    required(:password).filled(:string)
+    attribute :email, :string
+    attribute :password, :string
+
+    validates :email, presence: true
+    validates :password, presence: true
   end
 
   success do
-    required(:user)
-    required(:token).filled(:string)
+    attribute :user
+    attribute :token, :string
+
+    validates :user, presence: true
+    validates :token, presence: true
   end
 
   failure do
-    required(:message).filled(:string)
+    attribute :message
+
+    validates :message, presence: true
   end
 
   def call
@@ -422,11 +442,11 @@ describe AuthenticateUser do
       end
 
       it "provides the user" do
-        expect(result.user).to eq(user)
+        expect(result.user).to eq user
       end
 
       it "provides the user's secret token" do
-        expect(result.token).to eq("token")
+        expect(result.token).to eq "token"
       end
     end
 
@@ -457,18 +477,7 @@ It's a good idea to define your own interfaces to your models. Doing so makes it
 class AuthenticateUser
   include Interaktor
 
-  input do
-    required(:email).filled(:string)
-    required(:password).filled(:string)
-  end
-
-  success do
-    required(:user)
-  end
-
-  failure do
-    required(:message).filled(:string)
-  end
+  # ...
 
   def call
     user = User.find_by(email: email)

data/interaktor.gemspec

@@ -1,6 +1,6 @@
 Gem::Specification.new do |spec|
   spec.name = "interaktor"
-  spec.version = "0.5.0"
+  spec.version = "0.6.0.pre"
 
   spec.author = "Taylor Thurlow"
   spec.email = "thurlow@hey.com"
@@ -12,7 +12,7 @@ Gem::Specification.new do |spec|
   spec.required_ruby_version = ">= 3.0"
   spec.require_path = "lib"
 
-  spec.add_runtime_dependency "dry-schema", "~> 1.0"
+  spec.add_runtime_dependency "activemodel", ">= 7.0.9"
   spec.add_runtime_dependency "zeitwerk", ">= 2"
 
   spec.add_development_dependency "rake", "~> 13.0"

data/lib/interaktor/attributes.rb

@@ -0,0 +1,24 @@
+require "active_model"
+
+module Interaktor
+  class Attributes
+    include ::ActiveModel::Attributes
+    include ::ActiveModel::Serialization
+    include ::ActiveModel::Validations
+
+    if defined?(::ActiveModel::Attributes::Normalization)
+      include ::ActiveModel::Attributes::Normalization
+    end
+
+    DISALLOWED_ATTRIBUTE_NAMES = instance_methods
+      .map { |m| m.to_s.freeze }
+      .freeze
+
+    def self.check_for_disallowed_attribute_names!
+      attribute_names
+        .select { |name| DISALLOWED_ATTRIBUTE_NAMES.include?(name) }
+        .join(", ")
+        .tap { |names| raise ArgumentError, "Disallowed attribute name(s): #{names}" if names.present? }
+    end
+  end
+end