chebyrash / promise Goto Github PK

The specification for javascript promises has evolved by a couple of methods since this library was created and was just wondering if we should start hacking up the remaining JS promise methods into the lib?

MDN reference:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

Also I started hacking them up here: https://github.com/elycruz/promise/tree/issue-%23-js_promise_interface (for my own benefit :-D).

Thanks 👍

Spec Reference:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled

Example reference:
https://github.com/tc39/proposal-promise-allSettled#examples

Example reference:
https://github.com/tc39/proposal-promise-allSettled#real-world-scenarios

Method

• - AllSettled

Tests

• - With nil promises.
• - With an empty list of promises (same as above just explicit).
• - With only one passing promise.
• - With only passing promises.
• - With only one failing promise.
• - With only failing promises.
• - With a mix of passing and failing promises.

So, i'm working on something like this:

artists, err := promise.All(promises...).Await()

for _, artist := range artists {
    doSomethingWith(artist)
}

But, because .Await() returns a interface{}, i can't range through it

I also tried to specify the type:

var artists []*structs.ArtistResponse
artists, _ = promise.All(promises...).Await()

for _, artist := range artists {
    doSomethingWith(artist)
}

But then, i receive this:

I'm using Go 1.15

Creating separate issue for each method we're working on adding into the lib (this one's just for the All method).

Methods:

• - All

Tests:

• - All
  • - With no promises.
  • - With resolved promises (1 or more).
  • - With only resolved promises (1 or more).
  • - With failing promises (1 or more).
  • - With only failing promises (1 or more).

Hello,

One of the powerful features of Promises in a JS context is the ability to 'branch' the 'then' functions.

One promise can provide data to multiple other promises that do independent things with it.

In Go, take this example code:

		p1 := promise.New(func(resolve func(interface{}), reject func(error)) {
			time.Sleep(time.Millisecond * 1000)
      
			fmt.Println("1 resolved")
			resolve(uint8(1))
		})

		p1doubled := p1.Then(func(data interface{}) interface{} {
			num := data.(uint8)

			time.Sleep(time.Millisecond * 2000)
			fmt.Println("double resolved")

			return num * 2
		})

		p1tripled := p1.Then(func(data interface{}) interface{} {
			num := data.(uint8)

			time.Sleep(time.Millisecond * 500)
			fmt.Println("triple resolved")

			return num * 3
		})

		oneD, _ := p1.Await()
		one := oneD.(uint8)

		twoD, _ := p1doubled.Await()
		two := twoD.(uint8)

		threeD, _ := p1tripled.Await()
		three := threeD.(uint8)

		fmt.Println(one)
		fmt.Println(two)
		fmt.Println(three)

The expected behaviour would be for it to print:

1 resolved
triple resolved (500ms later)
double resolved (1500ms after that)
1 (all at once)
2 (^)
3 (^)

However the current behaviour assumes all promises exist as 'chains' with no branches. This also causes 'waterfall' behaviour with its execution.

1 resolved
double resolved (2000ms later)
triple resolved (500ms after that)
6 (all at once)
6 (^)
6 (^)

I assume the former would actually be the intended behaviour for the library given the comments for the Then function:

	// Appends fulfillment to the promise,
	// and returns a new promise.

The Then function distinctly does not return a new promise, it returns the same promise, adding the fulfilment function to the list.

The fix is relatively simple, copy the Promise every time the Then function is called to branch it off, actually returning a new Promise.

The Catch function should not return a new promise, but the old promise, it should not copy it.

Essentially this:

// Then appends a fulfillment handler to the Promise, and returns a new promise.
func (promise *Promise) Then(fulfillment func(data interface{}) interface{}) *Promise {
	promise.mutex.Lock()
	defer promise.mutex.Unlock()

	promiseCopy := promise.copy()

	switch promiseCopy.state {
	case pending:
		promiseCopy.wg.Add(1)
		promiseCopy.then = append(promiseCopy.then, fulfillment)
	case fulfilled:
		promiseCopy.result = fulfillment(promiseCopy.result)
	}

	return promiseCopy
}

// copy creates a copy of a Promise that resolves when it does, it returns the new Promise.
func (promise *Promise) copy() *Promise {
	p := New(func(resolve func(interface{}), reject func(error)) {
		data, err := promise.Await()

		if err != nil {
			reject(err)
			return
		}

		resolve(data)
	})

	return p
}

This obviously changes the behaviour of the library in a breaking manner.

Would a PR like this be accepted? I would assume a major version bump to v2 would have to be done?

Alternatively I can just create a fork with the different behaviour.

What are your thoughts?

Thanks.

Future I think it can make the code more clear without doubt, and sometimes it using the flight goroutine to running its 'Job'， which is little not suitable for the web server. So can the future using the goroutine pool resource to running ? Thanks.

This is the only other method from the JS Ecmascript 2015 standard that is not implemented here (other than the All method (which has a pull request on the way)).

Link to 'race' docs on MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/race

This issue will be to track the work done on it:

Method:

• - Race

Tests:

• - With no promises.
• - With one promise, a passing one.
• - With multiple passing promises.
• - With one promise, a failing one.
• - With multiple promises and one failing.
• - With multiple failing promises.

Problem: When there are more than two rejected promises in promise.All function. The returned error value is not stable。

Please infer blow image: the println err.Error() output maybe error1 or error2, in js promise. it is error1.

In the README as well as in the examples, you use promise.Any for typing but it is not exported by the package.

Hi,

Is there a way to perform promise.All() on a slice? Something like this:

		for _, completedTransaction := range promises {
			completedTransaction.Await()
		}

but built in. I realize a workaround is available now by using reflection, but this doesn't work with too many values.

confused.

your example is get ip from the remote
but if my network is poor that it'll last long time
i wanna to reject after 3 second if the ip does't get

HI,

Few questions.

1. Does each promise run in go routine ?
2. in case each promise run in go-routine , is it possible to use timeout ?

e.g. in case you are running promise.all for promise A and promise B and you want to wait for 10 seconds for all the responses (time limit) ,but promise A continue to run (possible forever due to some issue), is it possible to kill promise A after the 10 seconds ? (when you want to get the results with the time limt)

Thanks!

A lot of older tests need to be refactored to follow the new style proposed by @elycruz