some feedback / questions about attempt-promise HOT 5 CLOSED

Hey, so I saw this and I've been thinking about it on-and-off. Sorry it's taken so long to respond.

from attempt-promise.

That's a good question. I think both approaches are fine, but they are very different mindsets. The "Go approach" this library introduces is single-minded in its attitude to direct errors resulting from a single resolution. "Does this one call error? Let me deal with it immediately."

The "Promise approach" cares less about what causes the error or when it happens. It's likely that complex scenarios will require catch callbacks to juggle multiple error cases inside a single catch callback. "Did something error? Let me figure out what the error is..."

This library is equal parts technical implementation and stylistic choice to deal with errors immediately and unambiguously.

from attempt-promise.

Having said all that; it's entirely possible to use then/catch in a way that is stylistically similar (as you have done in your example). I don't think your example is typically how the then/catch chains go; but there's nothing preventing folks writing the chain in the way you have.

I'd argue that the "Go approach" is clearer and more succinct, but there's little data to show either way.

from attempt-promise.

Fully agreed, this is than basically a choice of style. speaking of which I would like your opinion of a promise-proxy pattern I have been toying with.

like the prosime example given above everything we do there is syntactically working around the async nature of a promise, the the logic written out is sequential, agreed?

well I think the above code could also be written as follows

try
{
    response.ok(
        "here are your products...",
        User.find(id).products.order("updated_at", "desc").limit(50)
    );
}
catch(e)
{
    response.error(`whoops we encountered an error: ${e}`);
}

(I don't think this is a very good example for this pattern, since for this to work response.ok needs to be able to accept a Promise as parameter)

User.find returns a Promise because it is asynchronously right, but the Promise class does not contain a property/function for products. So to solve this I wrap the Promise in a Proxy which queue's up all the calls, this way we can execute the when data is available but the code calling it is very readable

In my case I implemented the Proxied-Promise as follows

        let queue = [];
        const resolve = (item, { property, args }) => {
            let r = item[property];

            if(typeof r === 'function')
            {
                r = r.apply(item, args);
            }

            return r;
        };
        const promise = somthingThatIsAsync(someArg)
            .then(r => queue.reduce(
                (t, q) => t.then(r => Promise.resolve(r !== null && r !== undefined
                    ? resolve(r, q)
                    : undefined
                )),
                Promise.resolve(window[model])
            ));

        const proxy = new Proxy(() => {}, {
            get: (c, p) => {
                if((p in promise) === true)
                {
                    return promise[p].bind(promise);
                }

                queue.push({ property: p, args: [] });

                return proxy;
            },
            apply: (t, c, a) => {
                queue.last.args = a;

                return proxy;
            },
        });

        return proxy;

In my opinion this is very useful (if the recipiënt of the chain can handle promises), but I am curious what you think of this pattern (like possible pitfalls I have overlooked)

(I hope this isn't offtopic, since this whole issue has basically resulted in a discussion about code style)

from attempt-promise.

ping?

from attempt-promise.