web_pipe 0.15.1 → 0.16.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8148f2a5701baf60d74d238ed32b6fcdaadaaf5006431322222a081d005caa01
-  data.tar.gz: 90a38228ba60cd9637584b85cffd06d0271df5bd2d3d9bc721b3d3cb7de61287
+  metadata.gz: b0a90514a384a44456634dd195280291d82ab67eb336f69904c0cdc6bc3518ba
+  data.tar.gz: b2a3295f82715c9bf128d971994667eda13095631349b7cb33e1ccb97777b7e8
 SHA512:
-  metadata.gz: 4bd1b21978116a5743d53106cc4c2b8f042dba4cbe63804adbc370174bf08a9221f563561b123a10445e5cb3f87b7672d9cf0ef8c1161e53a9b54f83ae3aba13
-  data.tar.gz: a0028185e4bfe8858206fc90c8e355891d3e9a14db81fad7076fd8c05960f01abd1418fc05bece3c6fe73585a5732e2f13318a6529e9d6fef75f4e86181da376
+  metadata.gz: b353968992c5d5f2d5952fe3ae55c1a2691e8c852e8dd72525b4fcbb6e35e5fe0741016cc362e1afcdfe217594bdc43adc182c46e752989006fe8a5cc6a694af
+  data.tar.gz: c5d206d3058b7bd83dc3b0634c97d77e0e21bfc1468e6745708e7eaffd8aef1d4c7467a49894de8161d2af1bfd212ce647a7858f61875ed3eabd784e4ed7a101

data/.rubocop.yml

@@ -1,5 +1,5 @@
 AllCops:
-  TargetRubyVersion: 2.7.2
+  TargetRubyVersion: 3.0
   NewCops: enable
   SuggestExtensions: false
   Exclude:

data/CHANGELOG.md

