Aside of `promiseFn`, also provide just a `promise` property, to be able to run with existing promise

Hi. Thanks for this good work!

TL/DR: the requested feature would allow to simplify this

{searchResultPromise && (
          <Async promiseFn={() => searchResultPromise}>
            <Async.Loading>{<ProgressBar />}</Async.Loading>
            <Async.Resolved>
              {searchResult => (<ul>...</ul>)}
            </Async.Resolved>
          </Async>
        )}

Into this:

<Async promise={searchResultPromise}>
  <Async.Loading>{<ProgressBar />}</Async.Loading>
  <Async.Resolved>
    {searchResult => (<ul>...</ul>)}
  </Async.Resolved>
</Async>

Rationale: Using the promise-based UI patterns, a realm of a module like this one, I find myself quite often in need of having the code for controlling when to start the promise (the logic that would normally go to promiseFn) outside of the ‘present the loader or the results’ component. Sometimes it is enforced on me due to pre-existent decomposition of the code (separate component with the form for triggering the action).

I found that a good way to tackle this in a utility like this module, is to allow it to work with an existent promise. It would use ‘existence of the promise’ as an indicator that the run has started. ‘lack of a promise’, in turn, would be an indicator that the whole component shouldn’t show at all yet, because the user hasn’t started the action yet (NOTE: this second requirement is also a must for this feature to be useful for these frequent use cases).

Notably, I also found that a feature like that is already offered by many of the ‘promise pending/resolved/errored’ NPM modules, (including a popular one - the react-promise), so I do feel it is a proven common pattern.

[ghengeveld]

Okay, I decided to go along with it and renamed waiting to initial. Thanks for the feedback.

[ghengeveld]

Shipped in v5.0.0 🚀