Automattic / Automattic/mongoose
About asynchronous getters/setters again
- Dominant language
- JavaScript
- Stars
- 27.5k
- Forks
- 4k
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 35
Description
I have read the two discussions (#2571 and #517) that relate to this opportunity, and still do not see any reason to abandon it. Why not? Even if Mongoose should maintain compatibility with the ES5, this does not prevent to check that the setter returns to us. Watch this pseudo-code:
``` javascript
if (setterResult.constructor.name === 'Promise' && setterResult.then) {
promisesArray.push(setterResult.then(
value => {
return {
path: path,
value: value
};
},
err => {
return err;
}
));
}
// ...
if (promisesArray.length){
return Promise.all(promisesArray).then(
results => {
for (let result of results) {
// Do anything with it
}
// Do anything with all fields
return this.save();
},
errors => {
for (let err of errors) {
// Do anything with it
}
return errors;
}
);
} else {
// Do anything with all fields
return this.save();
}
```
So why not? This is a very useful feature, and it will join naturally in existing.
Contributor guide
Research direction
Start with discussions #2571 and #517 and the pseudo-code in this issue; it names no files, tests, or entry points. Done requires an agreed scope for asynchronous getters and setters plus tests showing the intended behavior without breaking existing ES5-compatible behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, mongodb, nodejs
- Domain
- backend, database
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100