Design patterns in React

A series in design pattern would be great

and i would like to know how to give answer please explain about your fronted project architecture ? give your sample react project architecture example .!

Lmao this is exactly what my company uses

SRP is a good pattern but can lead to the following drawbacks: excessive fragmentation, increased boilerplate code, decreased readability, difficulty in debugging, and an increased onboarding time for developers.

For small and even some medium-sized projects, sometimes it's just simpler and easier to AVOID breaking things down into multiple responsibilities and files. Sometimes it IS more readable if it's in a single place.

I would argue that PostFeed should handle the Post fetching itself. Makes more sense than the HomePage which is really just a visual container.

I don't think naming Design Pattern is right for this type of content. You are presenting good practices for React and Single Responsability Principle Anyway, interesting video, keep up the good work!

compound component is just adding more layers of complexity, just keep everything simple and easier we dont need a context or a hook for a simple select that absurd

Thanks a lot bro, really great video

Why is every react component put in a separate file, even the ones that are related to each other and could be easily navigated within the same file?

The only thing I would say about having your fetching and state in your parent component is that when you update that data, your whole page will reload, not just the componants using the data.

Love your videos man. Find them very helpful. I’m an experienced backend developer, finally biting the bullet and reaching myself react (if that’s at all helpful info).

Making my way through every videos you’ve made lol

thanks

why not fech posts in the postFeed. PostFeed is the owner of these posts. I'd do the fetching there

How come I'm not subscribed to this channel. Your contents are amazing

The last design pattern greatly helped me structure my code better. Thanks for the video. Appreciate if you can add some more design patterns.

The SRP is arguable here, for this example, homepage component should not be responsible for fetching posts, that's a responsibility for Posts component to do, imagine that homepage has other components that need some data from an API, so the homepage component will be a mess, therefore, we'll be violating SRP. Also the last patten is arguable indeed, if we do that for every component, then we're losing colocation principle which I think it's more meaningful than just move things around, instead I think smart/dump components pattern would make much sense in such situation instead of using custom hooks. Thanks for the video though

Never seen or used compound component pattern before. Very interesting. I'm curious in what other real world scenarios it would be beneficial to use. Thanks!

Select component are not good enough to show it even for junior developers, cause even within Design Pattern its a bad practice, cause you store the view and the logic of the context inside one file, that incorrect in any case.

I find it wild that it takes 70 lines of code to make a select component in React. Great video though.

Can we get this codebase or any github reop to view this example?

can I have github repos?

I have done all of those things before, glad to hear that they are good practices 😅

can we isolate the logic code in a components that uses that conditional rendering depending on states for example?

Awesome! You could highlight keywords.

Is the last example correct ? The useSignInHooks will be triggered on each render no!?

The Select context option feels unnesarily complex. Custom hooks + useContext for a native form element? You mention that it's nice because now it's a simple and reusable component, but you've created something that is finicky, difficult to understand and hard to maintain. That's the opposite of a senior design pattern.

I learned nothing, but it should be a good introduction for begginers maybe

Hi, I wonder about the last pattern 'extract useEffect to other files', if we have too many dependencies related to useEffect such as the variables from useState for checking, how can we handle that?

The useSignInPage does not have a single responsibility.

Talks about SRP, doesn't do SRP in its best way: your outer component does not do one thing, but two: it renders the component and it fetches the data. Therefore you break SRP 😬

how did you make the functions sticky in your vscode ?!

It's always interesting to see where someone draws the line on single responsibility.

i think the right name of the pattern is not feature components, is compound components,

That was a really interesting video! Thanks for sharing.

A question about extracting logic into Hooks - how do you share state from the hooks back into the component itself? Would you return a big object full of properties similar to how useState works?

Great video! However, there is something that is bothering me. Why should we reinvent the Select behavior when it's already implemented by the browser?

But the pattern is awesome and should be utilized.

Great video! I only disagree in the single responsability part, because in many cases it's not worth the effort of splitting things up, and you didn't dig into how to decide when to use the pattern.

Last one : chef's kiss.

If you have a PostFeed component that is responsible for rendering the posts, why fetch them in the parent component? If PostFeed has the responsibility to deal with the post feed (obviously), isn't it better to let it fetch its components and remove this responsibility from the parent?

Wow , Great explanation !
Thank you : )

'single responsibility principle' is an priniple. a.k.a. a guideline. Not a Design Pattern.
EDIT: I see 0 Design Patterns here. Just code separation, no technical problem solving.

I don't think it matters seniors are still going to use the most fkd up pattern in the existence

// @ts-no-senior-check

Thanks to show this!

Hey Cosden, thanks a lot for sharing your knowledge with us. Which monitor do you use for your mac? I have been struggling to find a decent one with crisp text for my mac mini :(

Great video. being fairly new to react (but not dev in general), I'm still finding it confusing when you and other creators keep calling them "custom hooks" -- to me they are just functions put into a separate file. Today I created a small util "function" that I can pass an array of objects to and a column name to get back the sum of that column (e.g. cart prices for total value of cart), I'm finding it difficult calling them "useXYZ()" when to me something like calculateTotalCartValue(cartData, "price") is better.

Really love theses kind of videos! Thank you! One question, and sorry if it would be obvious, but I really liked the last pattern, bit how would it be implemented if I need a control state? Or that would be more like the second pattern shown?