The Most Important Design Pattern in React

[@doruktekel3438]

summary : use custom hooks , use components for seperate all things , use inline func for basic things

[@shino_ojisan]

Thanks bro for saving my 35mins.

[@jerbear97]

@@shino_ojisan lmao watch the entire thing, it's worth the 35 mins

[@Warpgatez]

“Basic” but commonly missed on GitHub lol😂

[@aniyu197]

Your summary is worth than this video

[@shino_ojisan]

​@@jerbear97nope.

[@julien.roques]

Did I just click on a thumbnail that mentions "Senior" design patterns only to watch a 34 minutes long video that explains we shouldn't write the whole app code in App.tsx? Oh, my...

[@George-Al3xander]

Yet the funny thing is that you've described almost every "React advanced concepts" / "React clean code" video.

[@greatdouble8966]

Agreed, that's cringe

[@jessepinkman8158]

Lmao exactly. Thanks for saving my time

[@omkarsheral8559]

exactly, i also wasted my 35 mins

[@SaraanAsim]

Almost 5 years experience and I still learned something new ! Learning truly never stops. That bit about passing reference instead of calling function while initializing a state was new for me. Thanks!

[@innerstorm]

I was so waiting for the actual design pattern, that i've watched this whole 30min lesson on proper refactoring. thanks.

[@rjwhite4424]

You've helped me shrink components from 100's of lines long to just under 50.

[@cosdensolutions]

let's gooo

[@1234321bam]

OP, great job! One thing I noticed that is worth mentioning: you wrapped the functions in the useCount hook into useCallback to avoid unexpected rerenders in case the functions are dependencies of hooks. However, you have forgotten to add dependencies to the dependency arrays of the useCallback, which leads to incorrect values being passed when calling these functions more than once. This is a very common mistake among both juniors and seniors. You will want to either add dependencies or just use the updater callback function, e.g. setCount(prevValue => prevValue -1);

[@lulzmoney99]

Eslint will flag this for you… no excuse for not setting up eslint really…

[@PANKAJSHARMA-yu1ns]

I had the same doubt that why didn't he add count state in the dependency array, but being a junior developer I thought that it was intentional, thanks for clarifying that it was acutally a mistake.

[@tzaru9602]

Hmm, an important point to consider: he's focusing on abstraction. Over-abstracting or refactoring too early can backfire. When you aim for overly sophisticated systems, you often build features you won't need. Plus, you’ll never move forward if your mindset is: 'I need to write perfect code from the start.' The goal should be simplicity-make it work first, and as the project evolves and requirements become clearer, then refactor.

[@MonsterSmart]

Yep, 100%. Just make it work and wait for requirements to stabilise. Then when reason for refactoring will emerge itself then act. Abstracting too early is very wrong and will backfire. I've seen it so many times. Even more, I've done it so many times that I will not do this mistake again.

[@kapsxd]

I agree, I feel my brain is too small to think of a perfectly designed system from the beginning, however there is merit in knowing when your code is too spaghetti, as in when it does come time to refactor you end up literally rewriting the whole system

[@tzaru9602]

@@kapsxd It's always a bit of a balancing act. Trust me, your brain is fine. If you’re working on your own projects, as long as you can come back and figure out what’s going on, and easily fix or add features, you’re all good-no sense in wasting time. But if you’re part of a bigger team, there are usually specific guidelines for how to write code anyway.

[@eduardowada358]

​@@MonsterSmart Organic architecture, the best way to go, the problem is that most developers including senior developers are unable to recognize when the reason for refactoring shows up and will typically just slowly add to the monolith.

[@AndreiMarDava]

100%

[@atefevan8498]

Your coding style really pushing my react journey to another level ! Wish you to long live

[@nikitaliakhovka3489]

hey Darius, just a small tip for you, you can use Ctrl + Shift + P and type `organize imports` to quickly clean up unused modules ;)

[@zeeshannagori007]

Didn’t knew this one. 😮 Thanks ❤

[@Мартынов-х3ъ]

