A sample app showcasing Flux with React Router
JavaScript HTML
Switch branches/tags
Nothing to show
Clone or download
gaearon Merge pull request #41 from yanandcoffee/patch-1
Changes React Hot Loader url to React Transform Boilerplate url
Latest commit 5b35af1 Oct 3, 2015

README.md

Flux React Router Example

This is a sample Flux app I wrote on a weekend.
It uses open Github API to display starred repos by users and stargazers by repo.

Note: I now prefer Redux to Flux.
This example was ported to Redux.

I made it to document a few approaches I have tried while learning Flux.
I tried to keep it close to real world (pagination, no fake localStorage APIs).

There are a few bits here I was especially interested in:

Running

npm install
npm start

Doing Other Things

npm run lint # uses eslint
npm run build # build production version to dist folder

How I Classify Stores

I tried to avoid some of the duplication I've seen in other Flux example, specifically in Stores. I found it useful to logically divide Stores into three categories:

Content Stores hold all app entities. Everything that has an ID needs its own Content Store. Components that render individual items ask Content Stores for the fresh data.

Content Stores harvest their objects from all server actions. For example, UserStore looks into action.response.entities.users if it exists regardless of which action fired. There is no need for a switch. Normalizr makes it easy to flatten any API reponses to this format.

// Content Stores keep their data like this
{
  7: {
    id: 7,
    name: 'Dan'
  },
  ...
}

List Stores keep track of IDs of entities that appear in some global list (e.g. “feed”, “your notifications”). In this project, I don't have such Stores, but I thought I'd mention them anyway. They handle pagination.

They normally respond to just a few actions (e.g. REQUEST_FEED, REQUEST_FEED_SUCCESS, REQUEST_FEED_ERROR).

// Paginated Stores keep their data like this
[7, 10, 5, ...]

Indexed List Stores are like List Stores but they define one-to-many relationship. For example, “user's subscribers”, “repository's stargazers”, “user's repositories”. They also handle pagination.

They also normally respond to just a few actions (e.g. REQUEST_USER_REPOS, REQUEST_USER_REPOS_SUCCESS, REQUEST_USER_REPOS_ERROR).

In most social apps, you'll have lots of these and you want to be able to quickly create one more of them.

// Indexed Paginated Stores keep their data like this
{
  2: [7, 10, 5, ...],
  6: [7, 1, 2, ...],
  ...
}

See and run the source for more tips!