Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 28 06:09

    sindresorhus on master

    Create funding.yml (compare)

  • Nov 18 2018 12:07
    sindresorhus closed #7
  • Nov 18 2018 12:07
    sindresorhus commented #7
  • Nov 14 2018 23:14
    rodrigogs opened #7
  • Sep 28 2017 06:41
    SamVerschueren edited as member
  • Sep 28 2017 06:40
    kevva edited as member
  • Sep 23 2017 09:42
    sindresorhus closed #3
  • Sep 11 2017 11:18

    sindresorhus on master

    Add `p-progress` module (compare)

  • Aug 17 2017 10:04
    SamVerschueren edited as member
  • Aug 17 2017 10:04
    kevva edited as member
  • Jul 27 2017 14:18

    sindresorhus on master

    Fix typo (compare)

  • Jul 23 2017 13:11
    kevva edited as member
  • Jul 23 2017 13:07
    kevva edited as member
  • Jul 23 2017 13:05
    kevva edited as member
  • Jul 23 2017 13:03
    kevva edited as member
  • Jul 21 2017 20:18
    sindresorhus commented #3
  • Jul 21 2017 20:16
    sindresorhus commented #3
  • Jul 07 2017 19:01

    sindresorhus on master

    Slightly simplify one of the ex… (compare)

  • Jun 30 2017 18:49

    sindresorhus on master

    Add `p-do-whilst` module https… (compare)

  • Jun 02 2017 18:42

    sindresorhus on p-every

    (compare)

Luke Childs
@lukechilds
Out of interest, any reason you went with new Promise over Promise.resolve in p-try?
Could be simplified to just:
module.exports = cb => Promise.resolve().then(() => cb());
Sindre Sorhus
@sindresorhus
Yes, but that results in two promises, not one.
Promise.resolve() is one promise, and .then() is another promise
So adds slight overhead, although not noticeable.
But most importantly, the way I’ve done it is how it’s currently spec’d.
Luke Childs
@lukechilds
I see :ok_hand:
Federico Brigante
@bfred-it
Anything like a progress tracker for promises?
pProgress([a,b,c,d], p => console.log(`promises ${p}% loaded`))
It'd make sense for my image loader: https://github.com/bfred-it/image-promise
pProgress([src1, src2, src3].map(loadImage), logProgress)
And I guess it could ultimately behave like a Promise.all:
pProgress([...], logProgress).then(/* all done */)
Sindre Sorhus
@sindresorhus

@bfred-it

const promises = [a, b, c, d];
pProgress.all(promises).onProgress(p => {
  console.log(`promises ${p * promises.length}% loaded`;
}));

If you only supply it normal promises, the percentage per promise is always binary.

I do think it might be a useful addition to have this explicitly though. Maybe as a second argument onProgress. Can you open an issue about it?
Will Poulson
@WillPoulson
@sindresorhus Hi, Sorry I sent you an email then found this page. I'm having some issues with pEachSeries not actually waiting for the iterator to resolve before calling the next one. Any help?
Will Poulson
@WillPoulson
Eg I have two pEachSeries that chain. The second ones iterator has a timeOut inside of it. It doesn't wait before resolving.
Can I even chain pEachSeries?
Sindre Sorhus
@sindresorhus
@WillPoulson Just answered your email.
Will Poulson
@WillPoulson
@sindresorhus How am I meant to deal with catches in the pEachSeries? I'm rejecting promises but it doesn't trigger the catch on the each?
Sindre Sorhus
@sindresorhus
@WillPoulson If any of the promises in the iterator rejects, the pEachSeries promise rejects, and you could catch that if needed. See: https://github.com/sindresorhus/p-each-series/blob/0ff0ca8e52b4e1e54384c2c7cb99514e3e880921/test.js#L33-L35
Pulkit Sood
@dannysood
@sindresorhus Thank you for amazing work. Why isnt there a way to install all in a single package to install and upgrade quickly?
Phil Helm
@phelma
@dannysood I found this https://github.com/lenell16/promise-fun which might be what you are looking for
buoyantair
@buoyantair
Hey um
Am I doing this correct?
image.png
I think strings are also iterable right
Sindre Sorhus
@sindresorhus
Hard to say that without knowing what you're trying to achieve.
buoyantair
@buoyantair
Just trying to see how I can use this package :yum:
Theodore Dubois
@tbodt
i'm curious why all these promise packages are separate packages rather than one big package
Luke Childs
@lukechilds
why would you prefer one big package?
Johnny L.
@jleeothon

