diff --git a/Components-and-Hooks/HOC-Props-and-Custom-Hooks.md b/Components-and-Hooks/HOC-Props-and-Custom-Hooks.md
index dc12c7a..01a82b7 100644
--- a/Components-and-Hooks/HOC-Props-and-Custom-Hooks.md
+++ b/Components-and-Hooks/HOC-Props-and-Custom-Hooks.md
@@ -1160,6 +1160,14 @@ The issue of **naming collisions** that we can run into by using the HOC pattern
 
 Since **we can’t add lifecycle methods to a render prop**, we can only use it on **components that don't need to alter the data they receive**.
 
+# TLDR Summary table
+
+| Pattern | Pros | Cons | Use Cases
+| -- | -- | -- | -- |
+| **Higher Order Component** | <ul><li>Allows us to provide the same logic to multiple components, while keeping all the logic in one single place</li><li>By keeping the logic all in one place, we can keep our code DRY and easily enforce separation of concerns.</li></ul> | <ul><li>Composing multiple HOCs can make it difficult to understand how the data is passed to your components</li><li>The order of the HOCs can matter in some cases, which can easily lead to bugs when refactoring the code.</li><li>The name of the prop that a HOC can pass to an element, can cause a naming collision.</li></ul> | <ul><li>The same, un-customized behaviour needs to be used by many components throughout the application.</li><li>The component can work standalone, without the added custom logic.</li></ul> |
+| **Hooks** | <ul><li>Can help reduce nesting in your tree</li><li>Instead of having to compose multiple higher order components, we can simply write multiple hooks in the component.</li></ul> | <ul><li>Hooks allow us to add custom behaviour from within the component, which could potentially increase the risk of introducing bugs compared to the HOC pattern if multiple components rely on this behaviour</li></ul> | <ul><li>The behaviour has to be customized for each component that uses it.</li><li>The behaviour is not spread throughout the application, only one or a few components use the behaviour.</li><li>The behaviour adds many properties to the component.</li></ul> |
+| **Render Props Pattern** | <ul><li>Sharing logic and data among several components is easy with the render props pattern.</li><li>The issue of naming collisions that we can run into by using the HOC pattern no longer applies by using the render props pattern, since we don’t automatically merge props.</li></ul> | <ul><li>One of the downsides is deep component nesting.</li><li>Since we can’t add lifecycle methods to a render prop, we can only use it on components that don't need to alter the data they receive.</li></ul> | <ul><li>We can separate our app’s logic from rendering components through render props.</li><li>Render props pattern solves some of the issues we could encounter by using the HOC pattern.</li></ul> |
+
 ### [🙏 If you find it helpful, please give a STAR (click here) ️⭐️ ⭐️](https://github.com/anisurrahman072/React-Native-Advanced-Guide)
 
 Thank you for reading this article. I enjoy sharing my **5 years** of experience in **React-native**, **JavaScript**, **React** & **Node.js** with you every day. If you enjoyed reading this article, I would appreciate it if you could follow me on [**Twitter**](https://twitter.com/anis_RNCore) & [**Medium**](https://medium.com/@anisurrahmanbup).