Merge pull request #96 from juukie/patch-1

Typo’s, spelling corrections, indent fixes and such

docs/advanced-usage/adding-and-removing-projectors-and-reactors.md

@@ -15,7 +15,7 @@ Adding one projector:
 Projectionist::addProjector(TransactionCountProjector::class);
 ```
 
-Adding many projectors:
+Adding multiple projectors:
 
 ```php
 Projectionist::addProjector([
@@ -32,7 +32,7 @@ Adding one reactor:
 Projectionist::addReactor(SendMailReactor::class);
 ```
 
-Adding many reactors:
+Adding multiple reactors:
 
 ```php
 Projectionist::addReactor([
@@ -51,7 +51,7 @@ Removing one event handler:
 Projectionist::withoutEventHandler(SendPushNotificationReactor::class);
 ```
 
-Removing many event handlers:
+Removing multiple event handlers:
 
 ```php
 Projectionist::withoutEventHandlers([

docs/advanced-usage/discovering-projectors-and-reactors.md

@@ -11,8 +11,8 @@ If you want to see a list of the discovered projectors and reactors perform the
 
 ## Caching discovered projectors and reactors
 
-In production, you likely do not want the package to scan all of your classes on every request. Therefore, during your deployment process, you should run the `event-sourcing:cache-event-handlers` Artisan command to cache a manifest of all of your application's projectors and reactors. This manifest will be used by the package to speed up the registration process. The `event-sourcing:clear-event-handlers` command may be used to destroy the cache.
+In production, you likely do not want the package to scan all of your classes on every request. Therefore, during your deployment process, you should run the `event-sourcing:cache-event-handlers` Artisan command to cache a manifest of all of your application's projectors and reactors. This manifest will be used by the package to speed up the registration process. The `event-sourcing:clear-event-handlers` command may be used to remove the manifest.
 
 ## Disabling discovery
 
-If you want to turn off auto-discovery and want to enforce manually registration of projectors and reactors, just set the `auto_discover_projectors_and_reactors` key in the `event-sourcing` config file to an empty array.
+If you want to turn off auto-discovery to enforce manually registration of projectors and reactors, just set the `auto_discover_projectors_and_reactors` key in the `event-sourcing` config file to an empty array.

docs/advanced-usage/handling-exceptions.md

@@ -5,7 +5,7 @@ weight: 4
 
 The `event-sourcing` config file has a key, `catch_exceptions`, that determines what will happen should a projector or reactor throw an exception. If this setting is set to `false`, exceptions will not be caught and your app will come to a grinding halt.
 
-If `catch_exceptions` is set to `true`, and an projector or reactor throws an exception, all other projectors and reactors will still get called. The `Projectionist` will catch all exceptions and fire the `EventHandlerFailedHandlingEvent`. That event contains these public properties:
+If `catch_exceptions` is set to `true`, and a projector or reactor throws an exception, all other projectors and reactors will still get called. The `Projectionist` will catch all exceptions and fire the `EventHandlerFailedHandlingEvent`. That event contains these public properties:
 
 - `eventHandler`: The projector or reactor that could not handle the event.
 - `storedEvent`: The instance of `Spatie\EventSourcing\Models\StoredEvent` that could not be handled.

docs/advanced-usage/storing-metadata.md

@@ -20,9 +20,9 @@ class CustomStoredEvent extends EloquentStoredEvent
     {
         parent::boot();
 
-         static::creating(function(CustomStoredEvent $storedEvent) {
-             $storedEvent->meta_data['user_id'] = auth()->user()->id;
-         });
+        static::creating(function(CustomStoredEvent $storedEvent) {
+            $storedEvent->meta_data['user_id'] = auth()->user()->id;
+        });
     }
 }
 ```
@@ -57,9 +57,9 @@ class MetaDataProjector implements Projector
     public function onMoneyAdded(StoredEvent $storedEvent, StoredEventRepository $repository)
     {
         if (! Projectionist::isReplaying()) {
-           $storedEvent->meta_data['user_id'] = auth()->user()->id;
+            $storedEvent->meta_data['user_id'] = auth()->user()->id;
 
-           $repository->update($storedEvent);
+            $repository->update($storedEvent);
         }
 
         // ...

docs/advanced-usage/using-aliases-for-stored-event-classes.md

@@ -18,4 +18,4 @@ To get around this you can define event class aliases in the `event-sourcing.php
     ],
 ```
 
-With this configuration, instead of saving `\App\Events\MoneyAddedEvent` in the database, we just store `money_added`, now you can change the event class name and namespace. Just make sure to also change the mapping!
+With this configuration, instead of saving `\App\Events\MoneyAddedEvent` in the database, it just stores `money_added` so you can change the event's classname and namespace. Just make sure to also change the mapping!

docs/using-aggregates/writing-your-first-aggregate.md

@@ -30,36 +30,48 @@ class AccountAggregate extends AggregateRoot
 
 You can add any methods or variables you need on the aggregate. To get you familiar with event modelling using aggregates let's implement a small piece of [the Larabank example app](https://github.com/spatie/larabank-aggregates). We are going to add methods to record the [`AccountCreated`](https://github.com/spatie/larabank-aggregates/blob/master/app/Domain/Account/Events/AccountCreated.php), [`MoneyAdded`](https://github.com/spatie/larabank-aggregates/blob/master/app/Domain/Account/Events/MoneyAdded.php) and the [`MoneySubtracted`](https://github.com/spatie/larabank-aggregates/blob/master/app/Domain/Account/Events/MoneySubtracted.php) events.
 
-First, let's add a `createAccount` methods to our aggregate that will record the `AccountCreated` event.
+First, let's add a `createAccount` method to our aggregate that will record the `AccountCreated` event.
 
 ```php
 namespace App\Aggregates;
 
 use Spatie\EventSourcing\AggregateRoot;
 
-
 class AccountAggregate extends AggregateRoot
 {
     public function createAccount(string $name, string $userId)
     {
         $this->recordThat(new AccountCreated($name, $userId));
+
+        return $this;
     }
 
     public function addMoney(int $amount)
     {
         $this->recordThat(new MoneyAdded($amount));
+
+        return $this;
     }
 
     public function subtractAmount(int $amount)
     {
         $this->recordThat(new MoneySubtracted($amount));
+
+        return $this;
+    }
+
+    public function deleteAccount()
+    {
+        $this->recordThat(new AccountDeleted());
+
+        return $this;
     }
 }
 ```
 
 The `recordThat` function will not persist the events to the database. It will simply hold them in memory. The events will get written to the database when the aggregate itself is persisted.
 
-There are two things to notice. First, the method name is written in the present tense, not the past tense. We're trying to do something, and for the rest of our application is hasn't happened yet until the actual `AccountCreated` is saved. This will only happen when the `AccountAggregate` gets persisted.
+There are two things to notice. First, the method names are written in the present tense, not the past tense. We're trying to do something, and for the rest of our application is hasn't happened yet until the actual `AccountCreated` is saved. This will only happen when the `AccountAggregate` gets persisted.
 
 The second thing to note is that nor the method and the event contain an uuid. The aggregate itself is aware of the uuid to use because it is passed to the retrieve method (`AccountAggregate::retrieve($uuid)`, we'll get to this in a bit). When persisting the aggregateroot, it will save the recorded events along with the uuid.
 

docs/using-projectors/writing-your-first-projector.md

@@ -348,7 +348,7 @@ Projectionist::addProjector(TransactionCountProjector::class);
 If you've followed along, you've already created some accounts and some events. To feed those past events to the projector we can simply perform this artisan command:
 
 ```php
-php artisan event-sourcing:replay
+php artisan event-sourcing:replay App\\Projectors\\TransactionCountProjector
 ```
 
 This command will take all events stored in the `stored_events` table and pass them to `TransactionCountProjector`. After the command completes you should see the transaction counts in the `transaction_counts` table.

docs/using-reactors/creating-and-configuring-reactors.md

@@ -64,7 +64,7 @@ Just by adding a typehint of the event you want to handle makes our package call
 
 ## Getting the uuid of an event
 
-In most cases you want to have access to the event that was fired. When [using aggregates]() your events probably won't contain the uuid associated with that event. To get to the uuid of an event simply add a parameter called `$aggregateUuid` that typehinted as a string. 
+In most cases you want to have access to the event that was fired. When using aggregates your events probably won't contain the uuid associated with that event. To get to the uuid of an event simply add a parameter called `$aggregateUuid` that typehinted as a string. 
 
 ```php
 // ...

src/AggregateRoot.php

@@ -150,7 +150,7 @@ protected function ensureNoOtherEventsHaveBeenPersisted(): void
                 $this->uuid,
                 $this->aggregateVersionAfterReconstitution,
                 $latestPersistedVersionId,
-                );
+            );
         }
     }