Your work are truly amazing! I known about compound component a couple months ago, I think it's really cool concept till I watched this video that you show even cooler concept. Thank!
Nice video. It is inaccurate to say the original commits are “deleted” when performing a rebase. They still exist and can be accessed and even recovered if you know their original hashes. They do end up in an orphaned state and can be “cleaned up” under certain circumstances in the future.
This is great, what I don't quite get is how does the <ModalTrigger> make the <button> inside it trigger the event needed for the logic of the modal? Does it clone the child with an extra onClick prop inserted somehow?
I love the way you have dived deep into design patterns, but one main thing I am unsure about is that in the docs react team has mentioned not to use cloneElement and they have deprecated the api as well . So what’s your take on that? Would love to hear
The React team doesn't necessarily support all use cases, but many libraries use `cloneElement` internally. I've been looking at alternatives for a while now because I never liked how this was invisible and difficult to enforce in TypeScript. On the other hand, I figured out how to make render props fit my needs with memoization. Months later, in an interview with a Microsoft dev, he pointed out I could use useCallback and get a similar effect! It's not exactly the same, but it fixes my biggest gripe of render props. Another friend pointed out you could wrap these component functions to create new ones that had the functionality you wanted built-in. Where I work right now, they wanted render props with useCallback, so that's what I have. I haven't experimented with new ways to fix this since, but I'm sure there will be better ways in the future.
Hey man this is a gold mine of information. Keep it up. You should do more videos in this style with the slides. The way I learn most is when I get a short explanation of what a library/concept is first, why you need it, and why you should care. Then I like seeing an actual concrete example of how things are done using framework/example A and how the equivalent thing is done in framework/example B. Then I have the full context and can actually understand how example B solves the problems in example A and why I should even care in the first place. (think class + lifecycle vs function + hooks). This way you can gradually build on example A and B as you continue through the video and you can also isolate sections of code from example A, B or even C without needing to give full context of each to get your point across. I think this way is pretty digestible for most people and it makes sure the viewer is not lost in the middle of an explanation and they can discover why something is so elegant themselves. Anyways, liked and subbed hope to see more soon.
Thanks so much! I'd love to do more of these. I even have one ready on TypeScript but haven't had time to put it up yet (3 kids now) These styles of video take two weeks to create including all weekend and also time practicing my ad libs. Really glad you like the production value!
@@KevinGhadyani Yeah no worries I know it can get chaotic. I do have a few questions though. 1. What’s your stance on server components? Does this model still work with all the context? I’m assuming a lot of them would need to be client components to work to track the state. 2. You briefly mentioned jotai. Could you use it instead of context? 3. Opinion on tailwind now that it has exploded in popularity. I’ve personally used it for a few years now and couldn’t imagine styling an app without it or a solution very similar it. Shadcn/ui which runs on radix is also incredible to use and it looks like it uses a similar pattern you describe in the video. Would you call that children first?
@@keelangibb565 For #1, server components can track state too. The server keeps the HTML loading in the background and throws JS it generates at the client. That's how it works. So if you have state, it should retain in server components. Am I missing something? That's what my original exploration showed when I first tested it out in a different video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-6R_r6AqscqQ.html&pp=ygUbcmVhY3QgMTggc3NyIGtldmluIGdoYWR5YW5p #2 YES! I've actually used Jotai 4 times now in place of context. If I need global context, I use Jotai. It's like Redux in that it's not tied to React, so you can use it to write your own logic and associate multiple frameworks or multiple React instances. This is very common with micro frontends. #3 My opinion on Tailwind hasn't changed except on one point (I'll say at the end). If you write your HTML with Tailwind classes, you're doing it wrong. You need to write Tailwind like you're writing Emotion CSS (which you shouldn't be writing inline if you want your render code to be readable). Make it type-safe (which is super difficult to do in VSCode when it's not inline) and add some helper functions so it's easy to do line-by-line (function args) rather than a stupidly long string of random classes. There are so many gotchas! Vanilla Tailwind sucks and leads to the same problems I dealt with at a marketing site job in 2012 where you literally couldn't tell what was going on with the CSS or the HTML. YUCK! I absolutely don't recommend it if you're writing HTML like it's 1994. Also, unless you're using Vite, it's tricky to get Tailwind setup correctly. You have to purge out classnames from the final compiled output or your bundle jumps up 4MB. Lastly, you cannot use Tailwind classnames. This is why you _need_ helper functions or something similar. Tailwind classnames have to be namespaced you absolutely will run into the same Global CSS issue everyone runs into when you try to scale your site or upgrade something (like the Tailwind version) or change one style in one place of the Tailwind config and hope it doesn't globally affect your whole app. I am constantly dealing with micro frontends, and all of those have different CSS considerations based on the version of the component library they're running. If Tailwind isn't namespaced, they'll all share the same Global CSS, so when certain micro apps appear on the page at the same time, it could lead to different outcomes depending on which are loading when. Good luck debugging that! It will take WEEKS. And the problems will change over time as different apps add changes. So in conclusion, yes, you can use Tailwind, but I think you need to do a lot of work to make it feasible. I would absolutely never use it out-of-the-box. And so you know, I've done 2 Tailwind projects so far successfully on side jobs, so I'm speaking from experience.
IMHO the technical part of explaining what is props and children was good. The part that's crazy to me is the obsession to make things more complicated that it needs to be. The take in this video is that you should take the responsibility that the other devs gonna produce bad code and the solution is to write a complex and difficult to read code to mitigate it.
I'm not exactly sure I understand your point, but I'll respond the best I can :). I take a different approach at each company I go to based on the needs of the org and the existing codebase. This is just one solution you can use to solve the problem of tight coupling, but not something that works everywhere you go. In general though, the more complex your library, the less complex the code consumers need when consuming it. Where I work now, I have a different approach than this video. Instead of component usage freedom, they want API stability and ease-of-use. Now we're creating one component for each feature rather than a bunch of them that you assemble because that follows the design system better (unlike the patterns I had at this other company). It's a 180 degree difference in component design. The goal of TypeScript and other coding patterns is to make it dead simple to write code the intended way, so other devs can't screw it up.
My bad. That's probably partly on my editing and partly on the fact that I'm a fast talker in general. Newer videos have a different editor. He helps make things sound more natural, but I'd recorded and edited this one before I hired him.
Heya, found your talks during some downtime, and have been enjoying. I wanted to ask about the ref solution at 33:24 and I guess useEffect in general. From my experience, useEffect is really for syncing react with something external outside of react. Given a callback like onChange I'd just call it from the event handler that's updating calculatedValue versus waiting for useEffect to run when calculatedValue changed. This video is pretty old now too, so you may have changed the way you use useEffect. The useRef solution to ensure onChange is up-to-date without needing to include it as a dependency or memoize the incoming prop in the parent is interesting to me. Is this solution only intended for when you want useEffect to run under very specific circumstances? I could see someone finding this and doing something weird like wanting to do a fetch 'on mount' but only on mount so they ref all the potential props needed for that useEffect performing the fetch. I'm not saying you're wrong, but I'm trying to understand the value of what feels like bypassing the dependency list
I've changed how I do the useEffect useCallback thing mainly because React has changed. They fixed a bug where state setters would error when used after the component unmounts. In terms of useRef, it's powerful and needs to be done with care, but there are some situations where it's required.
I think I am fairly smart but I had to watch this twice to grasp the concept, and that is with 8 years React experience, I tried slowing it down to 0.75 speed but it makes you sound drunk... lol. Thanks though... I am sure after a good nights rest it will make sense. I am always bemoaning counter increment examples, now I wish there was one. Perhaps I will just try it out myself.
I've been searching for content to improve my shitty React codebase, and out of about 10 way more popular videos, this is the first one with some actual content. Others just tell something basic without any convincing. But your video is so much better! A bit long, so I'll watch the rest later, plus I see you left long answers to comments, which I'll obv have to read now. But for now, thanks!
Hope the rest helps you out! There are different ways to approach React components. I was aiming to fix tight coupling. In a later video I did with another group at Microsoft with a similar pattern, I also tried renderProps + useCallback, but it adds indirection. I use that pattern at my current job though. I came up with a way to do children-first with TypeScript and clever use of generics, but it requires some thought to figure out.
Hello, I am not able to see the Redux tab next to the React tab. Also when using react tab it sows Timeout while inspection. I tried several time but same result. I check all the possibilities but same result. Can you please help me with this ? thank you
For me it seems more obvious and simple just to add to the `fontSized` object a property `__proto__: legacyFontSizes`. Then `extreaLagre` and `extraSmall` won't appear by iteration, but not break the legacy code as e.g. with an attempt of getting `extraSmall` the `gigantic` will be returned. I still find your video very clear-cut and helpful, thank you! But can you please answer if in this particular case my solution is inferior to the approach with `Proxy`?
That's a great idea and a lot simpler! Personally, I wouldn't depend on proto as that's like black magic; unless I'm missing the mark. It's got that code smell. You also need to check for existing values first too. Hmm 🤔.
It's been a while since I watched this. I might've named it wrong or misremembered when creating the upload. This was definitely one of our topics when I talked to Marc though.
@@KevinGhadyani the other parts are still on your channel or where do I find them? Because I can use both redux and context but to be a good engineer I want to understand when to use which and not just apply blindly redux for everything
@coffeeandtalk it's really one of those "do what's best for your team on your project" situations. When I used Redux in the past, I did all Redux. This was before React Context was exposed cleanly to components. After React Context, I only used React Context because I prefer localized states. You can also use `useReducer` to make Redux-style with React Context. I still use Redux for state sharing between different JS frameworks or for backend code (yes, it works in Node without React).
I appreciate it! I'd love to make a course especially with the passive income source. Of the few courses I've tried for work, I've never gotten anything out of them, and I've never finished any either. I don't really think I'm qualified to do courses. I'd hope my RU-vid videos provide enough information.
@@KevinGhadyani Bummer... A course on how to properly design components would be awesome. Anyway, do you have source code with all the examples above? I would like to look at them in order to learn more. Some of the stuff is just too vague. BTW, I'm pretty sure you are qualified. :D
Nice. Currently working with the Tanstack virtualized table and it worked well, until I faced the requirement, of nesting a simple table in a virtualized row.
It would be nice if the video, as the title suggests, talked about Redux vs React Context. A more appropriate title would be "Chat with Mark Erikson, maintainer of the Redux ecosystem". It doesn't even link to his blog post on the subject.
Sorry about that. That's a great idea. Did I misname the video too? I broke up our convo into multiple videos each where we talked about a different topic relating to Redux. Pretty sure this one is where we name-dropped Dan Abramov because of the Context vs Redux debate.
@@KevinGhadyani you did mention both React Context and Dan Abramov, but it was mostly about history. I was hoping for a comparison, pros and cons, when you should choose one or the other, something like that. But there was nothing of the sort.
For clarity, transducers are to be useful in situations where you have multiple transformations in a pipeline. Like map, filter, map, ...etc, ...reduce; where each one is making potentially new intermediate datastructures upon each collection transformation. Transducers are an algorithmic way to combine all those operations into a single step on each item of your collection, and avoid making intermediate structures. If you're doing a lot of processing, it can save time and space; if you're only doing a little bit, probably stick to functional transformations. Oh, transducers were invented by Rich Hickey from Clojure. Fun to see my daily language making conceptual waves in larger ecosystems, usually without greater awareness. The future is here, just waiting for you to distribute it...
Just re-watched it. I'm surprised how simple it was. And yes, I don't like "for" loops. I have two LeetCode videos; one with RxJS (functional pipelines) and another where I did the same thing C++-style with a class. The class one took 3 times as long.
hmmm; summary: wants to speed up js, but doesn't like for loops, so trys to explain complex concept of loops via nested functions and loop body via list of other functions, resulting in worse performance then for loop i seem to be missing something, "benchmarks dont show it, but in other cases it would be better" then pls show it - even if its "too complicated"; goal of the talk hasn't been reached / not set, i feel no reason to look at the Transducers-conzept in the future
Sorry about that. It can be tough to come up with examples for an hour-long talk. Showing tons of code on slides is difficult because I can't use proprietary code, and all the crazy transducer stuff ends up being full apps, so it's not easily available. Without building a complete app, it's tough to explain. I'll keep this in mind next time I do something. You're right, these simple tests aren't fully utilizing transducers.
@@KevinGhadyani sure Kevin, I have raised an issue in GitHub but didn't got any reply from anyone. If you have any other link to connect with them, please share it with me
