👋 Hey all, hope you enjoyed the video! It didn't occur to me until I was publishing it that our move from calling setPrev() in the onClick handlers of each button, to using what ultimately became our usePrevious() hook, was actually a move from more imperative code to more declarative code. It's not just that the hook composes better with other components we may write in the future; it's that we're no longer thinking of _how_ the count state changes, but rather declaring all the state our component needs to render (both the UI and the animation), so that it is robust to state changes in the future. We've gone from caring _how_ the state changes (via a click), to not caring about how the state changes at all. So we're back to UI as a function of state. Imagine we make this component reusable, and now we accept `count` as a prop. In the onClick version, we'd need to update our component to also respond to change in the count prop. But with our usePrevious version, no matter how `count` changes (via a new prop, or another button we add to our code, or by adding a gesture where we can also swipe to increase count), our animation will work correctly. This is what made React so useful in the first place: turning imperative code like onClick={ $(.panel).slideDown() } into declarative code like . Declarative code helps us write more robust applications and is why I ultimately chose the title of the video that I did.
Not everybody is a great teacher, you definitely have a talent in clearly explaining complex topics in an easy to understand manner. It would be cool to see this carousel taken a step further and built into a onboarding UI with 3 screens, indicators and a couple of buttons, possibly done in the same style as your twitter clone or fitness app. I would imagine others would find that video pretty helpful.
I love your style when you first show the issues and the solution afterwards. That way we can learn much more than by just showing the solution straight away. Thanks :)
Dude, the timing of this is incredible! Literally was just looking at building a carousel with Framer Motion earlier this morning - so glad I saw this :)
Thank you for this video! I love framer motion, tailwind and React, web development is such a joy right now! Also, the hooks you used, including the previous state are in the awesome "react-use" library.
Super nice one, i even learn a couple things about React, like the extra sauce of keys for mounting and un-mounting, just would prefer to keep intentions as words, for decreasing & increasing on the code. There are any alternatives to framer-motion to build such widgets?
really like your videos, although there are many developers are doing tutorial video, and I really feel connected with your, which really helpped me alot, thanks , but meanwhile i feel frustrated when i encounter bugs..
Just explained this a bit more in the pinned comment, but the shorter answer is: deriving the direction from changes to our `count` state makes our component more declarative and therefore more robust to changes in the future. Imagine we calculate the direction in onClick, but then someone comes along and adds the ability to swipe the carousel to change the count. We'd now need to update our previous code. And then someone makes our carousel reusable, and exposes the `count` as a prop. Now when the count changes from the outside, we'd again need to update our previous code for our animation to work. If we use the usePrevious hook we ended up with, and derive it solely from the count state, we no longer care _how_ the `count` changes, and our component is more declarative and robust to new ways of changing `count` in the future.
why don't we store `direction` and `count` in the same state? const [[count, direction], setSlider] = useState([null,1]) ... onClick={() => setSlider([count-1,-1])} // left ... onClick={() => setSlider([count+1,1])} // right or it is bad idea?
You could do that for sure but I wanted to show usePrevious because it's more composable. The onClick event handler doesn't have to know about the direction, you can derive the direction from previous and current. That being said I like the idea of a useSliderState() hook like you mentioned, so it's easier to use throughout your app!
Why wont you get previous state from setState calback function? If you give setState callback function it will pass previous state to that callback function as an argument.
Hi Sam, great video! I am trying to learn the horizontal scroll like the one on amazon homepage where a lot of products are in one card container, is this the same as you showed on your video? thank you!
Hello. Thank you for the video. I am currently implementing page (router) animation using framer-motion. I tried to implement it in a slide form, but I feel like it's been cut off because I can see the white margins after the page has been animationed to exit. Is there a way to implement page animation like carousel like the video above?
Is it required to generate the tuple state? I specified the direction as a state rather than a constant and modified it from inside the button press functions. The application is working perfectly.
Does your action set both the index and direction? That works for sure but the solution with the tuple is more composable since the event handler doesn't have to traffic that extra information 👍
Hi Sam, thanks so much for this video. I tried to comment last night but it seems it was deleted, so apologies if there is a double-comment. I am trying to follow your example and have multiple items in each slide that stagger in. I faced the "wrong direction" issue like you did, which you fixed by setting custom on AnimatePresence. But that prevents me from setting custom on each child and passing the loop index so I can create a staggered exit. Would you know how to get around this problem? Tysm!
The trick in the docs (beta.reactjs.org/apis/usestate#storing-information-from-previous-renders) beats useEffect because (1) effects are just harder and more unpredictable, (2) effects run after render, so we would have a frame where `count` and `previous` were out of sync.
Because `count` isn't updated until the next render. So during the current render, if you think about the code `setCount(count + 1) `, there's no way that code could possibly update the local `count` variable, based on the way JavaScript works. It's part of reason Hooks were designed the way they were. It can be a little confusing at first but it's good to wrap your mind around this because it helps you understand how React renders your app in frames over time. For a given render frame, a state variable will always be the same. The way to think about setState() is that it tells React to enqueue an entirely new render, with the updated state value. When React re-renders using the new value, it starts all over again from the top of your component.
React is becoming one of the worst libraries ever. So much added complexity. Instead of empowering users it makes it so hard. Your video is great though.
👋 Hey all, hope you enjoyed the video! It didn't occur to me until I was publishing it that our move from calling setPrev() in the onClick handlers of each button, to using what ultimately became our usePrevious() hook, was actually a move from more imperative code to more declarative code. It's not just that the hook composes better with other components we may write in the future; it's that we're no longer thinking of _how_ the count state changes, but rather declaring all the state our component needs to render (both the UI and the animation), so that it is robust to state changes in the future. We've gone from caring _how_ the state changes (via a click), to not caring about how the state changes at all. So we're back to UI as a function of state. Imagine we make this component reusable, and now we accept `count` as a prop. In the onClick version, we'd need to update our component to also respond to change in the count prop. But with our usePrevious version, no matter how `count` changes (via a new prop, or another button we add to our code, or by adding a gesture where we can also swipe to increase count), our animation will work correctly.
This is what made React so useful in the first place: turning imperative code like onClick={ $(.panel).slideDown() } into declarative code like . Declarative code helps us write more robust applications and is why I ultimately chose the title of the video that I did.
Thank you Sam... helped a lot.
Not everybody is a great teacher, you definitely have a talent in clearly explaining complex topics in an easy to understand manner. It would be cool to see this carousel taken a step further and built into a onboarding UI with 3 screens, indicators and a couple of buttons, possibly done in the same style as your twitter clone or fitness app. I would imagine others would find that video pretty helpful.
I agree, that would be an amazing tutorial to see
I love your style when you first show the issues and the solution afterwards. That way we can learn much more than by just showing the solution straight away. Thanks :)
Dude, the timing of this is incredible! Literally was just looking at building a carousel with Framer Motion earlier this morning - so glad I saw this :)
wow... this is so amazing... Never seen anyone teach react in such depth and with proper explanations... Thank you very much Sam 👍
There is always something to learn from your videos.
Your videos are all so helpful. Truly a master at explaining things in a digestible way.
Thank you for this video! I love framer motion, tailwind and React, web development is such a joy right now! Also, the hooks you used, including the previous state are in the awesome "react-use" library.
Fantastic tutorial. Thanks for introducing me to useMeasure so many times in the past this would have saved me time
How is this man only have 10k subs? You deserve more!! Thank you! great explanation.
What a time to be alive :D Sending love from Mexico
Love the way you explained this. Great work 👍
You always go the extra mile, I love it! 👏
ABSOLUTELY AWESOME
"No effects, no refs" that could be a cool t-shirt
"No effect, no refs - just state" Love it!!
Amazing as always, thank you so much. High quality content.
Great explanation and amazing content! Thank you so much 😁
Thank you so much for this interesting video. You are the best teacher 😊
Super nice one, i even learn a couple things about React, like the extra sauce of keys for mounting and un-mounting, just would prefer to keep intentions as words, for decreasing & increasing on the code. There are any alternatives to framer-motion to build such widgets?
Very nice!
always amazing
Great Great Job! Super Good!
Thank you!
the first thing I do is to like, amazing content
Great tutorial!
Thank you so much
When is the Framer motion class dropping !! Sam !!!!
love your videos! keep it coming😂
really like your videos, although there are many developers are doing tutorial video, and I really feel connected with your, which really helpped me alot, thanks , but meanwhile i feel frustrated when i encounter bugs..
You should have way more subscribers than you do for the quality of your content. Hope your count goes up!
I learned a ton thanks 🙏
Love it, nice one
Couldn't you have just calculated the direction based on the chevron button that was clicked, directly inside of the motion div styling?
Just explained this a bit more in the pinned comment, but the shorter answer is: deriving the direction from changes to our `count` state makes our component more declarative and therefore more robust to changes in the future. Imagine we calculate the direction in onClick, but then someone comes along and adds the ability to swipe the carousel to change the count. We'd now need to update our previous code. And then someone makes our carousel reusable, and exposes the `count` as a prop. Now when the count changes from the outside, we'd again need to update our previous code for our animation to work. If we use the usePrevious hook we ended up with, and derive it solely from the count state, we no longer care _how_ the `count` changes, and our component is more declarative and robust to new ways of changing `count` in the future.
@@samselikoff That's pretty neat
Good crack for me thank you
amazing, how you may handle with images content ?
why don't we store `direction` and `count` in the same state?
const [[count, direction], setSlider] = useState([null,1])
...
onClick={() => setSlider([count-1,-1])} // left
...
onClick={() => setSlider([count+1,1])} // right
or it is bad idea?
also we can move all this logic to the custom hook
const { count, direction, showNext, showPrev } = useSlider()
You could do that for sure but I wanted to show usePrevious because it's more composable. The onClick event handler doesn't have to know about the direction, you can derive the direction from previous and current. That being said I like the idea of a useSliderState() hook like you mentioned, so it's easier to use throughout your app!
so infomative thanks
Why wont you get previous state from setState calback function? If you give setState callback function it will pass previous state to that callback function as an argument.
Hi Sam, great video! I am trying to learn the horizontal scroll like the one on amazon homepage where a lot of products are in one card container, is this the same as you showed on your video? thank you!
Hello. Thank you for the video.
I am currently implementing page (router) animation using framer-motion.
I tried to implement it in a slide form, but I feel like it's been cut off because I can see the white margins after the page has been animationed to exit. Is there a way to implement page animation like carousel like the video above?
Hi, great explanation!
How can I use Emmet like you did?
Is it required to generate the tuple state?
I specified the direction as a state rather than a constant and modified it from inside the button press functions. The application is working perfectly.
Does your action set both the index and direction? That works for sure but the solution with the tuple is more composable since the event handler doesn't have to traffic that extra information 👍
I love how you're not a programmer first and story teller second
How to do page transition with framer motion ?
Hi Sam, thanks so much for this video. I tried to comment last night but it seems it was deleted, so apologies if there is a double-comment. I am trying to follow your example and have multiple items in each slide that stagger in. I faced the "wrong direction" issue like you did, which you fixed by setting custom on AnimatePresence. But that prevents me from setting custom on each child and passing the loop index so I can create a staggered exit. Would you know how to get around this problem? Tysm!
Any chance you could share a sandbox?
that's awesome.
but why didn't you use useEffect with setTuple ?
The trick in the docs (beta.reactjs.org/apis/usestate#storing-information-from-previous-renders) beats useEffect because (1) effects are just harder and more unpredictable, (2) effects run after render, so we would have a frame where `count` and `previous` were out of sync.
@ 10:09 given that setPrev is placed AFTER setCount why does setPrev use existing value of the count and not the updated/incremented value?
Because `count` isn't updated until the next render. So during the current render, if you think about the code `setCount(count + 1) `, there's no way that code could possibly update the local `count` variable, based on the way JavaScript works. It's part of reason Hooks were designed the way they were. It can be a little confusing at first but it's good to wrap your mind around this because it helps you understand how React renders your app in frames over time. For a given render frame, a state variable will always be the same. The way to think about setState() is that it tells React to enqueue an entirely new render, with the updated state value. When React re-renders using the new value, it starts all over again from the top of your component.
@@samselikoff I see. Thank you
Thanks for the video, Sam ! I tried to subscribe to your Framer Motion course, but the sign up form doesn't work ...
I think it might be an ad blocker, could you disable and try again?
@@samselikoff Yes, that was it - now it works !
@@Film14666 So glad to hear! Mind if I ask which ad blocker so we can test it out + maybe render some useful messaging?
React is becoming one of the worst libraries ever. So much added complexity. Instead of empowering users it makes it so hard. Your video is great though.
its not about react its about the motion library itself
React is broken.