Speaker 1: Welcome to the deep dive, where we slice through information
Speaker 1: overload to bring you the most important insights from your sources.
Speaker 1: Today we're diving deep into reacts core features, drawing from
Speaker 1: REACT key concepts and in depth guide to reacts core features.
Speaker 1: Our mission to sort of demystify the art of building
Speaker 1: dynamic user interfaces from the absolute fundamentals all the way
Speaker 1: to cutting edge full stack capabilities. Whether you're a curious learner,
Speaker 1: just starting out, or gearing up for a big technical meeting,
Speaker 1: we're here to deliver those aha moments and clear actionable insights. Okay,
Speaker 1: let's unpack this React as a huge topic. Imagine we're
Speaker 1: trying to build some interactive websites starting fresh. What kind
Speaker 1: of problems pop up if you try to use just
Speaker 1: planal JavaScript? Why not stick with that?
Speaker 2: Right? Well, the big challenge with planin JavaScript, especially for
Speaker 2: complex UIs, is what we call it's imperative approach.
Speaker 1: Imperative meaning you're telling.
Speaker 2: The computer every single step to take. Yeah, like construction
Speaker 2: after instruction, detailing exactly how to change the UI.
Speaker 1: Okay, micromanaging the brain pretty much, and even for fairly
Speaker 1: simple things, this can balloon.
Speaker 2: You might hit it over underlines the code, and maybe
Speaker 2: three quarters of that is just fiddling directly with the dom,
Speaker 2: managing its state, all that boilerplate stuff. So naturally this
Speaker 2: makes Vanilla JS pretty error prone and honestly just a
Speaker 2: huge time sink. It's like being a puppeteer, you know,
Speaker 2: pulling every single string.
Speaker 1: Yeah, that puppeteer analogy really clicks. Okay, So if that's
Speaker 1: the old how what reacts? What what's the philosophy shift?
Speaker 2: The shift with React is moving from puppeteer to architect.
Speaker 2: Instead of telling the browser how to move every pixel,
Speaker 2: you just declare the final blueprint. You focus on the
Speaker 2: big picture, the desired end state.
Speaker 1: Ah.
Speaker 2: So like if a button is clicks, you just tell
Speaker 2: React okay, the tech should now be this, and React
Speaker 2: figures out the how efficiently it keeps the paragraph updated automatically, so.
Speaker 1: It handles the translation exactly.
Speaker 2: You describe your ideal UI. React handles the MESSI dom stuff.
Speaker 2: It frees you up to focus on your actual business logic,
Speaker 2: which is I mean a massive productivity boost.
Speaker 1: So for US developers it means letting React handle those
Speaker 1: low level dawn interactions. That sounds like a relief. How
Speaker 1: do we actually get started. Set up a project good question.
Speaker 2: To get going, You typically use a tool like vite.
Speaker 2: You run NPM create vite at latest my app in
Speaker 2: your terminal than NPM.
Speaker 1: Installed Fight Why fyte specifically for learning, It's often recommended
Speaker 1: because it's lightweight, super fast.
Speaker 2: Frameworks like next dot gs are powerful, absolutely, but they
Speaker 2: add their own concepts, their own syntax, which can be
Speaker 2: a bit overwhelming.
Speaker 1: Right at the start, makes sense, keep it simple initially, right, and.
Speaker 2: In that new project, you'll see files like app dot
Speaker 2: jsx and main dojsx. That dot jsx just tells you
Speaker 2: these files mixed JavaScript with that HTML like syntax called JSX.
Speaker 1: Got it JSX, okay, project setup. Now inside the code.
Speaker 1: React apps are built with components. What makes them so
Speaker 1: well fundamental components.
Speaker 2: Are basically reacts, reusable building blocks. Think of them like
Speaker 2: specialized Lego bricks. Okay, its own javascrip logic. Often it's
Speaker 2: CSS styling too, and it's JSX markup. All self contained.
Speaker 2: This makes your code way more manageable, promotes reuse, and how.
Speaker 1: Does the browser actually see these?
Speaker 2: And that main dot JSX file. There's a bit of
Speaker 2: code using reactums, specifically root dot render that's the match
Speaker 2: cup part. It takes your JSX components and translates them
Speaker 2: into the actual dom instructions the browser understands.
Speaker 1: So the index dot html file is just empty much
Speaker 1: just a shell.
Speaker 2: Yeah, React fills it all in Oh and a neat detail.
Speaker 2: Custom components they always start with an upper case letter
Speaker 2: pascal case like submit button.
Speaker 1: Why is that?
Speaker 2: React needs it to tell your custom components apart from
Speaker 2: standard HTML tags like div or p when it parses
Speaker 2: the JSX ah.
Speaker 1: Okay, good tip. And how do you decide what should
Speaker 1: be a component?
Speaker 2: A good rule of thumb is to think about your data.
Speaker 2: Try to create a separate component for every distinct thing
Speaker 2: or data entity you can identify, like an individual to
Speaker 2: do item in a list. That's a component the list
Speaker 2: another component?
Speaker 1: Okay, components is building blocks? Great for structure, but how
Speaker 1: do we make them? You know dynamics, so they aren't
Speaker 1: all identical? How do we pass in different information?
Speaker 2: Right? Static blocks aren't very useful. That's where props come in.
Speaker 2: Props short for properties, are how you can figure your components.
Speaker 2: You pass data down into them, How you pass them
Speaker 2: You can pass them like attributes in htmail. Right on
Speaker 2: the component tag or even as children between the opening
Speaker 2: and closing tags. React automatically bundles these into a props
Speaker 2: object that gets passed into your component function.
Speaker 1: So inside the component I just use propstock whatever you can.
Speaker 2: Yeah, like props dot title, But often developers use a
Speaker 2: technique called destructuring right in the function parameters structure. It's
Speaker 2: like unpacking the props object immediately. So instead of props
Speaker 2: dot title, you just have title. Makes the function definition cleaner,
Speaker 2: like function product, title, price. You see exactly what that
Speaker 2: component expects.
Speaker 1: Let's typing definitely.
Speaker 2: Yeah, And there's also this spread up operator. If you
Speaker 2: have a JavaScript object with lots of settings, you can
Speaker 2: use dot can fee and your JSX to pass all
Speaker 2: those object properties as individual props. Really handy for rapper components.
Speaker 1: Okay, props seem powerful, but you mentioned a challenge earlier,
Speaker 1: prop drilling.
Speaker 2: Ah, yes, prop drilling. It's well, it's a bit of
Speaker 2: a pain point sometimes.
Speaker 1: What is it exactly?
Speaker 2: It's when you have to pass a prop down through
Speaker 2: multiple layers of nested components, even if the components in
Speaker 2: the middle don't actually use that prop themselves, they just
Speaker 2: act as carriers.
Speaker 1: Like passing a note in class.
Speaker 2: Exactly like that. The components in the middle just passed
Speaker 2: along until it reaches the component way down the chain
Speaker 2: that actually needs the data.
Speaker 1: And why is that bad?
Speaker 2: It makes the code less reusable, adds clutter makes refactoring harder.
Speaker 2: If you decide to change how data flows, you might
Speaker 2: have to edit files for components that weren't even directly involve.
Speaker 2: It often suggests your state might be better managed elsewhere.
Speaker 1: Hmm, okay, avoid the note passing if possible, so props
Speaker 1: handle configuration. But how do we make UIs actually react
Speaker 1: to things the user does clicks typing?
Speaker 2: Excellent question. This is where state becomes crucial. State is
Speaker 2: managed primarily using another fundamental React tool, the U state
Speaker 2: hook A hook.
Speaker 1: Yeah.
Speaker 2: Hooks are special functions that let you hook into React features.
Speaker 2: U state is the main one for adding state to
Speaker 2: functional components.
Speaker 1: And what is state in this context?
Speaker 2: Think of state as any data within a component that,
Speaker 2: when it changes, should cause React to re render that
Speaker 2: component and update the UI. It's the memory of the component.
Speaker 1: Okay, so how does you state work?
Speaker 2: When you call U state you usually pass an initial value.
Speaker 2: It then returns in array with exactly two things. First,
Speaker 2: the current state value itself, and second a special function
Speaker 2: you use to update that value.
Speaker 1: So a value and a function to change it precisely.
Speaker 2: And here's the key react nose to reevaluate or rerun
Speaker 2: your component function only when that state updating function gets called.
Speaker 2: That's the trigger for UI updates.
Speaker 1: What if I have multiple pieces of data that need
Speaker 1: to change.
Speaker 2: Good point, you have options. You can call U state
Speaker 2: multiple times for each piece of state, creating multiple state slices,
Speaker 2: or you could manage a single larger state object with
Speaker 2: U state.
Speaker 1: Is one better than the other depends multiple use?
Speaker 2: State calls are often simpler for unrelated pieces of data
Speaker 2: if you use a single object, though, you have to
Speaker 2: be careful when updating. When you call the state updating
Speaker 2: function with a new object, it completely replaces the old one,
Speaker 2: so you need to make sure your new object includes
Speaker 2: all the properties, even the ones that didn't change. Usually
Speaker 2: you use the spread operator to copy the old state first.
Speaker 1: Ah okay, got to remember to copy the old stuck.
Speaker 2: Exactly And another best practice. If your new state depends
Speaker 2: on the previous state value like incrementing a counter, you
Speaker 2: should pass a function to the state setter like set
Speaker 2: counterpreve counterpost count plus one. This ensures you're working with
Speaker 2: the latest value, especially if updates happen quickly.
Speaker 1: Got it? Use the function form for updates based on
Speaker 1: previous state. What about calculating things from state?
Speaker 2: You can just derive values. If you have user input
Speaker 2: in state, you can calculate its length directly in your
Speaker 2: component cont snumb chars user input dot length. No need
Speaker 2: for separate state for that derived value.
Speaker 1: Okay, And what if multiple components need the same state,
Speaker 1: like that prop drilling problem.
Speaker 2: That's where the pattern of lifting state up comes in.
Speaker 2: You find the closest common ancestor component of all the
Speaker 2: components that need the state, and you manage the state there.
Speaker 1: So the parent component holds the state right, and.
Speaker 2: Then it passes the state value down as props and
Speaker 2: passes the state updating function down as props too, so
Speaker 2: the child components can still read and update the shared state.
Speaker 2: It centralizes control.
Speaker 1: Lifting state up makes sense. Okay, we have components props state.
Speaker 1: Now how do we handle dynamic displays showing or hiding things,
Speaker 1: rendering lists?
Speaker 2: Yeah, very common. Need for conditional content like showing an
Speaker 2: error message only when there's an error or a life
Speaker 2: oding spinner. You can just use standard JavaScript logic right
Speaker 2: inside your JSX.
Speaker 1: Like if statements yep.
Speaker 2: If statements work fine outside the return inside JSX. Ternary
Speaker 2: expressions conditioning JSX one true, JSEX one false are super common,
Speaker 2: or the logical A and D operator conditioned JSX one true.
Speaker 1: Okay.
Speaker 2: You can even store ENTIREJX structures and variables and render
Speaker 2: them conditionally, or even change the HTML tag itself based
Speaker 2: on a prop, like rendering a button or a tag
Speaker 2: dynamically flexible.
Speaker 1: What about lists of data like an array of items?
Speaker 2: For lists, you'll almost always use the JavaScript dot map method.
Speaker 2: You take your array of data, map over it, and
Speaker 2: return a JSX element for each item. Simple enough, but
Speaker 2: there's a very common warning. You'll hit React complaining about
Speaker 2: missing keys.
Speaker 1: Keys. What are those?
Speaker 2: Keys? Are special unique identifiers you need to add as
Speaker 2: a prop to each element you render inside a list
Speaker 2: map like like key, item, dot id.
Speaker 1: Why does React need them?
Speaker 2: They help React identify which items in the list have changed,
Speaker 2: been added, or removed. Without keys, React might have to
Speaker 2: re render the entire list unnecessarily. With keys, it can
Speaker 2: be much smarter even just rearranging existing dom elements. If
Speaker 2: the order changes. It's a performance optimization.
Speaker 1: And the key has to be unique.
Speaker 2: Unique among good siblings in that list. Yes, yeah, and stable.
Speaker 2: It shouldn't change between renders for the same item. That's
Speaker 2: why using the array index is a key is often
Speaker 2: a bad idea, especially if the list can be reordered
Speaker 2: or items removed from the middle. The index doesn't stick
Speaker 2: with the data item. Use a unique id from your
Speaker 2: data if possible.
Speaker 1: Got it? Use stable unique IDs for keys. And you
Speaker 1: mentioned immutability before with state objects, does that apply to
Speaker 1: a rays in the state too?
Speaker 2: Absolutely? If you have an array in state and you
Speaker 2: want to add an item, you must not use methods
Speaker 2: like dot push that modify the original array. Why not
Speaker 2: because React to text changes by comparing objector ray references.
Speaker 2: If the reference hasn't changed because you modified it in place,
Speaker 2: React won't see the change and won't re render.
Speaker 1: So what should I do?
Speaker 2: You need to create a new array. Use methods like
Speaker 2: concat or more commonly, the spread operators at my array
Speaker 2: dot old array new item. This creates a brand new
Speaker 2: array reference, signaling the change to React.
Speaker 1: Always immutable updates okay, immutable updates for objects and a
Speaker 1: raised and state crucial now styling. How do we make
Speaker 1: our components look good without CSS rules bleeding everywhere?
Speaker 2: Styling? Right, you can just in court standard CSS files
Speaker 2: import a component on CSS. But like you said, those
Speaker 2: styles are global by default, easy to get accidental clashes,
Speaker 2: especially in larger apps.
Speaker 1: So what are the alternatives?
Speaker 2: You can use inline styles in JSX you use the
Speaker 2: style prop, but it expects a JavaScript object, not a string,
Speaker 2: so it looks like style color red, padding top tenpx.
Speaker 2: Notice the cambl case for CSS.
Speaker 1: Properties inline styles. Okay, what about CSS classes?
Speaker 2: The CSS classes you use the class name prop, not
Speaker 2: class because class is a reserved word in JavaScript.
Speaker 1: Ah, class name, got it, And you.
Speaker 2: Can set class name dynamically based on state or props,
Speaker 2: which is really useful for conditionals.
Speaker 1: But that still doesn't solve the global clash problem if
Speaker 1: we import CSS files right correct?
Speaker 2: For that, CSS modules are a great solution. You name
Speaker 2: your CSS file like my component dot module dot css.
Speaker 2: When you import it, the build process automatically transforms your
Speaker 2: class names into unique strings, effectively scoping them to that component.
Speaker 1: So title in one component won't clash with dot title
Speaker 1: in another.
Speaker 2: Exactly, it becomes something like my component title A three
Speaker 2: to seven B prevents clashes entirely. Other popular options include
Speaker 2: CSS and JS libraries like style components, which let you
Speaker 2: write actual CSS inside your JavaScript files, often using tag
Speaker 2: template literals, and utility first libraries like Tail and thess
Speaker 2: are also very popular, giving you lots of small, reusable classes.
Speaker 1: Lots of options there. Okay, what if? What if I
Speaker 1: really need to directly touch a DOM element, like to
Speaker 1: focus an input field or measure its size. Escape reacts
Speaker 1: control for a moment.
Speaker 2: Sometimes you do need that. That's where refs come in,
Speaker 2: using the use ref another hook yep use ref lets
Speaker 2: you create a reference, a sort of pointer to a
Speaker 2: value that persists across renders. Commonly, you attach this ref
Speaker 2: to a DOM element using the ref prop like input
Speaker 2: ref my input ref, and then then inside your component logic,
Speaker 2: my input ref dot current will hold the actual DOM
Speaker 2: node and you can call methods on it like my
Speaker 2: inputref dot current dot focus.
Speaker 1: Does changing the ref cause a rerender like state No.
Speaker 2: Crucially it doesn't. Updating a ref my input ref dot
Speaker 2: current ocals some value does not trigger a component rerender.
Speaker 2: That's the key difference from state use res for values
Speaker 2: you need to track, but which don't directly affect the
Speaker 2: visual output.
Speaker 1: Okay. Refs for direct dom access or persistent values without rerenders.
Speaker 2: And this leads to the idea of controlled versus uncontrolled components,
Speaker 2: especially for.
Speaker 1: Forms control versus uncontrolled.
Speaker 2: A controlled input component has its value managed by React
Speaker 2: state use state. Every keystroke updates the state, which updates
Speaker 2: the input's value. Prop React is fully in control okay.
Speaker 2: An uncontrolled input doesn't have its value tied to state.
Speaker 2: You'd use a rapt to read its value only when needed,
Speaker 2: maybe on form submission. React doesn't manage its value moment
Speaker 2: to moment.
Speaker 1: Which one should I use?
Speaker 2: Generally prefer controlled components. It keeps React as the single
Speaker 2: source of truth. Uncontrolled can be simpler for very basic forms,
Speaker 2: but controlled gives you more power for validation, dynamic changes,
Speaker 2: et cetera.
Speaker 1: Got it, Prefer controlled? Now one more tricky layout thing, modals,
Speaker 1: pop ups, tooltips, things that need to appear on top
Speaker 1: but might be deep in the component tree. How does
Speaker 1: React handle that?
Speaker 2: Ah? Yes, the z index nightmare For that. React offers portals.
Speaker 2: You use the create portal function from React.
Speaker 1: Tom portals like teleporting UI.
Speaker 2: Kind of create portal takes two arguments the JSX you
Speaker 2: want to render like your modal component and a reference
Speaker 2: to a domnode outside your component's current place in the
Speaker 2: dom tree where you want to render it up inside
Speaker 2: where typically you'd have an empty DIV somewhere near the
Speaker 2: root of your index dot HTML like div ideo modal RUDDIV.
Speaker 2: You tell the portal to render your modal inside that div.
Speaker 1: So even if my button triggering the modal is nested
Speaker 1: deep down.
Speaker 2: Exactly, the modal renders visually in that top level DIV,
Speaker 2: avoiding CSS decking context issues and making styling much easier.
Speaker 2: But logically it still behaves like a child of the
Speaker 2: component that created the portal, regarding event bubbling in context.
Speaker 1: It's clever portals. Okay, that solves a common headache. Now
Speaker 1: let's shift gears slightly. We've talked rendering state. What about
Speaker 1: actions that happen besides rendering, like fetching data, setting timers,
Speaker 1: interacting with browser APIs.
Speaker 2: Right, Those are called side effects. There are actions or
Speaker 2: processes that happen in addition to the main rendering process.
Speaker 2: Sending HTTP requests, using local storage, setting up timers or
Speaker 2: subscriptions all side effects.
Speaker 1: And can they cause problems?
Speaker 2: Oh? Definitely. A classic newbie mistake is putting a side
Speaker 2: effect directly in the component body that also updates state.
Speaker 2: If fetching data updates state and the component rerenders, it
Speaker 2: might fetch data, get update state again, infinite loop.
Speaker 1: Yikes. How do we avoid that with another hook?
Speaker 2: That's effect.
Speaker 1: Yeah.
Speaker 2: Its whole purpose is to manage side effects safely within
Speaker 2: functional components.
Speaker 1: Okay, how does use effect work?
Speaker 2: It takes a function, your effect function, containing the side
Speaker 2: effect code, and crucially a second argument, a dependency's.
Speaker 1: Array dependencies array.
Speaker 2: Yes, this array tells React when to rerun your effect function.
Speaker 2: If you provide an empty array, the effect runs only once,
Speaker 2: right after the component mounts renders for the first time.
Speaker 1: Only once useful for initial data fetching exactly.
Speaker 2: If you list variables or props in the array, like
Speaker 2: user id, the effect will run after the first render
Speaker 2: and anytime the value of user ed changes between renders.
Speaker 1: Ah, so it reruns only if specific dependencies change.
Speaker 2: Precisely. If you don't provide the array at all, which
Speaker 2: is generally discouraged, the effect runs after every render. That's
Speaker 2: often how those infinite loops start.
Speaker 1: Okay, so always provide the dependency array mpty for once
Speaker 1: or list the values used inside the effect.
Speaker 2: That's the golden rule. Add all values props, state variables
Speaker 2: from the component scope that are used inside your effect
Speaker 2: function to the dependency's rate.
Speaker 1: All of them, any exceptions.
Speaker 2: The main exception is state updating functions the second thing
Speaker 2: returned by U state React guarantees these functions themselves never change,
Speaker 2: so you don't need to list them as dependencies. Same
Speaker 2: for built in APIs like fetch or refs.
Speaker 1: Okay, what about cleaning up like clearing a timer?
Speaker 2: Use effect candles that too. If your affect function returns
Speaker 2: another function, React will run that return function as a
Speaker 2: cleanup function.
Speaker 1: When does it run the cleanup it.
Speaker 2: Runs before the effect runs again if dependencies change, and
Speaker 2: also when the component unmounts is removed from the UI.
Speaker 2: Perfect for clearing timers, removing event listeners, unsubscribing from things.
Speaker 1: Very useful. What if a dependency is a function to
Speaker 1: find inside my component? Won't that cause the effect to
Speaker 1: run too often?
Speaker 2: Good catch. If you define a function inside your component,
Speaker 2: it gets recreated on every render. If that function is
Speaker 2: a dependency of use effect, the effect will run every time.
Speaker 1: So how do we fix that?
Speaker 2: We use another hook, use callback. You wrap your function
Speaker 2: definition and use callback and provide its dependencies. Use callback
Speaker 2: will then return a memoized version of your function, which
Speaker 2: only changes if its dependencies change.
Speaker 1: So use callback memois as functions preventing unnecessary effect runs exactly.
Speaker 2: It works hand in hand with use effect in those cases.
Speaker 1: Okay, effects cleanup dependencies. That covers side effects. What if
Speaker 1: state management gets really complex, multiple related pieces of state
Speaker 1: complex update logic.
Speaker 2: When use state starts feeling cumbersome for a related state,
Speaker 2: React offers an alternative, the use reducer hook.
Speaker 1: Use reducer sounds like redux.
Speaker 2: It's inspired by similar patterns. Yeah, it's better suited for
Speaker 2: managing complex state logic. You define a reducer function separate
Speaker 2: from your component. This function takes the current state and
Speaker 2: an action object and returns the new state actions. Yeah.
Speaker 2: Instead of calling a state center directly, you dispatch action
Speaker 2: objects to your reducer like type increment payload. The reducer
Speaker 2: handles the update logic based on.
Speaker 1: The action type, So use reducer returns.
Speaker 2: It returns the current state and that dispatch function. So
Speaker 2: constate dispatch us reducer initial state. It helps centralize and
Speaker 2: organize complex state transitions.
Speaker 1: Okay, use reducer for complex state. Now what about reusing logic.
Speaker 1: If I have some stateful logic, maybe involving state and
Speaker 1: effects that I want to use in multiple components, perfect
Speaker 1: use case for custom hooks. Custom hooks.
Speaker 2: Yeah, these are just regular JavaScript functions, but their name
Speaker 2: must start with use, like use fetch or use counter.
Speaker 2: Inside a custom hook, you can call other React hooks
Speaker 2: like use state, use effect, user ref, etc.
Speaker 1: So it's like bundling up hook logic exactly.
Speaker 2: You encapsulate stateful logic into a reusable function. Any component
Speaker 2: can then call your custom hook like const data I
Speaker 2: loading use fetch.
Speaker 1: Does every component share the same state from the custom hook? No?
Speaker 2: And this is key. Every component that calls your custom
Speaker 2: hook gets its own independent instance of the state and
Speaker 2: effects defined within that hook. It's reusable logic, but isolated
Speaker 2: state per component instance.
Speaker 1: Ah. That's powerful custom hooks for reusable stateful logic. Okay,
Speaker 1: let's talk performance. We build these complex apps, how to
Speaker 1: keep them fast? How does React help and what can
Speaker 1: we do?
Speaker 2: Performance is crucial? Definitely reacts. First big optimization is the
Speaker 2: virtual dom we touched.
Speaker 1: On earlier, right, the in memory copy.
Speaker 2: Yeah, instead of hitting the real browser dom. For every
Speaker 2: little change, which is slow, React builds up changes in
Speaker 2: its fast in memory virtual dom. It then compares the
Speaker 2: new virtual dom state with.
Speaker 1: The previous one, finds the differences.
Speaker 2: Right, It performs a diffing algorithm to find the minimal
Speaker 2: set of changes needed. Then it applies only those changes
Speaker 2: to the actual dom in one efficient batch. It minimizes
Speaker 2: direct dom manipulation.
Speaker 1: Okay, virtual dom diffing. What else?
Speaker 2: State batching is another built in when if you call
Speaker 2: set state multiple times in quick succession within the same
Speaker 2: event handler or effect, React is smart enough to bash
Speaker 2: those updates together into a single rerender cycle.
Speaker 1: So it doesn't re render multiple times unnecessarily exactly.
Speaker 2: It waits, collects all the state updates for that tick,
Speaker 2: and then performs one single rerender reflecting all those changes.
Speaker 2: Saves a lot of wasted work.
Speaker 1: That's good, But what if a component itself rerenders even
Speaker 1: if it's props didn't change just because it's parent re rendered.
Speaker 2: That can happen, and it can be a performance bottleneck.
Speaker 2: To prevent those unnecessary child component evaluations. React gives us
Speaker 2: React dot memo. You wrap your entire component export with
Speaker 2: memo like export default React dot memo my component. What
Speaker 2: memo does is perform a shallow comparison of the component's
Speaker 2: props between renders. If the props haven't changed, React skips
Speaker 2: re rendering that component and its entire subtree.
Speaker 1: So it stops the rerender cascade.
Speaker 2: Precisely, but it's not free. Comparing props also takes time,
Speaker 2: so you don't want to wrap everything in memo. Use
Speaker 2: it strategically on components that are reasonably complex and are
Speaker 2: likely to receive the same props, often even when the
Speaker 2: parent rerenders.
Speaker 1: Okay, memo for component rerenders. What about expensive calculations inside
Speaker 1: a component.
Speaker 2: For that, we have the use memo cook use memo
Speaker 2: versus memo wraps a whole component. Use memo is used
Speaker 2: inside a component to memoize the result of a specific
Speaker 2: expensive calculation. You give use memo a function that does
Speaker 2: the calculation and a dependency array just like use effect
Speaker 2: ah dependency array again yep, use memo only reruns the
Speaker 2: calculation function if one of its dependencies has changed. Otherwise
Speaker 2: it returns the cash result from the previous render. Great
Speaker 2: for complex computations, filtering large arrays, et cetera.
Speaker 1: And use callback fits in here too, right, Use.
Speaker 2: Callback, memoize as functions, use memo memois as values the
Speaker 2: result of a function. Use callback often when passing functions
Speaker 2: down as props to memoized components, so the prop function
Speaker 2: itself doesn't change unnecessarily.
Speaker 1: Okay, memo, use memo, use callback. Yeah, our optimization toolkit,
Speaker 1: and what's.
Speaker 2: Really exciting is the future. React nineteen is introducing an
Speaker 2: experimental React compiler. The idea is that the compiler will
Speaker 2: automatically analyze your code and insert memo, use memo, and
Speaker 2: use callback where appropriate during the bill process.
Speaker 1: WHOA, So React would optimize itself.
Speaker 2: That's the goal. It could significantly reduce the need for
Speaker 2: manual mammalization, which can be tricky to get right. Still experimental,
Speaker 2: but very promising.
Speaker 1: Very cool. Okay, that's runtime performance. What about the initial load?
Speaker 1: Big JavaScript bundles can make that first page view slow.
Speaker 2: Absolutely, initial load time is critical. The main technique here
Speaker 2: is code splitting, often called lazy loading.
Speaker 1: Lazy loading.
Speaker 2: Yeah. Instead of bundling all your application code into one
Speaker 2: giant JavaScript file that the user downloads up front, code
Speaker 2: splitting lets you load parts of your code on demand,
Speaker 2: only when they're actually needed.
Speaker 1: How do you do that and React?
Speaker 2: You use the React at lazy function combined with dynamic
Speaker 2: imports synfacts. So constant my lazy component React dot lazist
Speaker 2: my component. Then when you try to render my lazy component,
Speaker 2: React won't have the code immediately. You need to wrap
Speaker 2: it in a suspense component Suspense. Yes, Suspense takes a
Speaker 2: mandatory fallback prop, which is some JSX to display while
Speaker 2: the lazy component's code is being downloaded and loaded over
Speaker 2: the network like suspense fallback dot loading dot div.
Speaker 1: So the user sees a loading indicator instead of an
Speaker 1: error or a blank space exactly.
Speaker 2: It smoothed the experience. It reduces the initial bundle size,
Speaker 2: making the first load faster, but adds more network requests
Speaker 2: later when those components are.
Speaker 1: Needed trade offs. As always, any tools for debugging performance
Speaker 1: or other issues.
Speaker 2: Definitely in development you should use the strict mode component.
Speaker 2: Wrap your app in it, and React enables extra checks
Speaker 2: and warnings for potential problems like identifying unsafe life cycle
Speaker 2: methods or unexpected side effects. It doesn't affect the production build.
Speaker 1: Trick mode for development checks and.
Speaker 2: The React Developer Tools browser extension is absolutely essential. It
Speaker 2: lets you inspect them, own a tree, view, props and state,
Speaker 2: and critically, it has a profiler tap profiler. Yeah, you
Speaker 2: can record interactions in your app and the profiler shows
Speaker 2: you exactly which components rendered, why they rendered, and how
Speaker 2: long they took invaluable for hunting down performance bottlenecks.
Speaker 1: Reactive tools profiler.
Speaker 2: Got it.
Speaker 1: Okay, we've covered a ton about client side React, but
Speaker 1: the landscape is shifting, right. How does React extend beyond
Speaker 1: the browser into full stack territory?
Speaker 2: Yeah, the lines are definitely blurring. Traditional client side rendering CSR,
Speaker 2: where all the React code runs the browser has drawbacks. Well,
Speaker 2: the initial HTML page sent from the server is often
Speaker 2: just an empty shell with a JavaScript link. The user
Speaker 2: sees nothing until the JS downloads, parses, and executes to
Speaker 2: build the UI. This can feel slow and it's not
Speaker 2: great for Search engine optimization SEO. Plus, if JS fails
Speaker 2: or is disabled, the app is just broken.
Speaker 1: Right. So the alternative is server.
Speaker 2: Side rendering ASSR. With SSR, reaction components are actually rendered
Speaker 2: into HTML on the server for the initial request. The
Speaker 2: browser receives a fully populated HKML document.
Speaker 1: So the user sees content immediately exactly much.
Speaker 2: Faster perceived load time better for SEO. Then client side
Speaker 2: jobscript hydrates the static HTM, attaching event listeners and making
Speaker 2: it interactive.
Speaker 1: How do you typically implement SSR with React?
Speaker 2: Frameworks like nextjs are incredibly popular for this. Nextjs is
Speaker 2: a full stack React framework that provides SSR, static side
Speaker 2: generation and many other features essentially out of the box.
Speaker 1: Next js. I hear that a lot. How does it work?
Speaker 2: He uses file based writing. You create files and folders
Speaker 2: inside an app directory in the latest versions, and the
Speaker 2: file paths automatically become your application routes like app about
Speaker 2: page dot js becomes the about route simple layout dot
Speaker 2: js files define shared UI shells for different routes, and
Speaker 2: you use a special link component from next link for
Speaker 2: client side navigation between pages, which avoids full page reloads.
Speaker 1: Okay, but if components are rendering on the server. Now,
Speaker 1: what about components that need browsers or use hooks like
Speaker 1: use state or use.
Speaker 2: Effect ah excellent point. This is where a key next
Speaker 2: dot chs and modern React concept comes in the use
Speaker 2: client directive.
Speaker 1: Use client by default.
Speaker 2: Components in nextjs is app router are server components. We'll
Speaker 2: get to those. If a component needs client side interactivity,
Speaker 2: uses hooks, event handlers. Browser APIs. You must put the
Speaker 2: string useed client at the very top of the file so.
Speaker 1: That tells next dot js render this one in the browser.
Speaker 2: Precisely it marks that component and its entire subtree as
Speaker 2: client side components. Their code will be included in the
Speaker 2: client JavaScript bundle. The goal is generally to push client
Speaker 2: components as far down the tree as possible, keeping server
Speaker 2: rendering for as much of the UI as you can,
Speaker 2: to minimize the client bundle size.
Speaker 1: Minimize client components. Got it? Okay, you mentioned server components,
Speaker 1: and I've heard about server actions too. These sound like
Speaker 1: the really cutting edge stuff. What's the deal?
Speaker 2: They really are a major shift. React Server components rscs
Speaker 2: are a new type of compon it designed to run
Speaker 2: only on the server.
Speaker 1: Only on the server, even after the initial load.
Speaker 2: Yes, they can be rendered on the server, fetch data
Speaker 2: directly on the server, even accessing databases or file systems,
Speaker 2: and then their rendered output, which isn't interactive React components
Speaker 2: more like a description of the UI is streamed to
Speaker 2: the client.
Speaker 1: What's the big advantage?
Speaker 2: Their code never ships to the browser, zero impact on
Speaker 2: your client bundle size. This makes apps potentially much faster
Speaker 2: and lighter. Plus direct back end access simplifies data fetching drastically.
Speaker 1: But they can't use state or effects right since their
Speaker 1: server only.
Speaker 2: Correct no use state, use effects, no browser APIs. They
Speaker 2: are purely for rendering UI based on server side data
Speaker 2: or logic. Interactivity comes from client components. Use client nested
Speaker 2: within or alongside them.
Speaker 1: Okay, rscs for server only rendering and data fetching. What
Speaker 1: about changing data on the server form submissions?
Speaker 2: That's where server actions come in. These are functions you
Speaker 2: can define that are guarantee to run only on the server,
Speaker 2: even if triggered from a client component.
Speaker 1: How do you define them?
Speaker 2: You write an ACYNC function and put the directive use
Speaker 2: server at the very top of the function.
Speaker 1: Body use server inside the function.
Speaker 2: Yes, This marks it as a server action. You can
Speaker 2: then pass this function down as a prop, maybe to
Speaker 2: the action prop of a form, or call it from
Speaker 2: an event handler and a client component. When invoked, the
Speaker 2: function executes securely on the server.
Speaker 1: So you can update a database directly from a server
Speaker 1: action triggered by a button click.
Speaker 2: Exactly without manually setting up API m points for simple
Speaker 2: mutations React handles as a secure communication. You can use
Speaker 2: hooks like use action state new and React nineteen in
Speaker 2: client components to easily handle pending states and displieve validation
Speaker 2: error's return from the server action.
Speaker 1: Wow. Rsees and server actions really do blur the lines.
Speaker 1: But what about more traditional client side routing for complex
Speaker 1: single page apps spas? Does that still have a place.
Speaker 2: Absolutely, While frameworks like next jas handle routing if you're
Speaker 2: building a pure client side SPA or need more granular control,
Speaker 2: React router is still the go to library React router.
Speaker 1: How does it handle data loading? Now?
Speaker 2: It's evolved a lot. Modern React Router heavily promotes using
Speaker 2: loader functions associated with your routes loaders. Yeah, you define
Speaker 2: a loader function for a route. React router calls this
Speaker 2: function before your component even renders. It can fetch data,
Speaker 2: and then the component accesses that data using the use
Speaker 2: loader data so.
Speaker 1: The data is ready before render. No loading spinners in
Speaker 1: the component.
Speaker 2: Often Yes, it simplifies component logic because the data is
Speaker 2: just there, no need to manage loading and error states
Speaker 2: for that initial fetch within the component itself.
Speaker 1: What about submitting data?
Speaker 2: React rider has action functions too similar In concept of
Speaker 2: server actions but running client side or potentially p posting
Speaker 2: to an endpoint. You usually trigger these using React router's
Speaker 2: own form component, which prevents default browser navigation. Actions can
Speaker 2: return data or trigger redirects using redirect.
Speaker 1: And error handling.
Speaker 2: It has robust error handling. You can define an air
Speaker 2: element for routes and use the use root error hook
Speaker 2: inside that element to display meaningful air information.
Speaker 1: So React router provides data loading, submission, and airror handling
Speaker 1: tied to Ritz exactly.
Speaker 2: And you can combine its features with newer React capabilities too.
Speaker 2: For example, you might use reacts use optimistic hook within
Speaker 2: a component to show immediate UI feedback while iraq router
Speaker 2: action runs in the background, or use React routers de
Speaker 2: fer utility and a weight component to stream data that
Speaker 2: might be slow rendering fallback UI while waiting, improving perceived performance.
Speaker 1: Okay, lots of powerful tools. Combining there few, we've covered
Speaker 1: a massive amount of ground. We went from the basic
Speaker 1: problem React solves escaping imperative dominipulation all the way through
Speaker 1: components prop state effects, optimization techniques like memmorization and lazy loading,
Speaker 1: and then into the full stack world with SSR next JS, React,
Speaker 1: server components, server actions, and advance client side routing with
Speaker 1: React router. If we try and connect this all to
Speaker 1: the bigger picture. For some when listening, they now have
Speaker 1: this incredible toolkit conceptually and practically to build really interactive,
Speaker 1: really performant web applications. But this raises a question for me.
Speaker 1: Looking at things like server components, server actions, the tight
Speaker 1: integration and frameworks like next JS, where do you see
Speaker 1: that line between front end and back end development blurring
Speaker 1: the most for React developers in the next few years.
Speaker 1: What's the biggest shift you see coming from all this.
Speaker 2: That's a great question. I think the biggest shift is
Speaker 2: that the React developer is increasingly becoming a product engineer
Speaker 2: who needs to be comfortable thinking across the entire stack,
Speaker 2: from UI interactions right down to data fetching and mutations
Speaker 2: on the server, server components and actions especially pull back
Speaker 2: end concerns much closer to the UI code. The lines
Speaker 2: are blurring significantly. You're writing server logic right alongside your
Speaker 2: component logic. While you still need specialists. The average React
Speaker 2: developer will likely need a broader understanding than before, but
Speaker 2: the payoff is potentially much faster development cycles. And more
Speaker 2: seamless features. But at the end of the day, my best
Speaker 2: advice for anyone listening is simply practice is key. Theory
Speaker 2: is great, but you need to build things.
Speaker 1: Absolutely.
Speaker 2: You should definitely try building small demo projects. Maybe a
Speaker 2: shopping cart app that hits state lists, maybe some effects.
Speaker 2: An authentication system great for forms state maybe context or
Speaker 2: custom books. Even an event management website could involve routing,
Speaker 2: data fetching, maybe server components. If you use NEXTJS.
Speaker 1: Good project ideas.
Speaker 2: And as you build, remember you don't have to reinvent
Speaker 2: the wheel. Explore the ecosystem. Libraries like tan stack Query
Speaker 2: or React query are fantastic for complex data fetching, caching
Speaker 2: and synchronization, Simmer Motion for animations, react to form or
Speaker 2: forma for complex forms, and for global state management. Beyond
Speaker 2: simple prop drilling or context libraries like redoct zoos, standard
Speaker 2: Joe tie are popular choices. Leverage these tools.
Speaker 1: Fantastic advice, build things, explore the ecosystem. Well, thank you
Speaker 1: for joining us on this really deep dive into React.
Speaker 1: For everyone listening, keep building, keep exploring, and keep learning.