tslib is similar to the babel runtime. I should do some bundle size comparisons to see if offloading bytes to tslib makes sense. The size cost should be balanced: this is an easy tradeoff for apps written in TypeScript (they've probably got the library already) but if it adds much size in vanilla, the tradeoff isn't worth it.

It looks like there was a regression with action payload type inference. The never case is bleeding through. I suspect the failure action type branch is to blame.

Repro

const action = createAction('type', () => {
  return 'value'
})

createReducer(null, handleAction => [
  handleAction(action, (state, payload) => {
    //                         ^^^^^^^ never
  })
])

Repro:

const action = createAction.async('type', async payload => {
  // payload === undefined
})

action('payload') // 'payload' isn't given to the effect.

I recently discovered the tsdx build system. It automates a lot of stuff I've been trying to do manually, and after (counts repositories) 45 projects, the thought of having someone else manage JS tooling sounds pretty dreamy. tsdx looks like it might be able to deliver, and a proof of concept against the todomvc demo app appears to work marvelously.

I'm removing the failure(...) return value and replacing it with a bulk catch for thrown errors, which means the error type is no longer inferable for handleAction.error(...). It will become unknown. I'll encourage custom errors and instance checks instead.

handleAction.error(action, (state, error) => {
  if (error instanceof SomeCustomError) {
    // do the thing
  }
})

This issue provides visibility into Renovate updates and their statuses. Learn more

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency redux to v4.1.1
• Update dependency typescript to v4.4.2
• Update dependency eslint-plugin-prettier to v4
• Update dependency immer to v9
• Click on this checkbox to rebase all open PRs at once

• Check this box to trigger a request for Renovate to run again on this repository

Only async iterators are supported currently. That's causing some issues in #205 because I need synchronous execution, which is technically possible on the first tick of an async generator, but then the dispatch return value becomes a promise. That's certainly undesirable.

Now that I have a real use for them, I need proper support for synchronous iterators in the redux middleware.

function* dispatcher() {
  yield { type: 'action-1' }
  yield { type: 'action-2' }
  yield { type: 'action-3' }
  return 'return value of `dispatch(...)`'
}

Now that I'm moving towards throw statements instead of the failure(...) return value, I no longer need it. I should rip it out.

This will be a breaking change (obviously).

Retreon needs a logo for both the project and the organization.

Yielding an action should resume control with the return value of dispatch(...).

async function*() {
  const { type } = yield action()
}

and because this is all executed by the middleware, yielding another iterator will recursively consume all those yield statements as well, leading to some very interesting composition patterns.

I need error reducers to intercept error events, not just those gracefully returned by failure(...). This means adding a catch statement on the effect, but as I outlined over here, I can't just swallow every error. That means conditionally re-throwing after dispatch is done.

The only way that's possible is through async generator functions.

async function* createAction(type, effect) {
  try {
    yield { type, payload: effect() }
  } catch (error) {
    yield { type, error: true, payload: error }
    if (isUnknown(error)) throw error
  }
}

As an advanced use case, developers can dispatch actions through generator functions. Developers have to format their own action payloads, which makes reducer type inference difficult for error types and impossible for optimistic types.

const underlyingAction = createAction<string>('type')

async function* advanced() {
  // For reducer type inference to work, the optimistic payload must be part of the
  // action's return signature. Currently, there's no method to communicate it
  // without buying into `createAction.async(...)`.
  yield { type: String(underlyingAction), meta: {} }

  try {
    await effect()

    yield underlyingAction('works just fine')
  } catch (error) {
    // This is unwieldy, but still works with the reducers because `handleAction.error(...)`
    // infers the signature from `underlyingAction`. Alternatively, you could add a
    // boolean parameter to conditionally throw inside the action creator... yeah, I'm not
    // keen on it.
    yield { type: String(underlyingAction), ... }
  }
}

I'm tempted to create another action factory function, one that puts the onus of effect execution solely on the end developer, this way generator functions can leverage type inference and FSA compliant actions without much effort.

const underlyingAction = actionFactory<Payload, OptimisticPayload>('type')

async function* advanced() {
  yield underlyingAction.optimistic('optimistic payload')

  try {
    await effect()
    yield underlyingAction.success('success payload')
  } catch (error) {
    yield underlyingAction.failure(new Error('action failed'))
  }
}

It will require a new package export and type detection on reducers.

Now that I've settled on a consistent API, I can implement error handling for async action creators. Async actions should trigger handleAction.error(...) on any promise rejection.

const action = createAction.async('type', async function() {
  throw new Error('async rejection')
})

createReducer(state, handleAction => [
  handleAction.error(action, (state, error) => {
    console.log(error) // Error: async rejection
  }),
])

I'd like a simple application where I can demo and test the features of retreon holistically, something along the lines of a TodoMVC clone. It would help greatly to have E2E smoke tests verifying that retreon actually works in harsh browser environments.