You're using Javascript Promises The wrong way

🧭 Build Login/Register API Server w/ Authentication | JWT Express AUTH using Passport.JS and Sequelize

🧭 Turn Design into React Code | From prototype to Full website in no time

🧭 Watch Tutorial on Designing the website on Figma

🧭 Watch Create a Modern React Login/Register Form with smooth Animations

🧭 Debug React Apps Like a Pro | Master Debugging from Zero to Hero with Chrome DevTools

🧭 Master React Like Pro w/ Redux, Typescript, and GraphQL | Beginner to Advanced in React

🧭 Learn Redux For Beginners | React Redux from Zero To Hero to build a real-world app

🧭 Introduction to GraphQL with Apollo and React

Made with 💗 by Coderone

[joelm]

6:04 - There's no reason to create those extra variables for productsPromise and categoriesPromise. Just do `const [products, categories] = await Promise.all([fetchProducts(), fetchCategories()])`

[ayoub.k]

Hey man, I understand the need for using click bait titles, but that has a negative impact on junior or beginner developers. You say people are using something wrong, then you skip over use cases where the approach you say is wrong might actually be the best approach, and then you process to explain the better way which isn't the better way at all in some certain scenarios. I commented on another video of yours that anything has its own use case, so, please do better research and present a well rounded explanation in your videos in the future. Peace.

[BogacGuven]

A good reminder about promises' not so intuitive use-case. 👍 If anyone didn't get it from this video I'd also recommend Dave Gray's video "Callbacks, Promises, Async Await | JavaScript Fetch API Explained". Specifically a very similar example is at t:37:06. I'd recommend to watch that video from the beginning if you still didn't get why this happens.

[esequielalbornoz]

The issue with this approach is that if the products API takes 2 seconds and the categories take only 500ms, you won't be able to access the result of the categories until the products API returns the response

[ukaszzbrozek]

Instead of using Promise.all you should use Promise.allSettled. Promise.all if any error occurred would throw only the first failed request error. With Promise.allSettled you can show to the user at least partial data and console log for the programmer all problems with the BE.

[faythe]

That's very insightful, for when the data between the promises is not always dependant

[osquigene]

That's literally the first thing you would learn about asynchronous programming so I doubt people would not know about this.

[MrShaheer]

thats great knowledge thank you for sharing it. FYI: you could speed up and run getProductsByCategory by just making another API to get productsbyTopCategory, the API should calculate the top category on the server side (or use a cached version generated by previous call of getCategories) and just return products by that category, that way all three requests would go at the same time.

[huncho]

Thanks for sharing your experience on handling async fetching

[shivangm]

Got to learn new way to optimize for parallel use cases. Tanks!!

[ThiagoLucioBittencourt]

Amazing examples. Open knowledge about. Thanks to share.this

[focusiam]

Hello, thank you for this tutorial. Do you have the video where you build this app?

[orielsy]

I would have loved if you had broken down the issue briefly at the start then went in depth into the solutions.

This would saved me from watching the full video. I understand you want people to watch it but I'm already a seasoned developer.

[letri]

I don't think it's a wrong way:
1. sometime u need to sequential (line by line for api dependency).
2. promise is run by the way it's created (sequential & parallel).

[AngusMcIntyre]

In real life, seperate components would load both payloads. You won't see this category of error for ajax data loading in a properly architected app. The TLDR should be "only schedule a continuation if you depend upon the prior operation"

[jorgericaldi]

i have question. You need to wait anyway for products before categories, of course that is faster now because the promise.all or the other way, but is still waiting for products first. So will it be a best solution just move every call on his own useEffect even productsByCategory(with dependencies) ?

[amitei]

Okay, I just wasted a few minutes of my life on a video that moves two awaits to Promise.all for no particular reason.
As other wise men already said, the video is a bit misleading and the solution you provide is not the best because you are still waiting for ALL the promises to be resolved and then applying them to UI.

If requests are separate, do not depend on each other, and can be executed in parallel (as shown in your example), just put them in separate useEffects and that's it. The order does not matter, whenever the query is completed, its results will be displayed in the UI. There is no need to complicate such a simple thing.

Moreover, this approach is easier to understand, because in the context of one request, you are not interested in the other (they are independent, remember?). And if there is a need to change or refactor something, it will be much easier. For example, you could use a different set of dependencies to refetch, or just copy one request and paste it somewhere else.

[noriller]

Last case, if possible, would try to have a backend API doing that.

[Lindaine]

Isn't this concurrency instead of parallel?

[yolopolo]

Can't we just create two seperate async functions