<commit_before># ActiveRecord::Scoping::WithState

So small, it's almost silly - but it is kinda helpful.

I've found that when developing Rails apps, I tend to almost always pair each
scope with an instance method which returns a boolean indicating whether the
object is included inside that scope.

This gem simply automatically creates that method for you. Nothing super fancy,
and you might consider replacing the state methods with your own, more
efficient, implementations - but it's great for early stages of development, or
providing a comparative case for unit tests.


## Example

Using a small `Event` model:

```ruby
class Event < ActiveRecord::Base
  include ActiveRecord::Scoping::WithState
  scope :upcoming, -> { where ("starts_at > ?", Time.now) }
end
```

```ruby
old_event = Event.create(:starts_at => 1.day.ago)
upcoming_event = Event.create(:starts_at => 1.day.from_now)

old_event.upcoming? # => false
upcoming_event.upcoming? # => true
```


## Installation

Add this line to your application's Gemfile:

    gem 'active_record-scoping-with_state'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install active_record-scoping-with_state


## Usage

The gem automatically aliases the existing `scope` method provided by
ActiveRecord, so all of your models will have the new state methods by default.

The helper methods will have the same name as your scopes, with a `?` appended.

Eg:

`scope :upcoming, -> { ... }` will generate `.upcoming?`  
and  
`scope :spam -> { ... }` will generate `.spam?`

You get the picture.


## Configuration

You can turn off the automatic aliasing of `scope`, and explicitly call
`scope_with_state` instead, for each scope that you'd like to have generated
state method for. To do that, add the following initializer:

```ruby
# config/initializers/active_record-scoping-with_state.rb
ActiveRecord::Scoping::WithState.configure do |config|
  config.alias_scope_method = false
end
```


## Caveats

It should be noted that the instance methods do use a database query in order
to establish a model instance's state. Arguably not ideal, however the query is
as efficient as possible (I think?).

If you have performance concerns, I would recommend overriding the generated
state methods for production use. In this case, this gem can still be used
in test cases by calling `.has_scoped_state(scope_name)` on your model instances.
In this way, you can help validate that your overridden state methods are
congruent to the conditions in your scope.

Using the above `Event` model again, however the `upcoming?` method has been
overridden with:

```ruby
# app/models/event.rb

def upcoming?
  self.starts_at > Time.now
end<commit_msg>Updated readme to reflect name changes<commit_after># Scoping::WithState

An ActiveRecord extension so small, it's almost silly - but it is kinda helpful.

I've found that when developing Rails apps, I tend to almost always pair each
scope with an instance method which returns a boolean indicating whether the
object is included inside that scope.

This gem simply automatically creates that method for you. Nothing super fancy,
and you might consider replacing the state methods with your own, more
efficient, implementations - but it's great for early stages of development, or
providing a comparative case for unit tests.


## Example

Using a small `Event` model:

```ruby
class Event < ActiveRecord::Base
  include Scoping::WithState
  scope :upcoming, -> { where ("starts_at > ?", Time.now) }
end
```

```ruby
old_event = Event.create(:starts_at => 1.day.ago)
upcoming_event = Event.create(:starts_at => 1.day.from_now)

old_event.upcoming? # => false
upcoming_event.upcoming? # => true
```


## Installation

Add this line to your application's Gemfile:

    gem 'active_record-scoping-with_state'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install active_record-scoping-with_state


## Usage

The gem automatically aliases the existing `scope` method provided by
ActiveRecord, so all of your models will have the new state methods by default.

The helper methods will have the same name as your scopes, with a `?` appended.

Eg:

`scope :upcoming, -> { ... }` will generate `.upcoming?`  
and  
`scope :spam -> { ... }` will generate `.spam?`

You get the picture.

If you're wanting to avoid the automatically generated state methods on a given
scope, you can simply use `scope_without_state` instead of `scope`.


## Configuration

You can turn off the automatic aliasing of `scope`, and explicitly call
`scope_with_state` instead, for each scope that you'd like to have generated
state method for. To do that, add the following initializer:

```ruby
# config/initializers/active_record-scoping-with_state.rb
Scoping::WithState.configure do |config|
  config.alias_scope_method = false
end
```


## Caveats

It should be noted that the instance methods do use a database query in order
to establish a model instance's state. Arguably not ideal, however the query is
as efficient as possible (I think?).

If you have performance concerns, I would recommend overriding the generated
state methods for production use. In this case, this gem can still be used
in test cases by calling `.has_scoped_state(scope_name)` on your model instances.
In this way, you can help validate that your overridden state methods are
congruent to the conditions in your scope.

Using the above `Event` model again, however the `upcoming?` method has been
overridden with:

```ruby
# app/models/event.rb

def upcoming?
  self.starts_at > Time.now
end
{'fraction_non_alphanumeric': 0.07765423242467719, 'fraction_numerical': 0.0007173601147776184, 'mean_word_length': 4.462291870714985, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 21, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2288369', 'n_tokens_mistral': 1604, 'n_tokens_neox': 1528, 'n_words': 719}