@@ -4,6 +4,16 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/)
 and this project adheres to [Semantic Versioning](http://semver.org/).
 
+## [0.16.0] - 2021-11-07
+### Added
+- Extract the DSL as an optional convenience layer and introduce
+  `WebPipe::Pipe` as top abstraction.
+  [#47](https://github.com/waiting-for-dev/web_pipe/pull/47)
+- Be able to plug anything responding to `#to_proc`.
+  [#47](https://github.com/waiting-for-dev/web_pipe/pull/47)
+- Be able to use anything responding to `#to_middlewares`.
+  [#47](https://github.com/waiting-for-dev/web_pipe/pull/47)
+
 ## [0.15.1] - 2021-09-19
 ### Added
 - `:not_found` extension

data/README.md

@@ -3,15 +3,18 @@
 
 # WebPipe
 
-`web_pipe` is a modular rack application builder through a pipe of
-operations on an immutable struct.
+`web_pipe` is a builder of composable rack applications through a pipe of
+functions on an immutable struct.
 
-In order to use in conjunction with [dry-rb](https://dry-rb.org/)
-ecosystem, see also
-[`dry-web-web_pipe`](https://github.com/waiting-for-dev/dry-web-web_pipe).
+> `web_pipe` plays incredibly well with `hanami 2`. If you want to create a
+> `hanami 2` app with `web_pipe`, you can take inspiration from this sample todo
+> application:
+>
+> https://github.com/waiting-for-dev/hanami_2_web_pipe_todo_app
 
-If you want to use it with a Rails project, don't miss docs for the [rails
-extension](docs/extensions/rails.md).
+To use in conjunction with [hanami](https://hanamirb.org/) [dry-rb](https://dry-rb.org/) ecosystem,
+see also
+[`dry-web-web_pipe`](https://github.com/waiting-for-dev/dry-web-web_pipe).
 
 1. [Introduction](docs/introduction.md)
 1. [Design model](docs/design_model.md)
@@ -49,7 +52,7 @@ extension](docs/extensions/rails.md).
    1. [Session](docs/extensions/session.md)
    1. [URL](docs/extensions/url.md)
 1. Recipes
-   1. [dry-rb integration](docs/recipes/dry_rb_integration.md)
+   1. [hanami 2 & dry-rb integration](docs/recipes/hanami_2_and_dry_rb_integration.md)
    1. [hanami-router integration](docs/recipes/hanami_router_integration.md)
    1. [Using all RESTful methods](docs/recipes/using_all_restful_methods.md)
 
@@ -97,8 +100,8 @@ run HelloApp.new
 ## Current status
 
 `web_pipe` is in active development but ready to be used in any environment.
-Common needs are covered and while you can expect some API changes, they won't
-be very important and everything will be properly documented.
+Everyday needs are covered, and while you can expect some API changes,
+they won't be essential, and we'll document everything appropriately.
 
 ## Contributing
 

data/docs/building_a_rack_application.md

@@ -1,6 +1,6 @@
 # Building a rack application
 
-In order to build a rack application with `web_pipe` you have to include
+To build a rack application with `web_pipe`, you have to include
 `WebPipe` module in a class:
 
 ```ruby

data/docs/composing_applications.md

@@ -3,10 +3,10 @@
 Previously, we have seen how to [compose plugged
 operations](plugging_operations/composing_operations.md) and how to [compose
 rack middlewares](using_rack_middlewares/composing_middlewares.md). The logical
-next step is thinking about composing `web_pipe` applications, which is exactly
-the same as composing both operations and middlewares at the same time.
+next step is composing `web_pipe` applications, which is the same as composing
+operations and middlewares simultaneously.
 
-The DSL method `compose` does exactly that:
+The DSL method `compose` does precisely that:
 
 ```ruby
 class HtmlApp
@@ -33,7 +33,7 @@ class MyApp
   include WebPipe
   
   compose :web, HtmlApp.new
-  # It does exactly the same than:
+  # It does exactly the same as:
   # use :web, HtmlApp.new
   # plug :web, HtmlApp.new
   

data/docs/connection_struct/configuring_the_connection_struct.md

@@ -1,13 +1,13 @@
 # Configuring the connection struct
 
 [Extensions](../extensions.md) add extra behaviour to the connection struct.
-Sometimes they need some user provided value to work properly or they may allow
-some tweak depending on user needs.
+Sometimes they need some user-provided value to work properly or allow some
+tweak depending on user needs.
 
 For this reason, you can add configuration data to a `WebPipe::Conn` instance
 so that extensions can fetch it. This shared place where extensions look for
-what they need is `#config` attribute, which is very similar to `#bag` except
-for its more private intention.
+what they need is the `#config` attribute, which is very similar to `#bag`
+except for its more private intention.
 
 In order to interact with `#config`, you can use the method `#add_config(key,
 value)` or [`Config` plug](../plugs/config.md).

data/docs/connection_struct/halting_the_pipe.md

@@ -1,36 +1,34 @@
 # Halting the pipe
 
-Each operation in a pipe takes a single `WebPipe::Conn` instance as argument
-and returns another (or same) instance of it. In this way, a series of
-operations on the connection struct is propagated until final response is sent
-to the client.
+Each operation in a pipe takes a single `WebPipe::Conn` instance as an argument
+and returns another (or the same) instance. A series of operations on the
+connection struct is propagated until a final response is sent to the client.
 
 More often than not, you may need to conditionally stop the propagation of a
-pipe at a given operation. A lot of times the requirement to do something like
-that will be authorization policies. For example, you could fetch the user
-requesting a resource. In the case she was granted to perform required action
-you would go on.  However, if she wasn't you would like to halt the connection
-and respond with a 4xx http status code.
+pipe at a given operation. For example, you could fetch the user requesting a
+resource. In the case they were granted to perform the required action, you
+would go on.  However, if they weren't, you would like to halt the connection
+and respond with a 4xx HTTP status code.
 
-In order to stop the pipe, you simply have to call `#halt` on the connection
-struct.
+To stop the pipe, you have to call `#halt` on the connection struct.
 
-At implementation level, we must admit that we've not been 100% accurate until
-now. We said that the first operation in the pipe recerived a `WebPipe::Conn`
-instance. That's true. However, it is more precise saying that it gets a
-`WebPipe::Conn::Ongoing` instance (`WebPipe::Conn::Ongoing` being a subclass of
+At the implementation level, we must admit that we've not been 100% accurate
+until now. We said that the first operation in the pipe received a
+`WebPipe::Conn` instance. That's true. However, it is more precise to say that
+it gets a `WebPipe::Conn::Ongoing` instance `WebPipe::Conn::Ongoing` being a
+subclass of
 `WebPipe::Conn`).
 
 As long as an operation responds with a `WebPipe::Conn::Ongoing`
 instance, the propagation will go on. However, when an operation
 returns a `WebPipe::Conn::Halted` instance (another subclass of
 `WebPipe::Conn`) then any operation downstream will be ignored.
-Calling `#halt` simply copies all attributes to a `WebPipe::Conn::Halted`
+Calling `#halt` copies all attributes to a `WebPipe::Conn::Halted`
 instance and returns it.
 
-This made-up example checks if the user in the request has an admin role. If
-she has, it returns solicited resource. Otherwise she is unauthorized and never
-gets the resource.
+This made-up example checks if the user in the request has an admin role. In
+that case, it returns the solicited resource. Otherwise, they're unauthorized,
+and they never get it.
 
 ```ruby
 WebPipe.load_extensions(:params)

data/docs/connection_struct/sharing_data_downstream.md

@@ -1,19 +1,20 @@
 # Sharing data downstream
 
-Usually you'll find the need to prepare some data in one operation with the
+Usually, you'll find the need to prepare some data in one operation with the
 intention for it to be consumed by another downstream operation. The connection
-struct has a `#bag` attribute which is useful for this purpose.
+struct has a `#bag` attribute which is helpful for this purpose.
 
-`WebPipe::Conn#bag` is a `Hash` with `Symbol` keys where values can
-be anything you need to share. To help with the process we have following methods:
+`WebPipe::Conn#bag` is a `Hash` with `Symbol` keys where the values can be
+anything you need to share. To help with the process, we have the following
+methods:
 
 - `#add(key, value)`: Assigns a value to a key.
-- `#fetch(key)`, `#fetch(key, default)`: Retrieves value associated
-  to given key. If it is not found, `default` is returned when
+- `#fetch(key)`, `#fetch(key, default)`: Retrieves the value associated
+  to a given key. If it is not found, `default` is returned when
   provided.
 
-This is a simple example of a web application which reads a `name`
-parameter and normalizes it before using in the response body.
+This is a simple example of a web application that reads a `name`
+parameter and normalizes it before using it in the response body.
 
 ```ruby
 # config.ru

data/docs/connection_struct.md

@@ -1,11 +1,11 @@
 # Connection struct
 
-First operation you plug in a `web_pipe` application receives an instance of
-`WebPipe::Conn` which has been automatically created.
+The first operation you plug in a `web_pipe` application receives an instance of
+`WebPipe::Conn` automatically created.
 
-This is just a struct data type which contains all the information from current
-web request. In this regard, you can think of it as a structured rack's env
-hash.
+`WebPipe::Conn` is just a struct data type that contains all the information
+from the current web request. In this regard, you can think of it as a
+structured rack's env hash.
 
 Request related attributes of this struct are:
 
@@ -22,25 +22,27 @@ Request related attributes of this struct are:
 - `#env`: Rack's env hash.
 - `#request`: Rack::Request instance.
 
-Your operations must return another (or same) instance of the struct, which
-will be consumed by next operation downstream. The struct contains methods to
-add response data to it:
+Your operations must return another (or the same) instance of the struct, which
+will be consumed by the next operation downstream.
 
-- `#set_status(code)`: makes it accessible in `#status` attribute.
-- `#set_response_body(body)`: makes it accessible in `#response_body`
+The struct contains methods to add the response data to it:
+
+- `#set_status(code)`: makes it accessible in the `#status` attribute.
+- `#set_response_body(body)`: makes it accessible in the `#response_body`
   attribute.
 - `#set_response_headers(headers)`: makes them accessible in
-  `#response_headers` attribute. Besides, there are also
+  the `#response_headers` attribute. Besides, there are also
   `#add_response_header(key, value)` and `#delete_response_header(key)`
   methods.
 
-Response in last struct returned in the pipe will be what is sent to client.
+The response in the last struct returned in the pipe will be what is sent to
+client.
 
 Every attribute and method is [fully
 documented](https://www.rubydoc.info/github/waiting-for-dev/web_pipe/master/WebPipe/Conn)
-in code documentation.
+in the code documentation.
 
-Here we have a contrived web application which just returns as response body
+Here we have a contrived web application which returns as response body
 the request body it has received:
 
 ```ruby
@@ -67,16 +69,17 @@ end
 run DummyApp.new
 ```
 
-As you can see, default available features are the very minimal to read from a
-request and to write a response. However, you can pick from several
+As you can see, by default, the available features are very minimal to read
+from a request and to write a response. However, you can pick from several
 (extensions)[extensions.md] which will make your life much easier.
 
 Immutability is a core design principle in `web_pipe`. All methods in
-`WebPipe::Conn` which are used to add data to it (both in core behaviour and
-extensions) return a fresh new instance. It also makes possible chaining
+`WebPipe::Conn`, which are used to add data to it (both in core behavior and
+extensions), return a fresh new instance. It also makes possible chaining
 methods in a very readable way.
 
-You can use ruby 2.7 pattern matching on a `WebPipe::Conn` struct, as in:
+If you're using ruby 2.7 or greater, you can pattern match on a `WebPipe::Conn`
+struct, as in:
 
 ```ruby
 # GET http://example.org

data/docs/design_model.md

@@ -1,6 +1,6 @@
 # Design model
 
-If you are familiar with rack you know that it models a two-way pipe. In it,
+If you are familiar with rack, you know that it models a two-way pipe. In it,
 each middleware has the ability to:
 
 - During the outbound trip modifying the request as it heads to the actual
@@ -20,11 +20,12 @@ each middleware has the ability to:
 
 ```
 
-`web_pipe` follows a simpler but equally powerful model: a one-way pipe which
-is abstracted on top of rack. A struct that contains data from a web request is
-piped trough a stack of operations (functions). Each operation takes as
-argument an instance of the struct and returns also an instance of it.
-Response data can be added to the struct at any moment in the pipe.
+`web_pipe` follows a simpler but equally powerful model: a one-way
+ pipe abstracted on top of rack. A struct that contains data from a
+ web request is piped through a stack of operations (functions). Each
+ operation takes as argument an instance of the struct and also
+ returns an instance of it. You can add response data to the struct at
+ any moment in the pipe.
 
 ```
 
@@ -35,9 +36,9 @@ Response data can be added to the struct at any moment in the pipe.
 ```
 
 Additionally, any operation in the stack can halt the propagation of the pipe,
-leaving downstream operations unexecuted. In this way, final response is the
-one contained in the struct at the moment the pipe was halted, or last one if
-the pipe wasn't halted.
+leaving downstream operations unexecuted. In this way, the final
+response is the one contained in the struct at the moment the pipe was
+halted, or the last one if the pipe wasn't halted.
 
 As you may know, this is the same model used by Elixir's
 [`plug`](https://hexdocs.pm/plug/readme.html), from which `web_pipe` takes

data/docs/dsl_free_usage.md

@@ -1,26 +1,97 @@
 # DSL free usage
 
-DSL's (like the one in `web_pipe` with methods like `plug` or
-`use`) provide developers with a user friendly and ergonomic way to
-use a library. However, they usually come at expenses of increasing complexity
-in internal code (which sooner than later translates into some kind of issue).
+DSL's (like the one in `web_pipe` with class methods like `plug` or
+`use`) provide developers with a user-friendly way to
+use a library. However, they usually come at the expense of increasing
+complexity in internal code (which sooner than later translates into some
+issue).
 
-`web_pipe` has tried to do an extra effort to minimize these problems. For this
-reason, DSL in this library is just a layer on top of an independent core
-functionality.
+`web_pipe` has tried to make an extra effort to minimize these problems. For
+this reason, the DSL in this library is just a layer providing convenience on
+top of the independent core functionality.
 
-To use `web_pipe` without its DSL layer, you just need to initialize a
-`WebPipe::App` instance with an array of all the operations that otherwise
-you'd `plug`. That instance will be a rack application ready to be used.
+The DSL methods delegate transparently to instances of `WebPipe::Pipe`, so you
+can also work directly with them and forget about magic.
+
+For instance, the following rack application written through the DSL:
 
 ```ruby
 # config.ru
-require 'web_pipe/app'
+require 'web_pipe'
+
+WebPipe.load_extensions(:params)
+
+class HelloApp
+  include WebPipe
+
+  plug :fetch_name
+  plug :render
+
+  private
+
+  def fetch_name(conn)
+    conn.add(:name, conn.params['name'])
+  end
+
+  def render(conn)
+    conn.set_response_body("Hello, #{conn.fetch(:name)}!")
+  end
+end
+
+run HelloApp.new
+```
+
+is exactly equivalent to:
+
+```ruby
+# config.ru
+require 'web_pipe'
+require 'web_pipe/pipe'
+
+WebPipe.load_extensions(:params)
+
+app = WebPipe::Pipe.new
+                   .plug(:fetch_name, ->(conn) { conn.add(:name, conn.params['name']) })
+                   .plug(:render, ->(conn) { conn.set_response_body("Hello, #{conn.fetch(:name)}") })
+
+run app
+```
+
+As you see, the instance of `WebPipe::Pipe` is itself the rack application.
+
+As with the DSL, plug operations can be resolved from a container given on
+initialization.
+
+```ruby
+container = {
+  fetch_name: ->(conn) { conn.add(:name, conn.params['name']) },
+  render: ->(conn) { conn.set_response_body("Hello, #{conn.fetch(:name)}") }
+}
+
+app = WebPipe::Pipe.new(container: container)
+                   .plug(:fetch_name, :fetch_name)
+                   .plug(:render, :render)
+
+run app
+```
+
+Likewise, you can provide a context object to resolve methods when only a name
+is given on `#plug`:
+
+```ruby
+class Context
+  def fetch_name(conn)
+    conn.add(:name, conn.params['name'])
+  end
 
-op_1 = ->(conn) { conn.set_status(200) }
-op_2 = ->(conn) { conn.set_response_body('Hello, World!') }
+  def render(conn)
+    conn.set_response_body("Hello, #{conn.fetch(:name)}")
+  end
+end
 
-app = WebPipe::App.new([op_1, op_2])
+app = WebPipe::Pipe.new(context: Context.new)
+                   .plug(:fetch_name)
+                   .plug(:render)
 
 run app
 ```

data/docs/extensions/container.md

@@ -1,18 +1,17 @@
 # Container
 
-`:container` is a very simple extension which allows you to configure a
-dependency injection container to be accessible from a `WebPipe::Conn`
-instance.
+`:container` is a simple extension that allows you to configure a dependency
+injection container to be accessible from a `WebPipe::Conn` instance.
 
-The container to use must be configured under `:configuration` key. It will be
-accessible through the `#container` method.
+The container to use must be configured under the `:container` config key. It
+will be accessible through the `#container` method.
 
-You may be thinking why you should worry about configuring a container for a
+You may be wondering why you should worry about configuring a container for a
 connection instance when you already have access to the container configured
-for an application (from where you can resolve plugged operations). The idea
-here is decoupling operations from application DSL. If at anytime in the future
-you decide to get rid off the DSL, the process will be straightforward if
-operations are using the container configured in a connection instance.
+for an application (where you can resolve plugged operations). The idea is
+decoupling operations from application DSL. If you decide to get rid of the DSL
+at any time in the future, the process will be straightforward if operations
+are using the container configured in a connection instance.
 
 ```ruby
 require 'web_pipe'

data/docs/extensions/cookies.md

@@ -24,8 +24,10 @@ This extension adds following methods:
   - `same_site:` must be one of the symbols `:none`, `:lax` or `:strict`.
 
 - `#delete_cookie(key)` or `#delete_cookie(key, options)`: Instructs browser to
-  delete a previously sent cookie. Deleting a cookie just means setting again
-  the same key with an expiration time in the past.
+  delete a previously sent cookie.
+  
+  Deleting a cookie just means setting again the same key with an expiration
+  time in the past.
   
   It accepts `domain:` and `path:` options (see above for a description of
   them).

data/docs/extensions/dry_schema.md

@@ -1,20 +1,21 @@
 # Dry Schema
 
-Extension providing integration for a common
+Extension providing integration for every day
 [`dry-schema`](https://dry-rb.org/gems/dry-schema/) workflow to validate
 parameters.
 
 A plug `WebPipe::Plugs::SanitizeParams` is added so that you can use it in your
 pipe of operations. It takes as arguments a `dry-schema` schema and a handler.
 On success, it makes output available at `WebPipe::Conn#sanitized_params`. On
-error, it calls given handler with the connection struct and validation result.
+error, it calls the given handler with the connection struct and validation
+result.
 
 This extension automatically loads [`:params` extension](params.md),
 as it takes `WebPipe::Conn#params` as input for the validation schema.
 
 Instead of providing an error handler as the second argument for the plug, you
-can configure it under `:param_sanitization_handler` key. In this way, it can
-be reused through composition by others applications.
+can configure it under the `:param_sanitization_handler` key. In this way, it
+can be reused through composition by other applications.
 
 ```ruby
 require 'db'

data/docs/extensions/flash.md

@@ -1,22 +1,20 @@
 # Flash
 
-This extension provides with typical flash messages functionality. Messages for
-users are stored in session in order to be consumed by another request after a
-redirect.
+This extension provides the typical flash messages functionality. Messages for
+users are stored in session to be consumed by another request after a redirect.
 
 This extension depends on
 [`Rack::Flash`](https://rubygems.org/gems/rack-flash3) (gem name is
 `rack-flash3`) and `Rack::Session` (shipped with rack) middlewares.
 
-`WebPipe::Conn#flash` contains the flash bag. In order to add a message to it,
-you can use `#add_flash(key, value)` method.
+`WebPipe::Conn#flash` contains the flash bag. You can use the `#add_flash(key,
+value)` method to add a message to it.
 
-There is also an `#add_flash_now(key, value)` method, which is used to add a
-message to the bag with the intention for it to be consumed in the current
-request. Be aware that it is in fact a coupling with the view layer.
-Something that has to be consumed in the current request should be just data
-given to the view layer, but it helps when it can treat both scenarios as flash
-messages.
+There is also an `#add_flash_now(key, value)` method, which adds a message to
+the bag to consume it in the current request. Be aware that it is, in fact,
+coupling with the view layer. Something that has to be consumed in the current
+request should be just data given to the view layer, but it helps when it can
+treat both scenarios as flash messages.
 
 ```ruby
 require 'web_pipe'

data/docs/extensions/hanami_view.md

@@ -1,13 +1,13 @@
 # Hanami View
 
-> This extension currently works with `hanami-view` v2.0.0.alpha2, which is not
-still released but it's available on the gem repository.
+This extension currently works with `hanami-view` v2.0.0.alpha2, which is not
+still released but available on the gem repository.
 
-This extensions integrates with [hanami-view](https://github.com/hanami/view)
-rendering system to set a hanami-view output as response body.
+This extension integrates with [hanami-view](https://github.com/hanami/view)
+rendering system to set a hanami-view output as the response body.
 
 `WebPipe::Conn#view` method is at the core of this extension. In its basic
-behaviour, you provide to it a view instance you want to render and any
+behavior, you provide to it a view instance you want to render and any
 exposures or options it may need:
 
 ```ruby
@@ -37,9 +37,8 @@ class MyApp
   end
 end
 ```
-
-However, you can resolve a view from a container if you also use (`:container`
-extension)[container.md]:
+However, you can resolve a view from a container if you also use the
+(`:container` extension)[container.md]:
 
 ```ruby
 require 'hanami_view'
@@ -64,13 +63,10 @@ end
 ```
 
 As in a standard call to `Hanami::View#call`, you can override the context
-(`Hanami::View::Context`) to use through `context:` option. However, it is still
-possible to leverage configured default context while being able to inject
-request specific data to it.
+(`Hanami::View::Context`) to use through the `context:` option. However, it is still possible to leverage the configured default context while injecting specific data to it.
 
-For that to work, you have to specify required dependencies (in this case,
-request specific data) to your hanami-view's context. A very convenient way to do
-that is with [`dry-auto_inject`](https://dry-rb.org/gems/dry-auto_inject):
+To work, you have to specify required dependencies (in this case,
+request specific data) to your hanami-view's context. A very convenient way to do that is with [`dry-auto_inject`](https://dry-rb.org/gems/dry-auto_inject):
 
 ```ruby
 require 'hanami/view/context'

data/docs/extensions/params.md

@@ -1,10 +1,11 @@
 # Params
 
 This extension adds a `WebPipe::Conn#params` method which returns
-request parameters as a Hash where any number of transformations
-can be configured.
+request parameters as a Hash. Then, any number of transformations on it can be
+configured.
 
-When no transformations are configured, `#params` just returns GET and POST parameters as a hash:
+When no transformations are configured, `#params` returns GET and POST
+parameters as a hash:
 
 ```ruby
 # http://www.example.com?foo=bar
@@ -102,7 +103,8 @@ plug(:this) do |conn|
 end
 # ...
 ```
-Finally, you can override configured transformations injecting another set at the moment of calling `#params`:
+Finally, you can override the configured transformations injecting another set
+at the moment of calling `#params`:
 
 ```ruby
 # ...