Describe the bug
Despite this test passing, for the first render the state is always undefined.

To Reproduce
Steps to reproduce the behavior:

1. import useEpic
2. use it in a component with an Epic that returns an either a BehaviorSubject with initial state or an observable that pipes to startWith
3. Rely on (or just log) that state on the component render

Expected behavior
The state should be available on the first render

Additional context
One solution would be to subscribe and unsubscribe immediately in first render to get the initial state. If that solution is used we should give a way to opt out, because that could cause weirdness with other peoples observables.

Is your feature request related to a problem? Please describe.
In order to take advantage of the React suspense component, along with concurrent mode, so that w don't have to include loading: true, and the like, in our state....

Describe the solution you'd like
As always intended but I was waiting until some big announcement about data fetching and suspense at React Conf that never really came, so....

Use Suspense in React by an option called suspense which will default to false at first but may change in the future (breaking change) to default to true

If suspense is set to true, whenever the newState$ observable, returned from the Epic returns undefined, it will throw a promise, that will resolve on the next non-undefined value emitted from new state.

Describe alternatives you've considered
Of course you are free to not opt in (or opt out in the future) to this behaviour and handle your own loading states and spinners, I think the React way is to use the suspense component.

The devDependency eslint-plugin-react was updated from 7.18.2 to 7.18.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-react is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency rollup was updated from 1.27.6 to 1.27.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Is your feature request related to a problem? Please describe.

Having to define a lot of callbacks from the dispatch method can be tedious:

const [
  { restaurant },
  dispatch,
] = useEpic(restaurantFilterEpic);

const handleRegionChange = useCallback(e => dispatch(['SELECT_REGION', e.target.value])), dispatch);
const handleCityChange =  useCallback(e => dispatch(['SELECT_CITY', e.target.value]));
const handleRestaurantChange =  useCallback(e => dispatch(['SELECT_RESTAURANT', target.value]));

return <RestaurantSelector
  restaurant={restaurant}
  onRegionChange={handleRegionChange}
  onCityChange={handleCityChange}
  onRestaurantChange={handleRestaurantChange}
/>

Describe the solution you'd like
I'd like an option, to receive action creator style methods instead of the dispatch, perhaps something like:

const [
  { restaurant },
  { handleRegionChange, handleCityChange, handleRestaurantChange },
] = useEpic(restaurantFilterEpic, {
    actions: {
      handleRegionChange: ['SELECT_REGION', e => e.target.value],
      handleCityChange: ['SELECT_CITY', e => e.target.value],
      handleRestaurantChange: ['SELECT_RESTAURANT', e => e.target.value],
    }
  });

return <RestaurantSelector
  restaurant={restaurant}
  onRegionChange={handleRegionChange}
  onCityChange={handleCityChange}
  onRestaurantChange={handleRestaurantChange}
/>

The actions option should memoize the callbacks, but in a more efficient way than useCallback

Describe alternatives you've considered

After writing the examples I have to question: Is it worth it, the amount of code written is pretty close, maybe this isn't the best idea?

Describe the solution you'd like
Provide type definitions to typescript users

Describe alternatives you've considered
I would accept a PR that just adds the typedefs, but if I do it myself I will probably just re-write the library in typescript (mostly as a learning exercise).

Additional context
Of course the library will still export as JS, users will not be required to use TypeScript to use use-epic

First behavior

Callback function "handleChangeRTT" defined inside react function App - timer completed after the first loop.

Second behavior

Callback function "handleChangeRTT" defined outside react function App - timer completed as per condition.

What is the option ?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

scenario:
I wanna dispatch different actions from different Epic.

const [, dispatchLogin] = useEpic(loginEpic)
const [, dispatchActivate] = useEpic(activateEpic)

dispatchActivate({type1,payload1})
dispatchLogin({type1,payload1})

above are different dispatch, and cannot be access and catch globally

Describe the solution you'd like
A clear and concise description of what you want to happen.

combine all the epics and use single dispatch like `redux-observable` combineEpics

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.