react-blog-post: A React Blog App That Teaches the Redux Lifecycle

This 2017 CRUD demo is less about publishing posts than about showing how actions, reducers, routing, and form state fit together.

8 min read · zubair-trabzada/react-blog-post

A folded paper blog post feeds into a mechanical sorting press, where gears and levers split the flow into indexed cards, a delete chute, and a return path to a clean browser window. The scene explains how the app turns user input into normalized Redux state and then back into rendered screens. — The app is really a pipeline. Input becomes an action, the action becomes state, and the state becomes a screen.

Key Takeaways

react-blog-post reads like a working lab notebook, because every file explains one step in the classic Redux CRUD loop.
Its strongest pattern is normalization, where API posts become an ID keyed map that is cheap to read and safe to update.
The repo shows how promise middleware, form actions, and route ordering combine to make asynchronous navigation feel deterministic.
The code is dated, but the architecture still makes the request to render path legible in a way many newer stacks hide.

The most interesting thing about react-blog-post is not that it lets you publish posts. It is that it freezes a particular answer to a once common question: how do you make React, Redux, routing, and async data fetches behave like one system? Built as a fork of Stephen Grider's ReduxSimpleStarter, the repo reads like a guided tour of that era's best practices.

The app is built around one clean loop

That loop is simple enough to fit in your head, which is why the project works as an explainer. A form dispatches an action, redux-promise waits on the request, the reducer reshapes the payload, and the component renders from the store. Even route order is part of the lesson: /posts/new and /posts/:id sit above / so the index page does not collide with the create or detail screens.

The core pattern is linear. User input becomes an action, the action becomes normalized state, and route order decides which screen is allowed to render.

The diagram is the whole app in miniature. The user experience feels like ordinary CRUD, but the code is enforcing a strict sequence underneath it. You do not get a post view until the store has the right shape, and you do not get the index page when a more specific route should win.

Normalization is the real feature

case FETCH_POSTS:
  return _.mapKeys(action.payload.data, 'id');

case FETCH_POST:
  return { ...state, [action.payload.data.id]: action.payload.data };

case DELETE_POST:
  return _.omit(state, action.payload);

This is a small move with a large payoff. Once posts are keyed by ID, the app can fetch one record without scanning an array, delete one record without rebuilding everything, and treat the store as a lookup table instead of a pile of list items. The UI gets boring in the best possible way, because the data shape stops getting in its way.

What the stack reveals about its era

Repo pattern	What it buys	Lighter alternative
Redux Form for every field	One source of truth for the whole form lifecycle	Local component state or form hooks
Promise middleware plus callback redirects	A deterministic path from save to navigation	Query cache plus effect driven routing
Normalized post map	Fast lookup and simple updates	Entity adapters or server cache
Explicit Switch ordering	Prevents overlapping routes from rendering together	File based routing or nested routes

The stack is a time capsule. React 0.14, Redux 3, react-redux 4, redux-form, Webpack 1, Material-UI 0.20, Bootstrap from a CDN. That mix says the project was written when Redux was the default answer for even a small CRUD app, and when a little ceremony was considered the price of clarity.

The trade-offs are visible on purpose

The trade-off is obvious. This style gives you visibility, but it also spreads simple concerns across more files and more ceremony than a small app usually needs now. It also exposes rough edges, like a hardcoded API key and a dependency list that has aged past its support window. As a teaching sample, that is a feature. As production code, it is a warning label.

What makes react-blog-post worth studying is that it makes the full contract visible: submit, fetch, normalize, render, redirect. That chain is still the backbone of many frontends, even if the surrounding abstractions have changed. If you want to understand what Redux promised at its peak, this is a clean specimen.