Sounds like doing it manually is faster but good to know

[@cosdensolutions]

I actually prefer to do it manually and turned that off! Too many times I'm WIP on something and I know I have it unused but I will need it later and get annoyed when it auto gets removed 😅

[@Tushar.Sharma]

I just use Alt + Shift + O. I’m using Jetbrains keymap so not sure if it’s same in the default one.

[@maulx]

​@@Tushar.Sharma yeah, vscode has the same shortcut for it

[@aneurysmjs]

I've been watching your videos long ago but now you already convinced me to subscribe. Great job.

[@JackTheZuluman]

Thanks for your content, man. You've officially become one of my top five go-to channels for help on KZbin.💯💯💯

[@amirheidari464]

Bro you change my view point . Omg . Actually your coding style will change my react projects coding

[@bakedbash]

Coding in react after 1.5years, your videos are very helpful in my journey 😀

[@ebn646]

This is really good stuff you need to know about how React works under the hood. Good Job!

[@user-cn6my8kz4e]

As someone just starting to learn React, this is extremely useful. Thanks

[@ianski9898]

thanks for a free tutorial!! Love your vids!

[@lumiere930]

On your own projects then it makes sense to remove features that do not make sense but if you are at work and you start removing pieces of code that seem weird to you, then you will have a very angry Product Owner lmao. Behind every strange design decision in a code base is a developer who probably implemented it against his will after hours of meetings

[@petarkolev6928]

Cool video! I absolutely agree on these patters BUT in this example we had a huge chunk of component. Now imagine if you have to follow everywhere - no matter how small a component is you will end up with huge amount of files because you need to follow this rule of separation of concerns which is a really nice rule but one should add a logical condition when to separate and when to write in one place :)

[@JIVESHRAJPUT-w1k]

At 12:42, you did a mistake, while wrapping increement function in useCount hook you directly set setCount(count + 1) but it will never get the updated count inside increement because you didn't passed the count in dependency array of useCallback. To fix this issue there are 2 ways: 1. To pass count as a dependency in useCallback. 2. Write setCount((prevCount)=> prevCount +1). I personally prefer second one. Let me know if I said something wrong.

[@utkarshsinghchouhan8819]

I am little embarrassed, I am working in a company as a Junior Dev and I have written the code similar to the unoptimized version... it is so relatable 😅😅😅😅

[@asd7897891]

omg! i just surprised that u used Persian tattoo! 😍😍 "این نیز بگذرد"

[@TheGrizzlyKnight]

Absolutely PHENOMENAL video. Thank you for your effort and clear explanations!

[@jnnk-hb]

What you explained should be the basics even for juniors. Also your title is misleading. What you explained has nothing to do with design patterns.

[@daydreamer9469]

Refactoring sequence is important to be efficient. Divide into smaller components first, then create custom hooks when similar logic appears multiple times or to reduce clutter by grouping chunks of logic outside the component. That has been my rule of thumb for organizing React codebases.

[@tenjames]

12:30 increment and decrement will always set to initial count + 1 or initial count -1, since count is not in dependency array or there is no function in setCount.

[@rupture007]

I also thought when setting state if you are relying on the previous state like this you need to use a function like setCount((prevCount) => prevCount+1);

[@tenjames]

@@rupture007 Yes, thats good practice since state won’t be changed immediately after setState is called, so using (prev) => new; is safer since its using actual value of that state.

[@cosdensolutions]

yeah you're right, forgot that one!

[@rupture007]

@@cosdensolutions Lots of stuff to remember, I'm still learning myself. Great video.

[@PANKAJSHARMA-yu1ns]

@@tenjames are you saying instead of adding count state in the dependency array of useCallback, we should update the state by adding to previous state, I just want to know which one is better? adding to the dependency array or updating the previous state?

[@MattElisa97]

I love these videos !! More best practices 🤟🏽🙏🏽 That's clear and well explained. Merci !

[@pokerbro4544]

I would really like if you made a video about rtkq and its caching behaviour and also how it differs from tanstack

[@Yarde524]

