The Mighty Deferred Promise - An Interview Recount

❗️ See the comments - I over-engineered this, my solution is far from ideal. Good discussion in comments!
👉 I am writing a book on tooling! Check it out: lachlan-miller.ck.page/92dfa0...
🐦 / lachlan19900
I had an interview recently which featured an interesting question. In this video, I share the question and my solution, along with a construct, the mighty deferred promise. There's a TC39 proposal for it under the name "withResolvers": github.com/tc39/proposal-prom...
Corrections: 5:00 p-defer isn't necessary here - you can just return a promise. p-defer is useful if you want to resolve or reject the promise afterwards, from outside the location it was originally created. Example improvement: gist.github.com/lmiller1990/2.... See comments for discussion.

[@nochtans342]

Only makes sense to use this p-defer package if you are going to reject or resolve the value outside the promise no?

[@rahul_sharma_1]

Nice video and best explanation.

[@virtualdev0]

I did something similar on a project, but in a distributed environment. I have an in-memory object cache where values are being retrieved. It then listens to feature flag changes through redis, and updates the local in-memory cache. This made it faster because you’ll always get the latest changes without having the call the remote database all the time

[@dfidalgo2]

Just store the Promise object directly.

[@hkhademian]

I do not see any reason for using pdeffer in your example .

[@StingSting844]

This works only for a single feature flag? What happens when we have multiple requests for multiple feature flags? We need something like a singleton class which has a queue built in to handle batching. Calling getFeatureFlag('feature1'), getFeatureFlag('feature2') should work flawlessly. And in the instance you can build a simple cache to return the value immediately if was already fetched.

[@bk1507]

This sounds a lot like an interview I had at canva a few years ago

[@parlor3115]

Don't really see the value of this technique. You could have fetched the feature flag object in one call and wrote a second function that extracts the value of single feature flag using the key. In a frontend app, this is usually done on login and the object is stored in local storage.

[@NikitaFedotov-ok6ty]

Good video as always, thank you

[@dmytro3568]

it would be better to use lru-cache for storing multiple values and implement at least a basic scheduler mechanism, when you track the status of the feature request and not going to make multiple requests. also, it is common to have real-time feature flags, which means you have a WebSocket connection or polling these values with some delay, but it looks like this is not the case, so I assume this was a question about how to deal with cache techniques.

[@CodeChallengee]

Why Vim???

[@Giovanni-ge4jy]

In real world scenarios to beautifully handle asynchronous calls I would suggest using some reactive programming lib, like RxJS

[@basarat]

Nice video ❤