Consider an async (promise) allowance for actions / stores
- Dominant language
- JavaScript
- Stars
- 3.4k
- Forks
- 312
- PR merge metrics
- No merged PRs in 30d
Description
As ECMAScript 6 (and even 7) features become easier to achieve and use in a project, I feel that we should have allowances for using (what is now) first-class asynchronous primitives: Promises.
_Stores_ may return promises in a handling method.
``` js
export default alt.createStore(class Store {
// [...]
onSend() {
// This becomes much nicer when we can do "async onSend() [...]" in ES7
return new Promise((resolve, reject) => {
resolve();
});
}
});
```
_Actions_ return a promise by-default from the dispatch call.
``` js
export default alt.createActions(class Actions {
// The actions generated from the shorthand methods become the following:
send(params) {
return this.dispatch(params)
}
});
```
Internally, `this.dispatch` uses `Promise.all` to wait for all stores to finish execution and returns a chained promise that disposes of the resolved iterable.
---
The above allows for views that invoke actions to easily wait for a success or failure of a possibly asynchronous event.
Thoughts? I'll jump in and implement if we can agree that this is a good proposal for moving forward.
Contributor guide
Research direction
The proposal names stores, actions, this.dispatch, and Promise.all, but no files or tests. Start by reviewing the existing action and store dispatch flow, then read the discussion for an agreed design. Done would require a settled approach and corresponding coverage for asynchronous store handling and action promises.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100