Wow! Awesome video. I feel like this might be a good interview assignment when recruiting frontend devs.. give them the code and see how they approach improving it.

[@thomasweigert731]

Congratulations on 100k followers!

[@sandeepbhambre]

You should furthermore optimize the code by using a function inside setState functions to set states based on previous state values correctly. E.g: setcount(prevCount => prevCount +1);

[@daydreamer9469]

I was like this too. But now I’ll do this only if the setCount is used in multiple places and can be called more than once at the same time. Creating unnecessary callbacks can rack up the component complexity.

[@dungeonsanddronesrpgroup]

This is only required if you have a chance that the state would be out of sync.

[@SumanSen-ve1se]

Great video with clear instruction, thanks. Just wondering what if we had a requirement to change the document title dynamically, what's the best practice to do that?

[@code_traveller]

I really appreciate all your effort, but what I think it can we further optimized using the useReducer and useContext hooks right now using multiple useState will render the component tree multiple times.

[@Nellak2011]

I had no idea about the function reference in useState. Thanks for the pro tips.

[@daniilc342]

Thanks for the video! Learned a few tips for myself!

[@mihaillepadatu8256]

Randomly realised I ain’t no junior anymore. Great content!

[@mycloudvip]

Loved the concepts shown in the video! Thanks

[@vladyslavpetruk5664]

congrats on 100K 🥳

[@skylerockspecial]

11:41 shouldn’t be a useEffect. Move this logic to a local setstate handler so that the localstorage is in sync with the render. This is not a side effect of state changing but a side effect of an action.

[@doc8527]

You got the point. those in fact should be put inside the increment/decrement function right after setState, hence unless you there are a lot of more logics that could be combine as a single new hook and need to reuse them. Leave those functions/states like that inside the counter component instead of creating useCount() hook, it's totally fine. His misunderstanding of local setState handler as a side effect leads to potential wrong abstraction. it is indeed premature optimization. As setting value in localhost is not a universal thing, and specific to that counter component. I think some of his "better" looking codes are falling into the same issue. I actually fix similar issues countless times through PR reviews as they introduces tons of useEffects and abstractions when you handle complex real world business.

[@Firehoops]

