{"id":13411948,"url":"https://github.com/drapergem/draper","last_synced_at":"2025-05-14T21:00:18.496Z","repository":{"id":37822056,"uuid":"1980539","full_name":"drapergem/draper","owner":"drapergem","description":"Decorators/View-Models for Rails Applications","archived":false,"fork":false,"pushed_at":"2025-03-06T14:34:59.000Z","size":1407,"stargazers_count":5241,"open_issues_count":25,"forks_count":527,"subscribers_count":70,"default_branch":"master","last_synced_at":"2025-05-07T20:28:17.498Z","etag":null,"topics":["decorators","ruby"],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/drapergem.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2011-06-30T22:03:24.000Z","updated_at":"2025-04-27T20:45:18.000Z","dependencies_parsed_at":"2023-01-31T10:45:46.306Z","dependency_job_id":"b530daf5-7f32-458e-b47a-d49101d73dad","html_url":"https://github.com/drapergem/draper","commit_stats":{"total_commits":909,"total_committers":195,"mean_commits":4.661538461538462,"dds":0.7733773377337734,"last_synced_commit":"f74a2d41519f7879560769cbbcc4de1b0eb1ddc8"},"previous_names":[],"tags_count":60,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/drapergem%2Fdraper","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/drapergem%2Fdraper/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/drapergem%2Fdraper/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/drapergem%2Fdraper/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/drapergem","download_url":"https://codeload.github.com/drapergem/draper/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253234155,"owners_count":21875555,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["decorators","ruby"],"created_at":"2024-07-30T20:01:19.074Z","updated_at":"2025-05-14T21:00:18.339Z","avatar_url":"https://github.com/drapergem.png","language":"Ruby","readme":"# Draper: View Models for Rails\n\n[![Actions Status](https://github.com/drapergem/draper/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/drapergem/draper/actions?query=workflow%3Aci+branch%3Amaster)\n[![Code Climate](https://codeclimate.com/github/drapergem/draper.svg)](https://codeclimate.com/github/drapergem/draper)\n[![Test Coverage](https://api.codeclimate.com/v1/badges/0d40c43951d516bf6985/test_coverage)](https://codeclimate.com/github/drapergem/draper/test_coverage)\n[![Inline docs](http://inch-ci.org/github/drapergem/draper.svg?branch=master)](http://inch-ci.org/github/drapergem/draper)\n\nDraper adds an object-oriented layer of presentation logic to your Rails\napplication.\n\nWithout Draper, this functionality might have been tangled up in procedural\nhelpers or adding bulk to your models. With Draper decorators, you can wrap your\nmodels with presentation-related logic to organise - and test - this layer of\nyour app much more effectively.\n\n## Why Use a Decorator?\n\nImagine your application has an `Article` model. With Draper, you'd create a\ncorresponding `ArticleDecorator`. The decorator wraps the model, and deals\n*only* with presentational concerns. In the controller, you decorate the article\nbefore handing it off to the view:\n\n```ruby\n# app/controllers/articles_controller.rb\ndef show\n  @article = Article.find(params[:id]).decorate\nend\n```\n\nIn the view, you can use the decorator in exactly the same way as you would have\nused the model. But whenever you start needing logic in the view or start\nthinking about a helper method, you can implement a method on the decorator\ninstead.\n\nLet's look at how you could convert an existing Rails helper to a decorator\nmethod. You have this existing helper:\n\n```ruby\n# app/helpers/articles_helper.rb\ndef publication_status(article)\n  if article.published?\n    \"Published at #{article.published_at.strftime('%A, %B %e')}\"\n  else\n    \"Unpublished\"\n  end\nend\n```\n\nBut it makes you a little uncomfortable. `publication_status` lives in a\nnebulous namespace spread across all controllers and view. Down the road, you\nmight want to display the publication status of a `Book`. And, of course, your\ndesign calls for a slightly different formatting to the date for a `Book`.\n\nNow your helper method can either switch based on the input class type (poor\nRuby style), or you break it out into two methods, `book_publication_status` and\n`article_publication_status`. And keep adding methods for each publication\ntype...to the global helper namespace. And you'll have to remember all the names. Ick.\n\nRuby thrives when we use Object-Oriented style. If you didn't know Rails'\nhelpers existed, you'd probably imagine that your view template could feature\nsomething like this:\n\n```erb\n\u003c%= @article.publication_status %\u003e\n```\n\nWithout a decorator, you'd have to implement the `publication_status` method in\nthe `Article` model. That method is presentation-centric, and thus does not\nbelong in a model.\n\nInstead, you implement a decorator:\n\n```ruby\n# app/decorators/article_decorator.rb\nclass ArticleDecorator \u003c Draper::Decorator\n  delegate_all\n\n  def publication_status\n    if published?\n      \"Published at #{published_at}\"\n    else\n      \"Unpublished\"\n    end\n  end\n\n  def published_at\n    object.published_at.strftime(\"%A, %B %e\")\n  end\nend\n```\n\nWithin the `publication_status` method we use the `published?` method. Where\ndoes that come from? It's a method of the  source `Article`, whose methods have\nbeen made available on the decorator by the `delegate_all` call above.\n\nYou might have heard this sort of decorator called a \"presenter\", an \"exhibit\",\na \"view model\", or even just a \"view\" (in that nomenclature, what Rails calls\n\"views\" are actually \"templates\"). Whatever you call it, it's a great way to\nreplace procedural helpers like the one above with \"real\" object-oriented\nprogramming.\n\nDecorators are the ideal place to:\n* format complex data for user display\n* define commonly-used representations of an object, like a `name` method that\n  combines `first_name` and `last_name` attributes\n* mark up attributes with a little semantic HTML, like turning a `url` field\n  into a hyperlink\n\n## Installation\n\nAs of version 4.0.0, Draper only officially supports Rails 5.2 / Ruby 2.4 and later. Add Draper to your Gemfile.\n\n```ruby\n  gem 'draper'\n```\n\nAfter that, run `bundle install` within your app's directory.\n\nIf you're upgrading from a 0.x release, the major changes are outlined [in the\nwiki](https://github.com/drapergem/draper/wiki/Upgrading-to-1.0).\n\n## Writing Decorators\n\nDecorators inherit from `Draper::Decorator`, live in your `app/decorators`\ndirectory, and are named for the model that they decorate:\n\n```ruby\n# app/decorators/article_decorator.rb\nclass ArticleDecorator \u003c Draper::Decorator\n# ...\nend\n```\n\n\nTo decorate a model in a namespace e.g. `Admin::Catalogue` place the decorator under the\ndirectory `app/decorators/admin` in the same way you would with views and models.\n\n```ruby\n# app/decorators/admin/catalogue_decorator.rb\nclass Admin::CatalogueDecorator \u003c Draper::Decorator\n# ...\nend\n```\n\n### Generators\n\nTo create an `ApplicationDecorator` that all generated decorators inherit from, run...\n\n```\nrails generate draper:install\n```\n\nWhen you have Draper installed and generate a controller...\n\n```\nrails generate resource Article\n```\n\n...you'll get a decorator for free!\n\nBut if the `Article` model already exists, you can run...\n\n```\nrails generate decorator Article\n```\n\n...to create the `ArticleDecorator`.\n\nIf you don't want Rails to generate decorator files when generating a new controller,\nyou can add the following configuration to your `config/application.rb` file:\n\n```ruby\nconfig.generators do |g|\n  g.decorator false\nend\n```\n\n### Accessing Helpers\n\nNormal Rails helpers are still useful for lots of tasks. Both Rails' provided\nhelpers and those defined in your app can be accessed within a decorator via the `h` method:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  def emphatic\n    h.content_tag(:strong, \"Awesome\")\n  end\nend\n```\n\nIf writing `h.` frequently is getting you down, you can add...\n\n```\ninclude Draper::LazyHelpers\n```\n\n...at the top of your decorator class - you'll mix in a bazillion methods and\nnever have to type `h.` again.\n\n(*Note*: the `capture` method is only available through `h` or `helpers`)\n\n### Accessing the model\n\nWhen writing decorator methods you'll usually need to access the wrapped model.\nWhile you may choose to use delegation ([covered below](#delegating-methods))\nfor convenience, you can always use the `object` (or its alias `model`):\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  def published_at\n    object.published_at.strftime(\"%A, %B %e\")\n  end\nend\n```\n\n## Decorating Objects\n\n### Single Objects\n\nOk, so you've written a sweet decorator, now you're going to want to put it into\naction! A simple option is to call the `decorate` method on your model:\n\n```ruby\n@article = Article.first.decorate\n```\n\nThis infers the decorator from the object being decorated. If you want more\ncontrol - say you want to decorate a `Widget` with a more general\n`ProductDecorator` - then you can instantiate a decorator directly:\n\n```ruby\n@widget = ProductDecorator.new(Widget.first)\n# or, equivalently\n@widget = ProductDecorator.decorate(Widget.first)\n```\n\n### Collections\n\n#### Decorating Individual Elements\n\nIf you have a collection of objects, you can decorate them all in one fell\nswoop:\n\n```ruby\n@articles = ArticleDecorator.decorate_collection(Article.all)\n```\n\nIf your collection is an ActiveRecord query, you can use this:\n\n```ruby\n@articles = Article.popular.decorate\n```\n\n*Note:* In Rails 3, the `.all` method returns an array and not a query. Thus you\n_cannot_ use the technique of `Article.all.decorate` in Rails 3. In Rails 4,\n`.all` returns a query so this techique would work fine.\n\n#### Decorating the Collection Itself\n\nIf you want to add methods to your decorated collection (for example, for\npagination), you can subclass `Draper::CollectionDecorator`:\n\n```ruby\n# app/decorators/articles_decorator.rb\nclass ArticlesDecorator \u003c Draper::CollectionDecorator\n  def page_number\n    42\n  end\nend\n\n# elsewhere...\n@articles = ArticlesDecorator.new(Article.all)\n# or, equivalently\n@articles = ArticlesDecorator.decorate(Article.all)\n```\n\nDraper decorates each item by calling the `decorate` method. Alternatively, you can\nspecify a decorator by overriding the collection decorator's `decorator_class`\nmethod, or by passing the `:with` option to the constructor.\n\n#### Using pagination\n\nSome pagination gems add methods to `ActiveRecord::Relation`. For example,\n[Kaminari](https://github.com/amatsuda/kaminari)'s `paginate` helper method\nrequires the collection to implement `current_page`, `total_pages`, and\n`limit_value`. To expose these on a collection decorator, you can delegate to\nthe `object`:\n\n```ruby\nclass PaginatingDecorator \u003c Draper::CollectionDecorator\n  delegate :current_page, :total_pages, :limit_value, :entry_name, :total_count, :offset_value, :last_page?\nend\n```\n\nThe `delegate` method used here is the same as that added by [Active\nSupport](http://api.rubyonrails.org/classes/Module.html#method-i-delegate),\nexcept that the `:to` option is not required; it defaults to `:object` when\nomitted.\n\n[will_paginate](https://github.com/mislav/will_paginate) needs the following delegations:\n\n```ruby\ndelegate :current_page, :per_page, :offset, :total_entries, :total_pages\n```\n\nIf needed, you can then set the collection_decorator_class of your CustomDecorator as follows:\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  def self.collection_decorator_class\n    PaginatingDecorator\n  end\nend\n\nArticleDecorator.decorate_collection(@articles.paginate)\n# =\u003e Collection decorated by PaginatingDecorator\n# =\u003e Members decorated by ArticleDecorator\n```\n\n### Decorating Associated Objects\n\nYou can automatically decorate associated models when the primary model is\ndecorated. Assuming an `Article` model has an associated `Author` object:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_association :author\nend\n```\n\nWhen `ArticleDecorator` decorates an `Article`, it will also use\n`AuthorDecorator` to decorate the associated `Author`.\n\n### Decorated Finders\n\nYou can call `decorates_finders` in a decorator...\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_finders\nend\n```\n\n...which allows you to then call all the normal ActiveRecord-style finders on\nyour `ArticleDecorator` and they'll return decorated objects:\n\n```ruby\n@article = ArticleDecorator.find(params[:id])\n```\n\n### Decorated Query Methods\nBy default, Draper will decorate all [QueryMethods](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html)\nof ActiveRecord.\nIf you're using another ORM, in order to support it, you can tell Draper to use a custom strategy:\n\n```ruby\nDraper.configure do |config|\n  config.default_query_methods_strategy = :mongoid\nend\n```\n\n### When to Decorate Objects\n\nDecorators are supposed to behave very much like the models they decorate, and\nfor that reason it is very tempting to just decorate your objects at the start\nof your controller action and then use the decorators throughout. *Don't*.\n\nBecause decorators are designed to be consumed by the view, you should only be\naccessing them there. Manipulate your models to get things ready, then decorate\nat the last minute, right before you render the view. This avoids many of the\ncommon pitfalls that arise from attempting to modify decorators (in particular,\ncollection decorators) after creating them.\n\nTo help you make your decorators read-only, we have the `decorates_assigned`\nmethod in your controller. It adds a helper method that returns the decorated\nversion of an instance variable:\n\n```ruby\n# app/controllers/articles_controller.rb\nclass ArticlesController \u003c ApplicationController\n  decorates_assigned :article\n\n  def show\n    @article = Article.find(params[:id])\n  end\nend\n```\n\nThe `decorates_assigned :article` bit is roughly equivalent to\n\n```ruby\ndef article\n  @decorated_article ||= @article.decorate\nend\nhelper_method :article\n```\n\nThis means that you can just replace `@article` with `article` in your views and\nyou'll have access to an ArticleDecorator object instead. In your controller you\ncan continue to use the `@article` instance variable to manipulate the model -\nfor example, `@article.comments.build` to add a new blank comment for a form.\n\n## Configuration\nDraper works out the box well, but also provides a hook for you to configure its\ndefault functionality. For example, Draper assumes you have a base `ApplicationController`.\nIf your base controller is named something different (e.g. `BaseController`),\nyou can tell Draper to use it by adding the following to an initializer:\n\n```ruby\nDraper.configure do |config|\n  config.default_controller = BaseController\nend\n```\n\n## Testing\n\nDraper supports RSpec, MiniTest::Rails, and Test::Unit, and will add the\nappropriate tests when you generate a decorator.\n\n### RSpec\n\nYour specs are expected to live in `spec/decorators`. If you use a different\npath, you need to tag them with `type: :decorator`.\n\nIn a controller spec, you might want to check whether your instance variables\nare being decorated properly. You can use the handy predicate matchers:\n\n```ruby\nassigns(:article).should be_decorated\n\n# or, if you want to be more specific\nassigns(:article).should be_decorated_with ArticleDecorator\n```\n\nNote that `model.decorate == model`, so your existing specs shouldn't break when\nyou add the decoration.\n\n#### Spork Users\n\nIn your `Spork.prefork` block of `spec_helper.rb`, add this:\n\n```ruby\nrequire 'draper/test/rspec_integration'\n```\n\n#### Custom Draper Controller ViewContext\nIf running tests in an engine setting with a controller other than \"ApplicationController,\" set a custom controller in `spec_helper.rb`\n\n```ruby\nconfig.before(:each, type: :decorator) do |example|\n  Draper::ViewContext.controller = ExampleEngine::CustomRootController.new\nend\n```\n\n### Isolated Tests\n\nIn tests, Draper needs to build a view context to access helper methods. By\ndefault, it will create an `ApplicationController` and then use its view\ncontext. If you are speeding up your test suite by testing each component in\nisolation, you can eliminate this dependency by putting the following in your\n`spec_helper` or similar:\n\n```ruby\nDraper::ViewContext.test_strategy :fast\n```\n\nIn doing so, your decorators will no longer have access to your application's\nhelpers. If you need to selectively include such helpers, you can pass a block:\n\n```ruby\nDraper::ViewContext.test_strategy :fast do\n  include ApplicationHelper\nend\n```\n\n#### Stubbing Route Helper Functions\n\nIf you are writing isolated tests for Draper methods that call route helper\nmethods, you can stub them instead of needing to require Rails.\n\nIf you are using RSpec, minitest-rails, or the Test::Unit syntax of minitest,\nyou already have access to the Draper `helpers` in your tests since they\ninherit from `Draper::TestCase`. If you are using minitest's spec syntax\nwithout minitest-rails, you can explicitly include the Draper `helpers`:\n\n```ruby\ndescribe YourDecorator do\n  include Draper::ViewHelpers\nend\n```\n\nThen you can stub the specific route helper functions you need using your\npreferred stubbing technique. This examples uses Rspec currently recommended API\navailable in RSpec 3.6+\n\n```ruby\nwithout_partial_double_verification do\n  allow(helpers).to receive(:users_path).and_return('/users')\nend\n```\n\n### View context leakage\nAs mentioned before, Draper needs to build a view context to access helper methods. In MiniTest, the view context is\ncleared during `before_setup` preventing any view context leakage. In RSpec, the view context is cleared before each\n`decorator`, `controller`, and `mailer` spec. However, if you use decorators in other types of specs\n(e.g. `job`), you may still experience the view context leaking from the previous spec. To solve this, add the\nfollowing to your `spec_helper` for each type of spec you are experiencing the leakage:\n\n```ruby\nconfig.before(:each, type: :type) { Draper::ViewContext.clear! }\n```\n\n_Note_: The `:type` above is just a placeholder. Replace `:type` with the type of spec you are experiencing\nthe leakage from.\n\n## Advanced usage\n\n### Shared Decorator Methods\n\nYou might have several decorators that share similar needs. Since decorators are\njust Ruby objects, you can use any normal Ruby technique for sharing\nfunctionality.\n\nIn Rails controllers, common functionality is organized by having all\ncontrollers inherit from `ApplicationController`. You can apply this same\npattern to your decorators:\n\n```ruby\n# app/decorators/application_decorator.rb\nclass ApplicationDecorator \u003c Draper::Decorator\n# ...\nend\n```\n\nThen modify your decorators to inherit from that `ApplicationDecorator` instead\nof directly from `Draper::Decorator`:\n\n```ruby\nclass ArticleDecorator \u003c ApplicationDecorator\n  # decorator methods\nend\n```\n\n### Delegating Methods\n\nWhen your decorator calls `delegate_all`, any method called on the decorator not\ndefined in the decorator itself will be delegated to the decorated object. This\nincludes calling `super` from within the decorator. A call to `super` from within\nthe decorator will first try to call the method on the parent decorator class. If\nthe method does not exist on the parent decorator class, it will then try to call\nthe method on the decorated `object`. This is a very permissive interface.\n\nIf you want to strictly control which methods are called within views, you can\nchoose to only delegate certain methods from the decorator to the source model:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  delegate :title, :body\nend\n```\n\nWe omit the `:to` argument here as it defaults to the `object` being decorated.\nYou could choose to delegate methods to other places like this:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  delegate :title, :body\n  delegate :name, :title, to: :author, prefix: true\nend\n```\n\nFrom your view template, assuming `@article` is decorated, you could do any of\nthe following:\n\n```ruby\n@article.title # Returns the article's `.title`\n@article.body  # Returns the article's `.body`\n@article.author_name  # Returns the article's `author.name`\n@article.author_title # Returns the article's `author.title`\n```\n\n### Adding Context\n\nIf you need to pass extra data to your decorators, you can use a `context` hash.\nMethods that create decorators take it as an option, for example:\n\n```ruby\nArticle.first.decorate(context: {role: :admin})\n```\n\nThe value passed to the `:context` option is then available in the decorator\nthrough the `context` method.\n\nIf you use `decorates_association`, the context of the parent decorator is\npassed to the associated decorators. You can override this with the `:context`\noption:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_association :author, context: {foo: \"bar\"}\nend\n```\n\nor, if you want to modify the parent's context, use a lambda that takes a hash\nand returns a new hash:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_association :author,\n    context: -\u003e(parent_context){ parent_context.merge(foo: \"bar\") }\nend\n```\n\n### Specifying Decorators\n\nWhen you're using `decorates_association`, Draper uses the `decorate` method on\nthe associated record(s) to perform the decoration. If you want use a specific\ndecorator, you can use the `:with` option:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_association :author, with: FancyPersonDecorator\nend\n```\n\nFor a collection association, you can specify a `CollectionDecorator` subclass,\nwhich is applied to the whole collection, or a singular `Decorator` subclass,\nwhich is applied to each item individually.\n\n### Scoping Associations\n\nIf you want your decorated association to be ordered, limited, or otherwise\nscoped, you can pass a `:scope` option to `decorates_association`, which will be\napplied to the collection *before* decoration:\n\n```ruby\nclass ArticleDecorator \u003c Draper::Decorator\n  decorates_association :comments, scope: :recent\nend\n```\n\n### Proxying Class Methods\n\nIf you want to proxy class methods to the wrapped model class, including when\nusing `decorates_finders`, Draper needs to know the model class. By default, it\nassumes that your decorators are named `SomeModelDecorator`, and then attempts\nto proxy unknown class methods to `SomeModel`.\n\nIf your model name can't be inferred from your decorator name in this way, you\nneed to use the `decorates` method:\n\n```ruby\nclass MySpecialArticleDecorator \u003c Draper::Decorator\n  decorates :article\nend\n```\n\nThis is only necessary when proxying class methods.\n\nOnce this association between the decorator and the model is set up, you can call\n`SomeModel.decorator_class` to access class methods defined in the decorator.\nIf necessary, you can check if your model is decorated with `SomeModel.decorator_class?`.\n\n### Making Models Decoratable\n\nModels get their `decorate` method from the `Draper::Decoratable` module, which\nis included in `ActiveRecord::Base` and `Mongoid::Document` by default. If\nyou're using another ORM, or want to decorate plain old Ruby objects,\nyou can include this module manually.\n\n### Active Job Integration\n\n[Active Job](http://edgeguides.rubyonrails.org/active_job_basics.html) allows you to pass ActiveRecord\nobjects to background tasks directly and performs the necessary serialization and deserialization. In\norder to do this, arguments to a background job must implement [Global ID](https://github.com/rails/globalid).\nDecorators implement Global ID.\nThis means you can pass decorated objects to background jobs, and get them just as decorated when deserialized.\n\n## Contributors\n\nDraper was conceived by Jeff Casimir and heavily refined by Steve Klabnik and a\ngreat community of open source\n[contributors](https://github.com/drapergem/draper/contributors).\n\n### Current maintainers\n\n* Alexander Senko (Alexander.Senko@gmail.com)\n* Yuji Yaginuma (yuuji.yaginuma@gmail.com)\n\n### Historical maintainers\n\n* Jeff Casimir (jeff@jumpstartlab.com)\n* Steve Klabnik (steve@jumpstartlab.com)\n* Vasiliy Ermolovich\n* Andrew Haines\n* Sean Linsley\n* Cliff Braton (cliff.braton@gmail.com)\n","funding_links":[],"categories":["Ruby","Decorators","Views and related","Gems"],"sub_categories":["Articles"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdrapergem%2Fdraper","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdrapergem%2Fdraper","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdrapergem%2Fdraper/lists"}