Hey there! We're happy you decided to check this project out. Since we no longer use it at Infinite Red, we've decided to archive it. So it's no longer maintained. If you'd like to use the code or fork it and maintain it yourself, please help yourself. If you'd like us to link to your maintained fork for others who may find it useful, just email us at hello@infinite.red and we'll put a link below this notice. Happy coding!
To create a new release, you need to compile the code first with npm run build
and then create a package using npm pack
. Add the generated .tgz file to the release in github. Then reference that file in your package.json. This is required because otherwise you will get an error saying that the file dist/reduxsauce.js
does not exist.
Provides a few tools for working with Redux-based codebases.
Currently includes:
createReducer
- declutter reducers for readability and testingcreateTypes
- DRY define your types object from a stringcreateActions
- builds your Action Types and Action Creators at the same timeresettableReducer
- allows your reducers to be reset
We're all familiar with the large switch statement and noise in our reducers, and because we all know this clutter, we can use createReducer
to assume and clear it up! There are a few patterns I've learned (and was taught), but let's break down the parts of a reducer first:
- Determining the initial state.
- Running
- Knowing when to run.
- Injecting into the global state tree
Every reducer I've written has a known and expected state. And it's always an object.
const INITIAL_STATE = { name: null, age: null }
If you're using seamless-immutable, this just get's wrapped. This is optional.
const INITIAL_STATE = Immutable({ name: null, age: null })
A reducer is a function. It has 2 inbound parameters and returns the new state.
export const sayHello = (state = INITIAL_STATE, action) => {
const { age, name } = action
return { ...state, age, name }
}
Notice the export
? That's only needed if you would like to write some tests for your reducer.
In Redux, all reducers fire in response to any action. It's up to the reducer to determine if it should run in response. This is usually driven by a switch
on action.type
.
This works great until you start adding a bunch of code, so, I like to break out "routing" from "running" by registering reducers.
We can use a simple object registry to map action types to our reducer functions.
import Types from './actionTypes'
export const HANDLERS = {
[Types.SAY_HELLO]: sayHello,
[Types.SAY_GOODBYE]: sayGoodbye
}
The export
is only needed for testing. It's optional.
Sometimes you want to add a default handler to your reducers (such as delegating actions to sub reducers). To achieve that you can use DEFAULT
action type in your configuration.
import Types from './actionTypes'
import { Types as ReduxSauceTypes } from 'reduxsauce'
export const HANDLERS = {
[Types.SAY_GOODBYE]: sayGoodbye,
[ReduxSauceTypes.DEFAULT]: defaultHandler,
}
With code above defaultHandler
will be invoked in case the action didn't match any type in the configuration.
I like to keep this in the root reducer. Since reducers can't access other reducers (lies -- it can, but it's complicated), my preference is to not have the reducer file have an opinion.
I like to move that decision upstream. Up to the root reducer where you use Redux's combineReducers()
.
So, that brings us back to reduxsauce. Here's how we handle exporting the reducer from our file:
export default createReducer(INITIAL_STATE, HANDLERS)
That's it.
Here's a quick full example in action.
// sampleReducer.js
import { createReducer } from 'reduxsauce'
import Types from './actionTypes'
// the initial state of this reducer
export const INITIAL_STATE = { error: false, goodies: null }
// the eagle has landed
export const success = (state = INITIAL_STATE, action) => {
return { ...state, error: false, goodies: action.goodies }
}
// uh oh
export const failure = (state = INITIAL_STATE, action) => {
return { ...state, error: true, goodies: null }
}
// map our action types to our reducer functions
export const HANDLERS = {
[Types.GOODS_SUCCESS]: success,
[Types.GOODS_FAILURE]: failure
}
export default createReducer(INITIAL_STATE, HANDLERS)
This becomes much more readable, testable, and manageable when your reducers start to grow in complexity or volume.
Use createTypes()
to create the object representing your action types. It's whitespace friendly.
// Types.js
import { createTypes } from 'reduxsauce'
export default createTypes(`
LOGIN_REQUEST
LOGIN_SUCCESS
LOGIN_FAILURE
CHANGE_PASSWORD_REQUEST
CHANGE_PASSWORD_SUCCESS
CHANGE_PASSWORD_FAILURE
LOGOUT
`, {}) // options - the 2nd parameter is optional
prefix
: prepend the string to all created types. This is handy if you're looking to namespace your actions.
Use createActions()
to build yourself an object which contains Types
and Creators
.
import { createActions } from 'reduxsauce'
const { Types, Creators } = createActions({
loginRequest: ['username', 'password'],
loginSuccess: ['username'],
loginFailure: ['error'],
requestWithDefaultValues: { username: 'guest', password: null },
logout: null,
custom: (a, b) => ({ type: 'CUSTOM', total: a + b })
}, {}) // options - the 2nd parameter is optional
The keys of the object will become keys of the Creators
. They will also become the keys of the Types
after being converted to SCREAMING_SNAKE_CASE.
The values will control the flavour of the action creator. When null is passed, an action creator will be made that only has the type. For example:
Creators.logout() // { type: 'LOGOUT' }
By passing an array of items, these become the parameters of the creator and are attached to the action.
Creators.loginRequest('steve', 'secret') // { type: 'LOGIN_REQUEST', username: 'steve', password: 'secret' }
By passing an object of { key: defaultValue }
, default values are applied.
In this case, invoke the action by putting all parameters into an object as the first argument.
Creators.requestWithDefaultValues({
password: '123456',
undefinedKeyWontBeUsed: true
})
// { type: 'REQUEST_WITH_DEFAULT_VALUES', username: 'guest', password: '123456' }
prefix
: prepend the string to all created types. This is handy if you're looking to namespace your actions.
Provides a "higher-order reducer" to help reset your state. Instead of adding an additional reset command to your individual reducers, you can wrap them with this.
Check it out.
import { resettableReducer } from 'reduxsauce'
import { combineReducers } from 'redux'
// some reducers you have already created
import firstReducer from './firstReducer'
import secondReducer from './secondReducer'
import thirdReducer from './thirdReducer'
// listen for the action type of 'RESET', you can change this.
const resettable = resettableReducer('RESET')
// reducers 1 & 3 will be resettable, but 2 won't.
export default combineReducers({
first: resettable(firstReducer),
second: secondReducer,
third: resettable(thirdReducer)
})
NEW
drops redux dependency sinc we weren't using it @pewniak747
NEW
Adds ability to have a default or fallback reducer for nesting reducers or catch-alls. @vaukalakNEW
Adds default values tocreateActions
if passed an object instead of an array or function. @zhang-zDOCS
Fixes typos. @quajo
NEW
Makes unbundled code available for all you tree-shakers out there. @skellock & @messenseFIX
Corrects issue with prefixed action names. @skellockFIX
Upgrades dependencies. @messense
NEW
addsresettableReducer
for easier reducer uh... resetting. @skellock
FIX
creators now get theprefix
as well. @jbblanchet
NEW
createActions and createTypes now take optionaloptions
object withprefix
key. @jbblanchet & @skellock
NEW
adds createActions for building your types & action creators. @gantman & @skellock
NEW
adds createTypes for clean type object creation. @skellock
DEL
removes the useless createAction function. @skellock
FIX
removes the babel node from package.json as it was breaking stuff upstream. @skellock
NEW
initial release. @skellock