The only completely functionaltype-safe approach to Flux that its main goals are to diminish typesverbosity,repetition andcomplexity without losing any type information (type-safe alternative ofredux-actions).

Behold, the art of Deox:

Highlights

• Minimalist (almost no import cost) - checkoutBundle Phobia.
• Simple - focused on self-declarative API.
• Secure - complete test-suits for all of the edge and corners.

Motivation

The most common complaint about Flux is how it makes you write a lot of boilerplate.Also, existing solutions like redux-actions or redux-starter-kit are not type-safe by the idea (although there are some other ideas with classes 😱).

So, this is where Deox takes place tomake maintenance of Flux architecture simpler and more readable by sticking tofunctional programming paradigm.

Installation

You can install Deox package by running:

# YARN 
yarn add deox
 
# NPM 
npm install deox

Typescript tip: notice that Deox internally uses some ES2015 type definitions to represent better developer experience.So if you are usingTypescript and targetinges5, be surees2015 lib has been added in tsconfig.json:

{
  "compilerOptions": {
    ...
    "target": "es5",
    "lib": ["es2015"]
  }
}

The Deox NPM package contains aCommonJS build that can be use withNode.js or module bundlers (e.g.Rollup,Webpack, etc.). it also includes anESM build that works well withtree-shaking.

If you don't use module bundler, it's also fine. The Deox NPM package also includes a production minifiedUMD build that makes Deox available as global variable calledwindow.Deox; you can add it simply to your page via following script tag:

<script src="https://unpkg.com/deox@latest"></script>

Usage

import { createActionCreator, createReducer } from 'deox'
 
const increment = createActionCreator('INCREMENT')
const decrement = createActionCreator('DECREMENT')
const reset = createActionCreator('RESET', resolve => (count: number) =>
  resolve(count)
)
 
const defaultState = 0
 
const counterReducer = createReducer(defaultState, handleAction => [
  handleAction(increment, state => state + 1),
  handleAction(decrement, state => state - 1),
  handleAction(reset, (_state, { payload }) => payload),
])
 
counterReducer(undefined, increment()) //=> 1
counterReducer(undefined, decrement()) //=> -1
counterReducer(3, reset(0)) //=> 0

Documentation

• Introduction
• Getting started
• API reference
• FAQ
  • Using redux-thunk with Deox
  • Using redux-saga with Deox
  • Using redux-observable with Deox

FAQ

Why notredux-actions,redux-starter-kit ?

Bothredux-actions andredux-starter-kit are neat and almost similar to each other.Actuallydeox is similar to those projects in the idea, but not in implementation and promise.The main goal ofdeox is to use the full power oftype-safety andtype inferring in typescript.If you have some experience with those libraries, the following piece of code should be familiar for you:

type Actions 
  = ReturnType<typeof addTodo>
  | ReturnType<typeof removeTodo>
  | ReturnType<typeof editTodo>
 
const todosReducer = createReducer<State, Actions>(...)

This is horrible; Why define a type like actions that a reducer can handle?! It's completely obvious which actions a reducer handles.

On another hand there is a big problem with the pattern thatredux-actions andredux-starter-kit follows. it's lack of correct type for action handler:

const todosReducer = createReducer<State, Actions>(defaultState, {
  [addTodo]: (state, action) => {...}, // action: Actions
  [removeTodo]: (state, action) => {...}, // action: Actions
  [editTodo]: (state, action) => {...}, // action: Actions
})

Type of action parameter inaddTodo action handler is overallActions type. It's inaccurate!

And this is where Deox comes in action and practice:

const todosReducer = createReducer(defaultState, handleAction => [
  handleAction(addTodo, (state, action) => {...}), // action: AddTodoAction
  handleAction(removeTodo, (state, action) => {...}), // action: RemoveTodoAction
  handleAction(editTodo, (state, action) => {...}) // action: EditTodoAction
])

That's it. Thanks to typescript type inferringthere is no type verbosity at all. You can be suretodos reducer have the proper type of state and actions that it can handle.And every action handler's type is just what it should be. It's completely safe and correct!

What's the difference withtypesafe-actions ?

Thetypesafe-actions is a great project that Deox carries huge inspiration from that.Buttypesafe-actions doesn't have any plan for a complete set of utilities (specially reducers);It's all about actions and action creators.

Versioning

Deox usesSemantic Versioning 2.0.0

Contributing

Please read through ourcontributing guidelines.

Inspiration

• redux-actions - Flux Standard Action utilities for Redux
• typesafe-actions - Typesafe Action Creators for Redux / Flux Architectures (in TypeScript)

License

Deox is released underMIT license.