I get this is a over simplified example for the video, but the emphasis on having tiny files is a bit of concern promoting this to junior devs. They could take this and run with it. Good rule of thumb is 150-250 line components (excluding imports). Debugging & maintenance on large react applications with a bunch of tiny (

[@ZentoNFTs]

Nice video! Thank you for sharing this.

[@ALCATRAAAZZ]

This is definitely relevant content! I have thought about the principles a lot and while naturally improving my projects have come to a state where I created a function called handlers.js which consist of my handler functions. This sort of replace the useState inline functions with a function imported from handlers.js. Right way or not but it really improves the readability of code and removes the Smell of LONG Method. I guess unintentionally I have created custom hooks in that can be used all around the App

[@rockNbrain]

great content bro!!

[@krzysztofrozbicki1776]

This was nice and easy and very informative Thank You! But i think that the main issue of messy code (one component to do all) is elsewhere. The issue starts when your main component and all children component interact with each other so the children component interacts state with other compoennt or parent component. And i really would like you to make this video 10 - 15 minutes longer to show us how to use useContext efficient and if this a good practice to use useContext in all larger components. Because mainly this is the issue i am encountering in legacy code or even in my code - that all is stuffed inside one component because there are so much state changes and state shown - just like this DarkMode. There are also issues like - i am reusing this component - but small details changes (e.g. it looks or behave a little different depends on type of user). Should you then make a new component to have clear code, or stick to the DRY and just add new conditions to it. What would you recommend.

[@cosdensolutions]

Usually, state is not the problem. There are solutions for everything you said. Some state is only local to one component, some to just a few, some to most, and some to all. You can use useState, context, redux/zustand to manage all of those. If you follow the process I've done in the video, patterns will emerge. You'll move something to one component and then see it needs X state. So then you ask yourself "who else needs this?" and then make a decision then on where to put it. Each solution is valid and none is better. It just depends on the component and what it needs. And regarding your last point, if it's just pure UI differences, in that case just use a compound component (I have a video on it). That will allow you to render it how you want while keeping the same functionality. If the behavior is different based on where it' used, then it might be worth to create a new component. Again, it all depends on the specific case

[@krzysztofrozbicki1776]

@@cosdensolutions Thank you for your response! I didn`t know about compound components before. Still a lot to learn ;) I have just watched your video about that and it answered all my doubts i had and will help me with my current project!

[@Misskieutra]

Very useful. Thanks!

[@whatgoglikeno6120]

I feel 19:50 is a cop out. That is exactly the problem with this "extract every little thing" "SRP i s god" way of coding. You run into a real world requirement that just doesnt neatly fit into "the forms one and only responsibility". So now you have to compromise and suddenly you have so many philosophical questions and options. Keep it in here? Ehh kinda doesnt feel good. Move the code that sets the title somewhere more appropriate? Well now how do you get access to the forms name field? Do you exctract the forms state into yet another hook? Just the name? Create a UseTitle hook and use it in this component? Well... probably. But then you are setting the title after all in t his component so what did you gain? What if this is the only place the title ever gets changed? Why create a hook then? Who has the responsibiliy of setting the title in this case? the useTitle hook because it calls "document.title = "hello..."?`Or the component using the useTitle hook? Deep philosophical questions are the problem when you pray at the altar of the single responsibility principle.

[@truthybyte]

Well it's unexpected behavior, so you would expect the component controlling the state/hook to use a useEffect to change the title.

[@Vitalik186]

GRASP answers this - yes it's from OOP but it's actually about how to organize domain logic and can give many tips. SRP - it is about a different story, you wanted to say Separation of Concerns - this is an outstanding design principle, but the problem is that sometimes it's not clear how to use it.

[@rand0mtv660]

To be honest, his solution to that problem 30 seconds after was "let's just remove the effect, it doesn't make sense to update document title based on user input". I mean yeah this is a contrived example and so this code doesn't make sense, but in a real application you cannot just decide to remove things because things might seem necessary. I do agree with your take and extracting based on things being concise doesn't make sense. Sometimes a 500 line component is ok because it's easier to understand it that way compared to separating it into 10 x 50 line components that you have to connect in your head. I think some of his ideas and takes are ok, but these "guidelines" are exactly that, guidelines. They aren't meant as hard rules even though junior developers watching this might think this is the only way to do things because they don't have experience yet.

[@ra-pe9bi]

Great tutorial, as always! I just wonder, did you write this "wrong code" or found it somewhere on the internet?

[@cosdensolutions]

Wrote it 😁

[@beluga_0007]

congrats 100k🎉

[@yashainapure]

You really make informative video,great

[@Massimus888]

Great video! I'm coming from a C/C++ background and recently started learning React and Typescript. One question: I noticed you're using destructuring with your custom hook, like this: "const {count, increment, decrement} = useCount();" What do you think about using the entire object returned from the custom hook instead, like this: "const countManager = useCount();" 1. By using countManager.count, countManager.increment, and countManager.decrement, it's immediately clear that they all come from the same hook. 2. If you're using multiple custom hooks in the same component, keeping everything inside the countManager object avoids potential naming conflicts. 3. If the hook grows to return more values later, you won’t have to constantly update the destructuring logic. Lastly, another cool approach is to return an object from the custom hook with methods, like an API. This would give a clean interface with explicit getter and setter methods. For example: Instead of returning this: return {count, increment, decrement} Can do: return { getCount: () => count // Getter for count increment, decrement, };

[@cosdensolutions]

I don't think there's a rule or something on this, but generally things are usually destructured in JS. I personally haven't had naming conflicts because I keep my components really small and destructuring helps write shorter code instead and of always "countManager.something". There's no real perf difference so it's personal preference I would say. I just usually see destructuring and less so using one variable. So you can do it your way if you like! Just be flexible if you work in other projects

[@rand0mtv660]

Yeah I like this pattern. As you mentioned, it's immediately visible where the value is coming from. Just seeing "increment()" function being called in code doesn't tell you much. Only issue I've ran into with this pattern is if you use that value (e.g. countManager.increment) inside useEffect. ESLint plugin cannot in all situations detect that only this value should be in the dependency array and will tell you to put "countManager" inside the dependency array. This can lead to the effect being triggered unnecessarily and even produce an infinite loop. In that situation, destructuring or refactoring things is a must, but destructuring is easier because you can just continue using your custom hook without many changes.

[@piotroszko2]

If u ran into naming conflicts, that means that your component is too big. Also "countManager.count" example is fine, but when working with complex objects (ex. from API), we ran into "java problem" where one variable getter can be very long (aka. not readable). Also, u can always do const { name: userName } = useUser(), if variable name from hook is to broad for given context. A lot depends on context, and need. As mid frontend developer that worked in multiple big projects, destructuring is your friend, not a enemy.

[@unknownguywholovespizza]

What's wrong with using count instead of getCount? I see no benefit. Only over-engineering.

[@lulzmoney99]

You’re making things needlessly verbose by not destructuring. Any modern IDE is going to show you in many ways what you’re dealing with. No one is going to be confused. Like others said, if you’re running into naming conflicts it’s probably a code smell and if it’s not you can rename things when you destructure if you really need to. You sound like the kind of person who uses “this” in Java every time they use a class variable or method, makes everything final and religiously names every variable after the data type 😂 because it’s like… more clear… never mind how readable things get when simple one line statements get spread into 7 lines because of pointless syntax and ridiculously long variable names for “clarity”… Returning a getter is just pointless. Why make it necessary to call a function when you already have the count? There’s just no point in this. You’re making things unnecessarily difficult and verbose.

[@Uxidlegre]

Your title is misleading. There’s no pattern content here, this is just clean code writing…

[@codewithmoses]

This is very useful. Thank you for sharing

[@houssembahri-l9t]

Great video !

[@adnanrruka5152]

Cool Stuff man,

[@Jacek2048]

Phenomenal video, BUT you have a bug: after introducing `useCallback`, the counter is broken. This is because the closures always see `count` as whatever it was during closure creation, i.e. 0. We need pass a callback to `useState` to always increment the fresh value: `setCount(count => count + 1)`.

[@harag9]

Great video, many thanks for this. I hope you never see the App I've been given at work, the code smells in that would kill you. 1500 lines long etc. I'm slowly breaking it up similar to how you have done this, but taking time as I'm also having to learn react. Been a sub here for a while now, would love to do your course, but I just don't have the time at the moment, so for now, I've decided to sub to your newsletter! :) Like you, love the name of it. Great work bud! & Congratulations on reaching 100k subs!

[@crowleyeusford7886]

Hey cosden i have a quick question at 15:30 What if we want to use "count" variable in other components, how are supposed to place useCount hook, App or Counter?

[@derekcommonground]

Yeah, I think there is an issue with this example where if you try to apply it to the real world it breaks down. The counter is great as a custom hook example that only exists in a little black box, but if you try to reuse the component you actually end up with two separate counters and the count value is not accessible from other components. Then you end up needing to lift state and pass the value as a prop or create a context to share the value, so you end up with some top level state, just like how it started. So I think the concept and real-life use case is not clearly explained here

[@karolbielen2090]

@@derekcommonground There is no way around what you described unless you're willing to work with some global variables

[@andyazma4198]

Hi Darius, thanks for the great video, I just noticed your tattoo on your hand in Persian :) I could guess the full sentence but what a great phrase, I like it , keep up the good work

[@BEVILE]

a great video worth of subscribing , thanks!

[@truthybyte]

Can you go into how to handle state from parent components? Splitting up into components is a common concept, but best practices for handling state across multiple is often convoluted. Think if we want to do a final submit from the parent component which holds data from multiple forms or components.

[@cosdensolutions]

Either create something like an OnboardingForm, which has multiple pages/screens and use context or your form library's hooks to modify that one state. Then the final button just submits that one form. Or you could pass the data through the URL as well and have individual forms if you're saving each step. Or use Redux/Zustand to store it globally and use it in those components and persist it to local storage if needed. There are solutions, it just depends on the specific use case!

[@eliuddyn]

Amazing 🔥🔥

[@Rahmanullah-qy7rd]

I one year of experience I see your this is very very helffull for me to write a profissional code

[@jason.zubiate]

bro was cooking with this one

[@lakshaythegupta]

moving functions inline will recreate them on every render. Right? Wont it be overhead in contrast to creating separte function on top?

[@cosdensolutions]

they'll get recreated even above. Only with useCallback they won't. But most of the time there's no need for that

[@prashlovessamosa]

Can you please share some of the syllabus what's coming in the next modules of the project react course any info that you can share.

[@cosdensolutions]

it's going to be an update to React 19! So that will cover everything that React 19 changes and set you up for modern React

[@1234321bam]

I'd argue that making a function inline just for the sake of fewer lines is not a pattern but rather an antipattern. 1) It's not easy to cover it with tests. 2) You make it worse for the reviewers of your PRs and future self because they will spend time understanding your code (which isn't always that trivial). A properly named function describes its purpose and responsibility.

[@kalideb-y3y]

should we only refactor our codebase after we finish? to avoid premature abstraction

[@shakapaker]

Good question. I think that after the feature is working as intended

[@cosdensolutions]

refactor as needed. It all depends on the project and what it needs at any given time

[@shakapaker]

@@cosdensolutions Could you provide some examples please?

[@ThuongNguyen-km7vg]

13:01 Thank you for such useful video. But I think you should put the count as a dependency for useCallback.

[@cosdensolutions]

oh damn, you're right! I forgot that, thanks!

[@yitzchaksviridyuk932]

@cosdensolutions Actually probably better to not even do that because by making count a dependency, you’re still making react recreate those functions each time count changes. A better optimization would be to use derived state by providing a callback to setCount like setCount((x)=>++x) in the case of increment. You’re still creating an inline function within the setCount, but it’s very small and it makes your dependency array empty which always makes things easier to manage down the line. Case in point actually: if you were to add count as a dep to inc and dec, each time count changed, you’d be recreating both functions. However, using the derived state makes sure the only function you’re creating is the tiny callback within setCount when you’re doing the actual action of incrementing or decrementing count.

[@ThuongNguyen-km7vg]

@@yitzchaksviridyuk932 I agree. Thanks

[@henriquematias1986]

The first implementation regarding local storage is likely to give a hydration error if this component is running on the server first, cause on the server it will always be 0 but on the client it won't be 0 on the first render, hence why you need an useEffect. Also localStorage is not defined on the server, so this won't run on the server side?

[@muhebollahkhandaker]

I think, every junior dev has already implemented such code.

[@kmcg101]

When you are separating the COUNT variable and putting it in a custom hook you say that 'we are going to be able to use that count variable inside of this component (app) and potentially any other component that needs a count.' Do you mean that once the count variable is in a custom hook it can act like a global variable? Or do you mean that any component can have its own count and not the SAME count variable?

[@mehrdadarman]

The email and name values can be updated in only one object in useState

[@SaqibHussain-h5v]

I have two year of experience in reactjs and nodejs, while using reactjs, I always use custom hooks for business logic, In this way the design part is compltely seprated from business logic, am I doing right??

[@Pareshbpatel]

An excellent demonstration of the use of Design Patterns in React. So clearly explained. Thank you very much, Darius. {2024-09-12}

[@ALCATRAAAZZ]

What is too much splitting the components? I have created subcomponents of a component. IE, I have a component A.jsx with a Title, Paragraph, Button. Should I create a subcomponents for A.jsx with Title, Paragraph and Button .jsx? When to do it and when not?

[@YoungSesh]

Cooool!!

[@johndevnoza4223]

First 25sec and im highly curious what is it about! I wonder if i ll be able to understand such a concept as someone with 0working experience

[@BrunoOliveira-lm6wl]

In React components you should only perform code that has possible side effects in a useEffect. Reading from localStorage in render is not a good practice.

[@strategistaow3520]

How to make VSCODE like yours? You have very comfortable VSCODE

[@cosdensolutions]

check out my vscode video!

[@strategistaow3520]

@@cosdensolutions kzbin.info/www/bejne/hJ_Kp3mZocuXnassi=sEoT-1VNALxcUCrC are you referring to this video? In that video, there isn't any guide on how to move the left panel to the right side. By 'left panel,' I mean the div that holds extensions, files, Git, search, etc.

[@sahajranipa]

21.21 at this point you could have done that using a single state function like that setFieldNames((prev) => ({ ... prev,[name]: value})) in handleNames(e=> ( let {name, value}= e.target;))

[@bongbuincyril6150]

After some time this will be termed as bad practice Nice lesson though Love u man

[@xbsidesx]

Removing functions that call setState is not that great. Function handlers are way more declarative than inline anonymous functions, that are harder to debug (they have no name). Also, the anonymous functions are recreated in every render, although that’s early optimization (which is a little ironic here)

[@Wakkyguy]

Shouldn't we use the functional form of state setter when our state updates are dependent on the previous value of the state?

[@cosdensolutions]

you can, but it's not always necessary. But if you want to be safe, yeah use it!

[@Wakkyguy]

@@cosdensolutions 👍🏻

[@andrija8506]

It would also help if you post the original code, so we can follow along easier

[@ulfjohansen2139]

If only the real world was simple and state didn't need to be shared between components at different places in the render hierarchy. If only performance wasn't an issue and there were no reason to use useCallback (useMemo and memo), if only you didn't end up with a completely incomprehensive mess of tiny components and hooks that are only used in one place or perhaps a few with close but not exactly the same use case. This is all good advice for the code examples, but the code examples are very simple and if you think SoC is the holy grail to readable code, you are in for a rough ride.

[@_andrewpeacock]

Would love to hear your opinion on NextJS vs Remix :)

