The Mighty Deferred Promise - An Interview Recount

Рет қаралды 7,143

6 ай бұрын

❗️ 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.

Пікірлер: 33

@nochtans342 6 ай бұрын

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

@nicholasantidormi6238 6 ай бұрын

Agree, I think you can use the variable to store the promise directly. Another little improvement could be awaiting the promise instead of using .then, just for consistency, I'm not a big fan of mixing async/await with then (but It is just a personal preference).

@LachlanMiller 6 ай бұрын

This is a good point, this whole thing could be simplified to something like this gist.github.com/lmiller1990/26eb3c2d76eb8c122a0012c1e47dc15e p-defer package can be useful if you need to resolve/reject after the call for whatever reason, but in this situation it's not really necessary. After thinking this through, I don't think p-defer really makes sense in this explanation. I will add a comment to this meaning. I will leave the video as-is, happy to own this oversight and take it as a learning experience. Thanks!

@LachlanMiller 6 ай бұрын

@@nicholasantidormi6238 After reading the feedback, I agree. I think your recommendation is something like: gist.github.com/lmiller1990/26eb3c2d76eb8c122a0012c1e47dc15e ?

@31redorange08 6 ай бұрын

@@LachlanMillerWhy do you wrap fetchAllFeatures() inside another promise?

@bavfalcon9636 6 ай бұрын

@@31redorange08 it's simulating an network call, imagine some fetch code was used here, you would want to wait for the response from the server by returning a promise.

@rahul_sharma_1 6 ай бұрын

Nice video and best explanation. But, Why to use another npm package for a small problem. Simply we can memorize the promised results. function memoize(fn) { const cache = new Map() return (arg) => { if (!cache.has(arg)) cache.set(arg, fn(arg)) return cache.get(arg) } }

@LachlanMiller 6 ай бұрын

Thanks for the comment. Sure, this works too. Both fine!

@virtualdev0 6 ай бұрын

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

@LachlanMiller 6 ай бұрын

Interesting - what was the use case for in memory, real time feature flags? What kind of feature did you want to turn on/off in a real time fashion for a given user?

@dfidalgo2 6 ай бұрын

Just store the Promise object directly. let promise; async function getFeatureFlag() { promise ??= getAllFeatures(); const features = await promise; // profit }

@LachlanMiller 6 ай бұрын

Yes - this is a lot better, I over-engineered this. Check the pinned comment! Happy to own a less than ideal answer, this is how we learn. The interviewer pointed out the deferred promise I recommended was over-engineered, which I'd agree with - no need to be able to resolve/reject outside the function call.

@hkhademian 6 ай бұрын

I do not see any reason for using pdeffer in your example . why do you just keep the promise instance and `.then ()` into it ?

@LachlanMiller 6 ай бұрын

You are correct, there is no point in this scenario. I don't have a good reason for using pDefer here, other than I used it recently and it was fresh in my mind. See the pinned comment for a discussion.

@NikitaFedotov-ok6ty 3 ай бұрын

Good video as always, thank you

@LachlanMiller 2 ай бұрын

My pleasure!

@bk1507 Ай бұрын

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

@LachlanMiller Ай бұрын

I'll just share it, this was Atlassian, most likely a lot of people go back and forth between the two! I'm guessing this question has been used at a lot of places.

@StingSting844 6 ай бұрын

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.

@LachlanMiller 6 ай бұрын

The global promise (or deferred one) accomplishes this, right? You only ever get one network request - the feature flags are cached in the resolved promise. I could be misunderstanding your comment - this should work for any number of flags.

@dmytro3568 6 ай бұрын

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.

@LachlanMiller 6 ай бұрын

I'm not entirely clear on why you'd need a scheduler here. The real time feature requests isn't something I've seen before but no doubt possible! It's definitely hard to show all this knowledge in a ~45m interview. I think you hit the nail on the head - the main purpose was to discuss caching and the pros/cons of each approach.

@parlor3115 6 ай бұрын

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.

@LachlanMiller 6 ай бұрын

Hi! That's definitely a valid approach. As an interviewed, I might ask: what if we want to store a feature flag in the database so each user gets the same feature flagged experience regardless of device, browser, etc? I'd say there is no right answer, it'll always depend. I agree with your approach, too, simple is good!

@Giovanni-ge4jy 6 ай бұрын

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

@LachlanMiller 6 ай бұрын

RxJS is a very great tool, although I have found it can be difficult to debug large systems built using RxJS exclusively. It seems to work great when combined with another too, like MobX, React etc.