Skip to content

Commit

Permalink
Updates documentation per new getListeners
Browse files Browse the repository at this point in the history
  • Loading branch information
ctrlplusb committed Jul 23, 2019
1 parent c9ee9d8 commit 2706d22
Show file tree
Hide file tree
Showing 4 changed files with 19 additions and 15 deletions.
8 changes: 6 additions & 2 deletions website/docs/docs/api/store.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,14 +26,18 @@ A store is created via the [createStore](/docs/api/create-store) API. A store in

Returns the actions of your store.

- `getState` (Function, required)
- `getListeners` (Function)

Returns the state of your store.
Returns the listener actions of your store. Useful if you would like to manually execute a listener for the purpose of testing.

- `getMockedActions` (Function)

If the `mockActions` configuration value was passed to the `createStore` then calling this function will return the actions that have been dispatched (and mocked). This is useful in the context of testing - especially thunks and listeners.

- `getState` (Function, required)

Returns the state of your store.

- `reconfigure` (Function)

Allows you to reconfigure the store by providing a new/updated model. The existing state of the store will be maintained. This is especially useful in supporting hot reloading.
Expand Down
8 changes: 4 additions & 4 deletions website/docs/docs/introduction/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,10 +22,10 @@ Under the hood we use Redux to power the store. 😱

Yes, we have noticed a lot of negative sentiment toward Redux recently. However, we feel that this is usually directed at the boilerplate and configuration that is typical within a Redux application. Discounting the boilerplate, the architectural design of Redux is awesome, providing us with characteristics that fit well into the React paradigm.

Therefore we provide a complete abstraction over Redux, providing an API that is both intuitive and quick to develop against. By wrapping Redux we get to leverage its mature architecture, whilst also being able to support the amazing tooling that has formed around it. For example, we support the [Redux Dev Tools Extension](https://github.com/zalmoxisus/redux-devtools-extension) out of the box.
Easy Peasy is a full abstraction over Redux, providing an API that is both intuitive and quick to develop against, whilst removing any need for boilerplate. By wrapping Redux we get to leverage its mature architecture, whilst also being able to support the amazing tooling that has formed around it. For example, we support the [Redux Dev Tools Extension](https://github.com/zalmoxisus/redux-devtools-extension) out of the box.

We have even taken this further by outputing a Redux store, which would allow you to interop your Easy Peasy created store with existing libraries and applications based on Redux / React Redux. This unlocks a kinder migration path for those currently using React Redux.
In addition to this, as we are outputing a Redux store, this allows interop with existing libraries and applications that are using React Redux. A big benefit of this is that you can apply a gradual migration of your existing applications from React Redux into Easy Peasy.

Finally, for the most advanced use cases, we allow extension of the underlying Redux store via middleware and enhancers - provided via our `createStore` configuration.
To help support migration and interoperability we expose configuration allowing the extension of the underlying Redux store via middleware and enhancers.

That being said, absolutely no Redux experience is required to use Easy Peasy. Once you read through the tutorial you should have all the knowledge and confidence you need to be able to integrate Easy Peasy into your application.
That being said, absolutely no Redux experience is required to use Easy Peasy.
6 changes: 2 additions & 4 deletions website/docs/docs/quick-start.md
Original file line number Diff line number Diff line change
Expand Up @@ -222,8 +222,6 @@ A listener will receive the same payload as was provided to the target being lis

## Closing notes

That concludes the quick start overview of Easy Peasy.
That concludes the quick start overview of Easy Peasy. Whilst this should have provided enough of an overview to immediately begin developing with Easy Peasy we highly recommend that you review the [documentation](/docs/introduction) for a more detailed overview of the APIs.

From here we would recommend either looking at the [live examples](/docs/introduction/examples), the [full tutorial](/docs/tutorial) or the [API docs](/docs/api).

Have fun. 👋
Within the [documentation](/docs/introduction) section you will find detailed tutorials, API docs, TypeScript tutorials, recipes, etc.
12 changes: 7 additions & 5 deletions website/docs/docs/testing/testing-listeners.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,9 +63,11 @@ test('listener gets dispatched when target fires', () => {

## Testing if the listener performs as expected

We may also want to test that our listeners perform the expected. It is possible to dispatch our listeners manually just like we would any other action. However, unlike other actions you will need to provide a specific payload that matches what a listener would expect from its `target` argument.
We may also want to test that our listeners perform the expected. It is possible to dispatch our listeners manually by using the `store.getListeners()` API.

The `target` argument that a *listener* handler receives contains the following properties:
When dispatch a listener action it is important to note that a very specific payload structure is expected. This payload becomes the `target` argument to the listener handler.

Below is an overview of the payload object that you need to provide when manually dispatching a listener action:

- `type` (string)

Expand All @@ -87,12 +89,12 @@ The `target` argument that a *listener* handler receives contains the following

An array containing a list of the resolved targets, resolved by the `targetResolver` function. This aids in performing target based logic within a listener handler.

You need not provide a full `target` argument if you know that your listener only uses parts of it. You could instead only populate the parts of the `target` object that you expect your listener to be using.
You need not provide all the values if you know that your listener only uses some of them. You could instead only populate the parts of the `target` object that you expect your listener to be using.

For example, below we will manually dispatch a listener, providing only the payload.

```javascript
store.getActions().onTodoAdded({
store.getListeners().onTodoAdded({
payload: 'Write docs on testing'
})
```
Expand All @@ -107,7 +109,7 @@ test('onTodoAdded adds a log entry', () => {
const store = createStore(model);

// act
store.getActions().onTodoAdded({
store.getListeners().onTodoAdded({
payload: 'Test listeners',
});

Expand Down

0 comments on commit 2706d22

Please sign in to comment.