Welcome to Part 3 of “How we Redux”! I’m your host Abhi Aiyer, and today we have on the show: Domain State Logic.

If you haven't read Part 1 or 2 you can find them:

Alright, let’s get this show started. Today we’re going to build all the Meteor related pieces of our Todo App and give you your first taste of some Redux philosophy.

First things, first

We need to store our Todos somewhere. Good thing we can create collections in Meteor, backed by MongoDB.

Voila! There you go. A todos collection with reference to the Todos namespace on both client and server.

Publications

Next we’ll make some publications for our Todo App to subscribe on the client. If you want to step through a “History of Data Management”, check out my blog post about that here and read about Pub/Sub here. Credit to Sacha Greif for that amazing post. Our publications need to handle 2 things. The current filter of todos and the current page “skip”. Since we’re using MongoDB we need to use skip values to paginate our collections.

So let’s break this publication down. We’re publishing our Todos based on a filter value from the client. Let’s clean up this publication a bit:

This last thing we need to do is publish the total count of Todos we have to wrap up our architecture for a paginated Todo list. We’ll add the Publish Counts package to achieve this:

meteor add tmeasday:publish-counts

This allows us to publish cursors to the client to hold the count for the total number of Todos we have based on the query not limited by the “limit” param on our Mongo find.

Now on the client we can grab the count of todos via:

Counts.get('TodoCount');

Method Time

Okay, let’s make some Meteor Methods. I’m going to preach against allow/deny rules and say Methods in a Redux-Meteor implementation are the only way to interact with the server.

Meteor methods are not PURE because they mutate the state of the database, so we keep this state managed via Meteor’s DDP and Minimongo relationship. I would start considering these as “Side Effect” actions and treat them as you would some asynchronous call you make in Redux. We’ll come back to this when we hook up our Redux-related goods to Meteor.

We’ll make 2 Methods. One for adding todos and one for toggling them “completed” or not.

The first method addTodo is pretty simple. We’ll take text from the client input and insert it into our Todos collection. If you need the response of the method to have data, return the todos like I have above to get the _id of that item in the response.

The second method is the toggleTodo. We find the todo we’re updating, see what the state of completion is and inverse it. With a simple update, boom, our item is complete or incomplete.

Expose the methods through ActionCreators

Now that we have a way to interface with our server, let’s expose this by writing some actions our UI can take. Now what I’m about to describe to you is called the ActionCreator pattern in Redux. The ActionCreator belongs to the layer that separates your UI Visuals from your UI business logic. I call this layer the “Action Layer”, and this is the only place you write business logic on the client. As our application matures, we don’t know where our front end decisions may go. Using React may be an afterthought and the latest and greatest is out and about. Having an architecture like this decoupled from your view allows your business logic to be reused as the visuals change on your website. Remember, Redux is an architectural pattern with a library to enforce it.

Let’s write 2 Actions to represent our meteor methods, or “Side Effect” actions. To accomplish this, we’ll be using the ‘redux-thunk’. What is the thunkMiddleware?

Redux Thunk allows you to write action creators that return a function instead of an action. The function you dispatch inner function receives the store methods dispatch and getState() as parameters. — Dan Abramov

We have written two ActionCreator functions that will take some inputs from the UI calling them and return a function to the Store’s dispatch method. This function we return will deal with the side-effects executed in the system. In traditional Redux, this would be used to make AJAX calls and handle other functions that may mutate the state. More on Thunk later when we tackle the Store and component level tasks.

Conclusion

Stop what you’re doing and go read about actions.

Redux Thunk: https://github.com/gaearon/redux-thunk

Actions: http://rackt.org/redux/docs/basics/Actions.html

Flux Actions: https://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

I can’t stress to you how much, that when it comes to Flux and Meteor, ACTIONS ARE EVERYTHING. Actions are powerful. Actions are how we get the job done. I could devote a whole post just on how Actions are amazing…but do your homework and I’ll see you in Part 4.

If you like this series, recommend it to your friends! Follow me on twitter: @abhiaiyer

Getting into React? Check out my post on JSX here.

Part 4: https://medium.com/modern-user-interfaces/how-we-redux-part-4-reducers-and-stores-f4a0ebcdc22a