sling-connector issueshttps://gitlab.entropy.cc/entropy/sling-connector/-/issues2021-01-25T14:30:32Zhttps://gitlab.entropy.cc/entropy/sling-connector/-/issues/16Discussion: Move to Promise first implementation2021-01-25T14:30:32ZCaleb WeeksDiscussion: Move to Promise first implementationThis is a space to discuss options for switching to a Promise-first approach for the SlingConnector. The drive for this is to reduce the complexity of the current SlingConnector code and make the calls more efficient overall. Suggestions...This is a space to discuss options for switching to a Promise-first approach for the SlingConnector. The drive for this is to reduce the complexity of the current SlingConnector code and make the calls more efficient overall. Suggestions made so far:
1. Remove callback version entirely and bump to a new major version
1. This makes for the cleanest implementation of Promises, but will take a long time for full adoption. BL core could be updated without _too_ much hassle, but non-core consumers would take a long time meaning we'd need to two version of the sling-connector available, which I don't love. I think this is only viable if we commit to updating **everything** to use the new version
2. Keep the callbacks as an option, but switch to doing Promises first, calling callbacks only if they're provided.
1. This was something I actually considered when we first added Promise support (https://stackoverflow.com/questions/57686203/function-needs-to-support-promises-and-callbacks), but I opted not to do it because I couldn't find anyone approaching callbacks / Promised that way. I still don't see any obvious downsides with it.
3. Move the promise version to a nested area in the import. Something like `require('sling-connector/promise')`.
1. I don't love this option since we still have the complexity of reusing code between the two approaches. It just forces the developer to pay more attention to the import. It would also break anywhere that's using the current Promise version.
4. We could go with something similar to the `aws-sdk`, where the Promise version must be explicitly requested with the `.promise()` call. Similar to the item above this, I don't love it because any existing Promise implementations would break. Might have been a good option from the start, but difficult to switch to now.Caleb WeeksCaleb Weeks