Redux vs. Storeon: An App to App Comparison
By: Kris Guzman
Tags: JavaScript, Web Development, Software Development, React, Programming

Actions & Reducers (Redux)

As we saw at the folder level earlier, with Redux we split up our reducers into separate files, then combined them in an index.js file under /reducers , and exported the result to be used by our store.

Let’s take a closer look at how our reducer for counting is setup in Redux:

count.js (Redux reducer for our counting state)

To give you some context, all we basically have are a few actions to increment and decrement the counter, as well as an action to let the UI know when the counter is “loading”.

What does the reducer for Storeon look like?

Well… if I show you, it will spoil everything, so bear with me while I show you the Redux action creators for updating the counter:

async action creators (Redux)

If you are familiar with Thunk middleware, this is nothing special.

We dispatch our “loading” actions called INCREASING and DECREASING . Then we call our fake api (passing in # of seconds to wait), and dispatch our INCREMENT or DECREMENT actions when the promise resolves. Then we call an action called LOG_HISTORY , which we’ll take a look at soon.

If you are use to Redux, this may seem like a simple enough process.

Events & Modules (Storeon)

Storeon will be new for many of you, so I’m going to break it down into bite sized pieces. We will start by creating a module to handle our counter state.

basic module and state initialization

When working with Storeon, you work with events and modules. Modules are how we organize different pieces of state logic, and the events we setup inside of those modules define how we interact with that state from the outside world.

We begin by creating and exporting our module called countModule . Storeon will pass the store object to each of the modules we pass to createStore , as I showed earlier. The store object is how we setup events, and dispatch actions. Storeon has a few built in events, such as @init , which is where we setup our initial state. See the docs to read about the other built in events.

Okay, so there isn’t enough here yet to make a good comparison between Redux and Storeon. Let’s add a couple of events that will act as “reducers” in Redux terms:

Our first action events!

Right below our initialization event, we create two new events named count/increasing and count/increase . Basically, this is like our “loading vs. loaded” actions. We use a path naming convention [module-name]/[event-name] to avoid name clashing, since storeon references events by a unique string (like Redux reducers).

You might have noticed that there aren’t any “reducers” and “actions” in the exact same sense as Redux. Well, with Storeon, there isn’t a strict separation of the two in the way we use them in Redux.

In our UI, if we called store.dispatch('count/increase') , our event would be triggered, and the state would be updated.

This is great, because now we have both our “action” and “reducer” in one place, making it much easier to follow!

Events vs. Action Creators

Let’s make an event that calls these “reducer” like events we just created, then calls an api, and finally updates our counter. Here’s a screenshot with our Storeon event on the left, and our Redux action creator equivalent to the right: