README.md in draper-3.0.1 vs README.md in draper-3.1.0

@@ -324,10 +324,21 @@
 
 ```ruby
 @article = ArticleDecorator.find(params[:id])
 ```
 
+### Decorated Query Methods
+By default, Draper will decorate all [QueryMethods](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html)
+of ActiveRecord.
+If you're using another ORM, in order to support it, you can tell Draper to use a custom strategy:
+
+```ruby
+Draper.configure do |config|
+  config.default_query_methods_strategy = :mongoid
+end
+```
+
 ### When to Decorate Objects
 
 Decorators are supposed to behave very much like the models they decorate, and
 for that reason it is very tempting to just decorate your objects at the start
 of your controller action and then use the decorators throughout. *Don't*.
@@ -460,9 +471,23 @@
 preferred stubbing technique (this example uses RSpec's `stub` method):
 
 ```ruby
 helpers.stub(users_path: '/users')
 ```
+
+### View context leakage
+As mentioned before, Draper needs to build a view context to access helper methods. In MiniTest, the view context is
+cleared during `before_setup` preventing any view context leakage. In RSpec, the view context is cleared before each
+`decorator`, `controller`, and `mailer` spec. However, if you use decorators in other types of specs
+(e.g. `job`), you may still experience the view context leaking from the previous spec. To solve this, add the
+following to your `spec_helper` for each type of spec you are experiencing the leakage:
+
+```ruby
+config.before(:each, type: :type) { Draper::ViewContext.clear! }
+```
+
+_Note_: The `:type` above is just a placeholder. Replace `:type` with the type of spec you are experiencing
+the leakage from.
 
 ## Advanced usage
 
 ### Shared Decorator Methods