Thanks for the reply. I believe promises are a better pattern to tackling
asynchronous workflow. The only problem with promises, in my opinion, is
people aren't using them enough.
I really wanted feedback on the blackbox widget development more than
promises vs callbacks though.
On Monday, October 5, 2015 at 6:32:48 PM UTC-5, Aleks Totic wrote:
>
> In this pattern, I'd prefer callbacks to promises, something like:
>
> this.fire('share-item',{id, target, message, callback(err, result});
>
> Promises are still not mainstream, and callbacks are well understood.
>
> Aleks
>
> On Monday, October 5, 2015 at 1:28:56 PM UTC-7, Phred Lane wrote:
>>
>> I'm making an application that functions as a front end for a service. It
>> doesn't do any work itself. It just let's the outter page know that it
>> wants things to be done through events.
>>
>> For instance, it fires events like:
>>
>> this.fire('delete-item', {id});
>>
>> this.fire('edit-item', {id, title});
>>
>> this.fire('share-item',{id, target, message});
>>
>> If the request can fail or I care about the response, I have a wrapper
>> around `this.fire` that fires with a deferred object and the data. This is
>> so I can show the end user feedback "Deleted X items successfully" or
>> "Failed to update the title for Y".
>>
>> this.firePromise('delete-item', {id});
>>
>>
>> this.firePromise('edit-item', {id, title});
>>
>>
>> this.firePromise('share-item',{id, target, message});
>>
>> For reference, this is the definition of the Promisable mixin:
>>
>> Polymer.Promisable = {
>> defer: function() {
>> return Q.defer();
>> },
>> firePromise: function(name, data) {
>> var deferred = this.defer();
>>
>> deferred.data = data;
>>
>>
>> this.fire(name, deferred);
>>
>>
>> return deferred;
>> }
>> };
>>
>>
>> The otuter page catches the events, does the needful, and
>> resolves/rejects the promise as needed. Here's an example:
>>
>> widget.addEventListener('delete-item', function(e) {
>> var deferred = e.detail;
>> var data = deferred.data;
>>
>> fetch(`/rest/endpoint/items/${data.id}`, deleteOptions)
>> .then(function(result) {
>> deferred.resolve();
>> widget.items = result.items;
>> })
>> .catch(deferred.reject)
>> ;
>>
>> });
>>
>> I'm not responsible for making the requests to the backend myself,
>> because the goal is for me not to care. I'm just expressing how I want the
>> data to be managed.
>>
>> Is this a weird pattern? Is there an alternative (better and/or more
>> Polymer-esque) way to get the same functionality? I don't want to use fetch
>> wrapped in an element, because I don't care if they use fetch, $.ajax, or
>> any other method to get the data. I want them to be free to handle my
>> events as they see fit.
>>
>> I'm generally just looking for feedback on this pattern.
>>
>>
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/49c3c482-5edf-4c5d-ad7d-c54f44a31abf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