@lukechilds I came here wondering the same: if it's possible to install the whole lot in a single package. (Big apologies in case this was already talked about thoroughly!)

I assume that package size is a bigger concern for frontend development. But arguably, as a server-side developer I'm not that concerned about the size of the the dependencies.

I know that all the "promise-fun" packages are developed with the same philosophy and namespaced under the same author. And although they are independent, they solve the same need for a promise library/framework/ponyfill.

Making a different package out of every single function is an overkill if you look at it from this perspective.

Luke Childs
@lukechilds

@jleeothon So from you perspective there is not much downside apart from the mild inconvenience of installing a new package each time you want to use one. You could create your own package that bundles them all together if you wanted (it probably already exists) and then just depend on that.

But if it was the other way round, and I wanted to write a frontend module and wanted to use one of these functions. I'd need to include the entire library, which would be a much worse downside.

Sindre Sorhus
@sindresorhus

I'd need to include the entire library, which would be a much worse downside.

And yes, there's tree-shaking, but it rarely works in practice.

Luke Childs
@lukechilds
And even if it worked perfectly, package authors shouldn't be tree shaking their libs and publishing a bundle. The package consumers should be the ones settings up tree shaking, so you would require every single consumer to have a complex build system to use it on the front end without a size penalty
Sindre Sorhus
@sindresorhus
Yes, I didn't mean that I would do the tree-shaking up-front.
Luke Childs
@lukechilds
yup, was just further emphasising the point that it would cause more pain
Sindre Sorhus
@sindresorhus
There are also many other benefits to smaller modules. Easier to replace. The modules can update independently of each other (No more waiting for a never arriving v2).
Johnny L.
@jleeothon
Indeed in some comment above someone mentioned a library that bundles them all together :) Thanks guys! I can definitely see the point of keeping them separate but also the advantage of something that will bundle them together.
Kirill Groshkov
@kirillgroshkov

It seems to me that p-queue is the most maintained package, newly added features (like throttling) overlap with other packages (like p-throttle). So it seems like I can use just p-queue for my cases and not need p-map or p-throttle.

I'm just thinking.. Wouldn't it be easier to implement all promise-like features in one package (e.g around p-queue) and just drop all others. Cause now the list of p-packages is so big and it takes time to figure out what to use. In the readme it recommends p-map by default, but.. I would recommend p-queue since it covers more functionality.

Also, +1 from me to expect it all in one package. Frontend devs use build tools 99% of the time, and I just believe/hope that tree-shaking will work in future (it just should! cause it's so important). For backend devs size really doesn't matter in such scales as these tiny packages. Size will be probably even smaller due to smaller package.json and lockfiles and other package management overhead:)
Travis Fischer
@transitive-bullshit

@kirillgroshkov 98% of the time, p-map is the exact functionality that I want.

Just because a package has more recent commits doesn't mean it's more well maintained. p-map, for instance, is more targeted and has been so battle-tested that there's rarely a need to update it as it's core functionality is more focused.

Kirill Groshkov
@kirillgroshkov
ok, I'll take a look again at p-map api vs p-queue api. It would be great if just one package can fit all needs so I don't need to import numbers of packages
Gabo Esquivel
@gaboesquivel
@sindresorhus how do you do achieve same functionality as Q.allSettled with the promise-fun libs ?
Gabo Esquivel
@gaboesquivel
Gunar Gessner
@gunar
Is there a promise-fun alternative to https://github.com/andyfleming/interval-promise ?
I could use p-throttle + setInterval but it wouldn't be elegant as that could become a memory leak. My problem is that an iteration could take longer than the interval set, hence interval-promise.
Gunar Gessner
@gunar
I'm going with setInterval + p-queue for now, but this is not ideal
Gunar Gessner
@gunar
Alright so I can do p-queue + throttling (to implement interval behavior) + onIdle (to always keep one job in the queue)
Да
@Vadyanga_twitter
Hello
I'm using this code
const doWork=async(b)=>{
while(online > maxWorkers-1)await delay(5000);
return b++;
};
const a = [1,2,3];
let x = await Promise.all(a.map(doWork));
console.log(x);
which one I need to use for delete a string with delay
https://github.com/sindresorhus/promise-fun