[@imadimad8814]

Please if you can make a video, short , article , blog , or what ever feels you good , about services api in reactjs, i tried a lot of techniques but i am still confused about the performant one , i used services layer using only ts , i tried server actions , i tried to use hooks , simple functions , write service logic in component, i tried rtk query ..... but i dont know yet what is the good one , please if can reply to my comment i will really apritiate that

[@sanmarchen]

Спасибо 😊

[@rick-n4i6d]

Everything’s all good and great until you’re drowning in 1,000 useSomething hooks scattered everywhere. To get the whole picture, you’re left swimming through endless fragments. And it only gets better when every single one is tucked away in its own folder with an index.tsx file, so you end up clicking through 100 identical index.tsx files, wondering, ‘Wait… did I open this one already?

[@1Nekotama]

sometime spliting code in to lot of component can make a 'props drilling', I wonder how other handle this problem

[@veniaminbalan]

video suggestion: ask chatgpt to make a react app and then refactor it

[@EmanuelGaron]

> Removes dark mode functionality

[@CarlosVergara-id8cf]

One question. It seems you are using TS, however I don't see any TS errors? why?

[@jerbear97]

ngl the first part got me like "why does he have my code"

[@rohitshrivastava4318]

const [count, setCount] = useState(initializeCount): const [count, setCount] = useState(initializeCount()): Can someone please explain difference between these two in detail? Not able to understand what he said

[@glaze4629]

I barely write custom hooks, I think I may adopted them more often.

[@mdtajbirhossain8228]

Thanks to the commenters for saving my valuable 35 minutes🙂

[@AlaaHosam-xr3tx]

in a big project how to organize hooks when they are too many?

[@crism8868]

If you need to abuse useEffect, you're likely not thinking in React. That was one of my takeaways of this video

[@AliBagheri2079]

تتوی خیلی زیبایی داری❤❤❤

[@grandpowr]

Would be nice if you did a testing video for Frontend