React? The spread thing is a Javascript thing. I had Performance issues on node doing that. But I was doing thousands of operations quickly, so in that case there was a huge performance hit. But in a Javascript web app, React or not, if you are doing a few spreads, you won't notice the performance hit.
Nesting components is really new to me. I've never done this because the principle of the components is to separate responsibility. You may call them but setting a component inside another is counter-intuitive.
Yeah it’s bad practice. I’ve seen it used a lot where components are passed as props, but people have to understand that it’s just really inefficient 😩
@@odra873 passing in a component as a prop is fine. However, you shouldn’t define that component inside a component, which some people resort to when passing them as props.
The "never use the Spread Operator" symptom is why I so dislike today's JS community and gate keeping. The time complexity of the original operation is unnecessarily O(n^2), after the fix, it becomes O(n). It even has nothing to do with Javascript, it's just your typical Computer Science fundamental. Spread Operator is doing what it's supposed to do, the O(n) operation! That's why you should never abuse nested reduce, filter, map, forEach in complex logic if you know you will involve some sort of O(n^2) operation. Devs, learn the fundamental please! I have so much pains speaking with today's "senior" JS/FE devs, as many just blindly believe some random articles on the internet without thinking.
I love how you discussed clear pros and cons of everything (even though some react patterns are just dumb to use) instead of blindly believing something about some technique like the cults.
This is much needed it, thank you sir, I lost track of the times I cringed over some of these clickbaity video titles "This is game CHANGER AND ALL YOU NEED 😱", how about these tech influencers just relax for a second.
Don't try to be a "senior developer" and show your tricks of useMemo or trying to render a component just once, overengineering just will be bad at the end
When I was learning and younger, stuff like this was what made it really hard to learn. I it took me a lot longer than it should have to switch to tailwind because of stuff others said about it that I just took as true.
Great video but your example of using useCallback is incorrect and is actually an overhead. The `sort` function doesn't use any variables within the component since `a` and `b` are passed in so it could be defined outside of the component. You could even go the extra mile and put it in another file to import wherever you need it. A good way to determine if a component needs useCallback or can be defined outside of the component is the empty deps array.
I'm not sure I would call it "incorrect". I would say that it could, and in that case, should, be optimized to be external to the component as you suggest. The example was purposefully simplified so that I could talk more about the references to functions and how they can be stabilized with a useCallback. The ideal example would have a sort selector and the sort function would be dependent on that. But even that too could be simplified to a ternary (or lookup) to select between two (or more) external sort functions.
Good refresher! That implicit arrow body creates and returns a new obj () => ({}) after each iteration! Was not sure, how ot works with reduce, but now it is clear!
I watched your video about Jotai state manager, and I liked it. it is simple and light. I wish there was way for us to review our code with some expert and see if we are doing it right or wrong.
Also, this helps me, I think of components like muscles. You want to use your muscles, not extend them. Extending them leads to injury from misuse, regular use leads to strength. Hope that helps someone.
"Use XY as it is meant to be used". Wise words. When eslint became popular I was wondering about rules crippling JS. Rules forbidding the use of certain language features or operators. And often the reason was "people make mistakes with that". I always said "Well, then learn the language and learn to avoid those mistakes, but don't cripple the language."
Every video you see on youtube they always have strong beliefs on one thing. I think you are the only person I have seen that doesn't do that and it aligns with me the most.
A voice of reason. Too many Twitter accounts and YT chans pump out absolutist content for views and likes. I always come to your channel for well-reasoned takes. Keep up the great work Jack!
This one is a 5/5 cult then, because at this point, they're almost right. UseEffect is primarily used to get data from an external system, like a fetch. If you're doing it in your code, it's pretty universally recommended to use a 3rd party query library like RTK or React Query. These abstract away useEffect correctly so the user doesn't have to. There are some legitimate other uses involving refs and timers, but those situations are somewhat rare. The one that happens CONSTANTLY and that new and even intermediate React developers do (I was guilty of this a lot) is use a useEffect to set the state of state variable when the value of another state variable changes. This is the big anti-pattern. The first issue is that useEffect itself happens post-render, so it will trigger an additional rerender when you set that other variable. This is an unnecessary performance hit that can be solved by directly setting the state in the place that the other variable is set. If you are unable to easily do that because the setter happens in a different component, you will want to lift that state up to a parent component, create the handler there, and pass the handler (usually with useCallback) down the child components. There's also the annoying infinite rerendering that can happen, which if you're in a spot where it is even possible, you're like already in the anti-pattern zone. Many people will see the ESLint warnings about useEffect where something exists in the dependency array but doesn't exist in the useEffect function. If you have this warning in your build step, you are doing an anti-pattern. It's funny, because when this happens it can be very difficult to fix the issue because you've useEffect'ed yourself into a corner, and it usually requires a fundamental component structure change. Lastly, and this is the most frustrating, if you start trying to chain useEffects together, or have different useEffects all over your component tree that depend on one another, you can very easily create obscure state logic bugs that are difficult to find and even more difficult to fix (band aide in this case). UseEffect is probably the biggest example I can find in React of a tool being presented in guides and courses for the wrong use case. It is the most simple and apparent hook to reach for in a lot of cases where its use is not intended at all. I would honestly argue at this point, if you're actually directly (not a query library) using the useEffect hook in your code, you're probably foot-gunning yourself. I'd actually love to see Jack do a video in this if he hasn't already.
React is like the COBOL of the 2020's. Driven by one of the worst companies in the world. There are so many better tools, but the timid majority don't know any better, and will always follow their leaders anyway. If you want a better life, and build long term maintainable systems, say NO to react.
Make huge project in term of size in react for 3+ years. And do you know what? It runs perfect! So if you don't like React ok its for you but don't tell us it is bad. If you know how to use it, it is great. And this approach applies to all instruments that you will work.
Hahaha it's not about never use but thing is always thinking in terms of react is not right. I saw university a teacher preaching react JS and totally by passing the DOM manipulation in vanilla JS. One should not start front end journey directly from reactis especially the students. Moreover one should also be open to think outside of reactjs as well but yes do use reactjs where it makes sense... Only problem is to ALWAYS see any problem from reactjs lens
Do you have any videos perhaps talking about how you can begin to move away from using the class-based version of react components to being more functional. I started off trying to just do it with recent projects for arcgis and have discovered that the number of number of effects on the page that has become overwhelming. And I'm trying to figure out how I can better manage that cuz I do think the functional syntax is a little more expressive
Most of the time, for most components we will do... performance doesn't matter. When it do, and when you have tools to pinpoint what and where... then you can min-max every single loop and whatever else, otherwise? Aim for readability and manutenability.
I think react is not infallible, nor is its dom management (relatively on performance). Yet, it is little by little becoming a goto framework/library for web interfaces, simple interfaces shouldn't be this resource-intensive. Signals are great. Making some changes on the react way in order to have better results is not necessarily a bad thing, and no, we won't switch to solid.js
I learned that I am the Kondo Coder. The slatejs editor in my app is very laggy. Suspected the slate package only for so long. Moved the nested component definitions in the Editor component out. Butter smooth editor. Thank you so much.
So many of these beautiful thoughts and insights clumped in a single video. It is true that using the same tools for every project is very close-mindedness. It seems to me that people using Redux in every project are sometimes just afraid to not face the wrath of these cults.
Still many senior developers write business logics in the reducers. I prefer to maintain business logic inside the pure hooks. Now I am struck with a company that has a legacy React app. I am dying here. Someone please help me. ❤
I'm pretty new to this stuff but surely defining a component inside a component negates the point of React which is to compose components, right? I mean is a component defined inside another component even a component at all? Why wouldn't you just have a bigger, single fragment of JSX?
Readability. Even better would be putting the component outside of the other one, expecially if it's a "dumb" UI component that doesn't get used anywhere else.
As far as neverspreaders and Primeagen in particular, I have a strong belief that Prime is not as top notch of a developer as her portrays himself. In one of his videos he mentioned that the state flow in React "is not unidirectional because it has to ping the server at some point"...
The only cult I'm in is never using redux if I can avoid it. Anything but redux. I give redux cult 0/5 stars because redux should just die already, there are better options out there. The only time I'd consider a full blown state manager like that is if for some reason there were 20 components that had to share a lot of state between each other. But that seems like an architecture problem, and I don't really like going down the rabbit hole of "but what if I need this to do X". More often than not, you can just wiggle around a little and get rid of X completely.
Why is 20 components the right amount for you? Why not hundreds? Or thousands? 20 components sharing state is not a lot in medium to large code bases. And, no, it does not mean it's an architectural problem. Components define the UI that reacts to the current state of things; whether passed as props (component-specific state; styling, content, modality, etc.), or external sources (component-independent state; context, feature flags, user/session state, realtime databases, etc.), all that matters is that you present the user with correct UI. There's many different kinds of state and it depends on what the goal is that you're trying to accomplish. Additionally, there can be cases where passing unstable props is not feasible, for example in cases where rendering many components proves to have an overhead due to copying of data. Here it's a common pattern to pass stable values such as strings or number, like IDs and then have the component selecting the state it needs from a shared store based on that input. On top of that, requirements change often when you work on a product; and it will never be entirely clear to you or anyone on your team where they change and results in added maintenance burden. A way to minimize this is to not think about API of your components, and use DI to get data from other sources. This is especially useful when things move and change all the time. But whether you use Redux (which is more than just "dispatch" and "actions") or any other state library is entirely up to you (and your team, together) to figure out. Choose what _works_ for you.
@@dealloc 20 was an arbitrary amount meaning "a lot". And I didn't really mean components like a button or input, but larger things like tables, lists etc. youtube page of this video would have the top bar, sidebar, video, recommended and comment section. It's still just 5, and I doubt there's something they all use (maybe besides logged in user data, which can be just context or the like). I wouldn't put the entire comment section or all the recommended videos into a global store, seems like a nuclear option to me. And by "between each other" I meant that the state is mutable from many places by the user, and the change should be visible everywhere else in real time. If it's mutable from one place, plain context or zustand will work just fine. Most states I've seen and worked with were stable as well, and if something isn't, useMemo. I know redux is more than dispatch and actions. The "more" part is fine. Dispatch and actions aren't for me though. Sometimes a reducer can simplify things tremendously, but I find they're not nice to work with, the standard syntax with a switch is weird, it's hard to find the specific code you are looking for if you have many actions etc. I use reducers as an exception when it makes sense, not as a default way of thinking about everything, it's too cumbersome. Redux has one advantage I'm willing to admit. It's standardized. If you're working in a large team and have some experience with the codebase, you can easily add a slice that works and looks like all the other slices. It's basically react on rails, but you have to lay down the rails yourself (or have copilot/gpt do it nowadays) Either way, I'm still not going to use redux unless it's forced on me, and if so I'll start looking for a new job. Especially if the reasoning is "it's an industry standard" and not an actual good reason like "we need to make it extensible" or "we really can't afford extra renders but want modularity". And even then I'd fight to use something else, although at that point it would just be my bias against redux.
I think the term ‘render’ is a source of confusion. The component doesn’t render to the screen, it’s *processed* by the React engine. It took me a while to understand that re-rendering isn’t bad, it’s how React resolves differences to determine whether or not to update the corresponding *real* DOM node. The React team could’ve easily chosen another term that would be less likely to cause confusion, like “resolve”.
Primeagen is the worst about this kinda thing. Him and Theo both LOVE just summarizing things for scapegoat views ("THIS IS THE WORST YOU HAVE EVER SEEN!" OR "OH MY GOD HOW DID WE LIVE WITH OUT ___") We need some cooler heads to prevail in tech and less people like The Primeagen.
They use clickbaity titles because they work. Just like veritasium does, and both explained why and apologized in advance for doing. That doesn't diminish the value of their content.
Terrible advice, you are calling to disable the mind and do as "they said", forgetting that it is React that adapts as framework. The way how it is done in React neither good, nor future-proof. It is good time to look else where.
Alright, which "they said" are you talking about? I only gave two that I can think of; using React classes hierarchically and nesting component definitions. Both of those were covered in the documentation from the beginning as anti-patterns. React didn't adapt from those into something else. Those were, are, and always will be anti-patterns in React. To your larger point that "The way how it is done in React neither good, nor future-proof." Then use a different framework. Why put a ton of framework code on that page just to try to work around it?
Err say what?! React uses new reference as a poor mans event! That sounds rather insane to someone who got started on an environment where Any allocations during course of normal operation was either a bug or just simply bad code that should never pass code review.
0️⃣ ✨ for ‘Always use State Manager’ for 👍 what he is saying, but even more so. There’s a very high likelihood that your app is not big enough to use a state manager. React IS a state manager, inherently!
Great video, and as always, right on. Never will understand why so-called 'software engineers' want to fight against how React works. I've found over many years that it just works great without a lot of mucking with it and worrying about re-renders too much. Maybe all the hooks are a bit confusing, and hope the React team might make it more clearer when, how and why to use them.
Great Video. I would love to see a more hands on approach like take a project and add useMemo and other optmizations which reduce memory usage bundle size, INP, CLS all the good stuff... even better post that code like two days before and do a code review. What do you think?
For past 3 years I've used react context only, and only when I really need that shared state. I'd argue the same about SSR. The amount of complexity it brings just to please Crawlers (which already know how to index SPAs), and to save that 0.5s. Its nuts. Most people have powerful phones, laptops to handle CSR on their own devices. Rehydration, Thunks, Sagas, RTK, React-Query, File-based routing (thanks nextjs). All this results in a codebase where 80% is infrastructure code, 10% integration code and the rest is your huge and fat and unreadable react components. Totally agree with you on the re-render aspects. Leave the damn thing to the framework, only you (the dev) cares about it, the average person could not give a damn thing about it he won't notice it.
"and to save that 0.5s. Its nuts" -- when time is money, even half a second counts. Also as far as I know, crawlers can parse SPAs, but it's better if you can serve them proper HTML immediately. Server side rendering is also required for OG tags and other things like it to work and be parsed by those crawlers. SSR isn't just about Google/Bing. Yeah if you have a dashboard app behind authentication you probably don't need SSR, but public facing pages are a totally different story. Regarding renders, yeah worry about re-renders if they actually cause performance issues and let React handle the rest.
To add to this: sometimes pages that fetch data don’t reliably get picked up by crawlers in my experience. The loaders of Ssr frameworks are nice because they allow you to control that initial data.
@@rand0mtv660 Most places that I worked with, were indeded precious about those 0.5s render time, but ignorant about the long chain of api calls, ignorant about basic UX concerns like hover-based mega-menus, SSO, page flickering etc. Sure 0.5s is important but its as important as polishing your Lamborghini's bonnet. If its a Ford Focus, then you have more important things to work on.The polish would come as last priority. In practice, unless you are google, your business opportunities would not resort to those 0.5s but rather in a competitive service offered to the end customer. And on the other hand achieving those extra 0.5s results in bi-weekly planned release cycles mainly made of bugfixes.
@@arden6725 Few seconds vs increment of milliseconds is quite a difference. But despite that, I'm ready to bet that if you get that juicy PS5 Slim deal on a local retailer shop's website, you'll wait and retry from 3 browsers as many times as needed just to capitalize on the deal.
Could you cover using javascript classes, not class components, in a react app? I saw a recently implementation where someone defined a functional component property as a class. Ex. myForm, which is a config class for the form component.
I am of cult. Not using spread until you need it. Just rerender when you need to rerender. And i have a new cult this cult named. Do not use useState with objects useReducer better for this job
The second argument to React.createElement is a props object which is created every time you render. The only difference between doing and is { b: props.b } vs { ...props }. Which I don't even think would register in a perf test.
@@RaducuGabriel I get it. What I'm saying is that if you put props on a component invocation, any props at all, spread or not, the compiler is going to create a props object and sent it to createElement or jsx. So either way, you get an object. And you don't get two if you do {...something}, you just get one with {...something} in it. Check the repl: babeljs.io/repl/#?browsers=defaults%2C%20not%20ie%2011%2C%20not%20ie_mob%2011&build=&builtIns=false&corejs=3.21&spec=false&loose=false&code_lz=GYVwdgxgLglg9mABACTgWwKYAoCUiDeAUIogE4ZQilJbEmIA8yGAhgCYakEB0vADqTh8AzgF8AfHXqMAwi1JQZccFB79BI0YmBw4AXgBEAZgOIA9JOkkGchUpXbdhgEymLUxmebtOlxDgBuQlEgA&debug=false&forceAllTransforms=false&modules=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=true&sourceType=module&lineWrap=true&presets=env%2Creact%2Cstage-0%2Cstage-1%2Cstage-2%2Ctypescript&prettier=false&targets=&version=7.24.3&externalPlugins=&assumptions=%7B%7D
I am confused... what if I have a custom native html element, an input for example... {...props} would pass all the properties to the underlying input from my custom input... how do the neverspreaders deal with this?
I think the "always use a state manager", is maybe not 100% correct, maybe it should have said "always use a state manager, when you need more than just component state". Seen as you said use React as designed, that's what the built in state was designed for "Component State", when you need more, eg. "Application State", a state manager is really a must, oh. and I don't mean Redux, Jotia , or maybe Zustand that you mention would be a better start. Also your `useCallback` example was probably a bit pointless, the creating and retrieval of the callback would likely just take the same as an implicit function on each render. The `useCallback` would have been more relevant if you had used this callback as a dependency, than was passed as props.
Actually what I said was that state in class components was component state, and that we have with hooks a much more robust state model. Hooks provide a reactive state model which is fully capable of modeling application state. Reactive hook state, plus form and URL state is often as much as some applications need. Obviously applications vary widely in terms of the complexity of their state. Blogs managing comment state is much easier than a Figma clone. In the class based model we would have used Redux for both of those cases. Now Redux would be absurd overkill in the blog/comments example. And I'd argue that actually React's hooks model is more powerful than Redux in that derived state and effects are first class citizens in React hooks, as opposed to being relegated to selectors in the Redux model. As for the useCallback criticism, I don't follow. The sort function is passes as a prop and used as a dependency.
@@jherr "useCallback" Sorry, yeah, you have passed it as a props to , my bad. Still think the state manager still make things way better, yes, things can be done using pure React, but what I've found using a state manager means in most cases you don't even need to worry about `useCallback` , `useMemo` to keep things snappy etc, you get implicit granular updates anyway. My main use for React is complex Dashboard style systems, and what I've found using a detached state manager, keeping things as application state really helps here, especially with keeping code clean. React's dependency checking might also be shallow compare, but if you can avoid these checks in the first place, that really helps with performance too, comparing 1000's of dependencies adds up. btw. I don't like Redux, that's why I said "and I don't mean Redux".. :)
@@keithjohnson6510 Ah, my bad about the redux thing. IMHO, for a dashboard and not knowing the specifics my guess is that you've made a good choice there. My point in the video was just to get out of the mode of always thinking you have to have a state manager to go along with React.
Until it's out I recommend still using useMemo and useCallback. Forget will have a sea change impact on the React ecosystem (like hooks and RSCs before it).
For 2) If the functions are bad, what about assigning the fragments to constants? e.g., const x = … and then using it inside the render method {x}. This improves the readability for the render method if the JSX tree is over 100 lines. Not sure about the implications though.
Render functions inside of components are ok. As is assigning rendered elements to constants. Components are not ok. Component invocations are handled differently. is NOT the same as {MyComponent()}
7:56 - this is not good because it implies parent knows about the implementation of Table but it shouldn't. This is a brittle setup - every time you use a Table component you need to remember to pass a stable sort function. This can be solved with a custom useStableRef hook and using it inside of Table - but that just goes to show you have to hack around React to do this sort of thing and built in hooks don't really solve those issues.
I wrote a reply but it isn't here after a page refresh - I hope it's just on moderation or something. In case it got deleted for whatever reason(because of tsplay link?) tldr: useStableRef won't help in this scenario, my bad(but it can help in others) - the problem I've described is still there I think, it's a non-trivial problem but it's usually not solved with useMemo. If you're still curious about useStableRef anyway - please ask. I'll try to post link again then
@@huge_letters bro I don't think we can add comments with links. It just gets deleted. Btw I am interested in your useStableRef hook.. Could you paste your codesandbox link without that http and colon symbols.. so, I could use to visit
Redux devtools are not actually bound to Redux. Now anything, including other state managers, and Zustand, can leverage the Redux devtools. And some support its vaunted time travel debugging.
I'm curious, why the move to exclusively use function components? I find the hooks to be quite confusing from a DX standpoint. Class components are a lot more explicit (lifecycles for example). For me explicit always trumps implicit. Curious to know your thoughts.
I hate default imports because in some projects I've worked on ctrl-clicking those wouldn't show me where they are used. That was specially bad when people re-exported them from a middle-level index.js/ts to be used by other files. Non-default exports have never given me problems in comparison.
So true! It's one of the primary differentiators IMHO between junior and senior developer. A junior will ask me if they should use Zustand or Redux as an absolute. As if one is just inherently better than the other. Senior developers will want to know trade-offs and pros and cons.
Maybe this is a personal preference thing (it def is), but for some reason when im working in react it just feels like busy work with seemingly contrived framework preferences and terminoloy making things arbitrarily more tedious than they need be. Like are we really creating something novel when we have to potentially spend hours of time creating and testing semi-complex forms? Im not a Javascript genie, but Id assume that the issues i have with react are due to the design of Javascript and Javascript is designed the way it is due to how web assets are served. Ill admit react can be pretty fun when you're not essentially "hooking up frontend with backend", and actually making useful software. Im not doing front-end nowadays, but I think its actually more interesting to look at developments in the react ecosystem, than actually be active in it. Some of the new changes look decent.
I agree. My observation is that React programmers spend inordinate amounts of unproductive time fiddling around with low-level boilerplate code and css, completely losing sight of the app that they actually have to deliver! And once nextjs is introduced with things like kysely, it seems like we are going backwards to the early 2000's re-inventing problems that have long since been solved in other tech stacks like Angular. React programmers make a huge deal about the DOM, but in reality, this should have been abstracted many years ago. My observation is that the vast majority of React programmers are developing glorified CRUD apps and none of them are doing anything that demands high performance DOM manipulation. And if they are, then they should be using a gaming engine (eg Unity), not React. UIs are most definitely required, but it seems like there is far too much focus on pixel positions when we should be focusing on backends delivering business requirements.
Another bad thing about React fanboys is they argue that other framework's templating is weird e.g. custom html attributes and directives. However they are more than happy to write jank JSX and spaghetti it with some JavaScript and it's ugly as hell.
Primagen is bad source of information. For entertainment - probably good, but for education - definitely not. And main reason is with his narration manner you can never be sure if he is saying something seriously (considering he knows subject well enough) or just clowning as usual. Well, except for his devotion to nvim, which seems almost sacred for him. I personally dont have anything against him, but his content should be taken as joke and never relied on.
