
No Comments Yet
Be the first to share your thoughts and start the conversation.
Be the first to share your thoughts and start the conversation.
One of the most frequently misunderstood concepts in frontend development, whether you’re using React.js, Next.js, or another framework, is our tendency to follow flashy trends over selecting what best suits the case at hand.
Before reading this, you've probably already considered which state management library to use, perhaps the well-known RTK — Redux Toolkit or a trendy option like Zustand, right?
It’s normal; we often want to show off (in a good way) by using popular tech. But that’s not always the best approach. When learning, feel free to experiment and showcase different things. But when building real applications, think critically about what your project truly requires. Don’t just follow trends; keep things simple and focus on what works best.
At JSM, we urge you to focus on the “Why.” Question everything you’re doing and aim for the best. It’s the “Why” that plays a crucial role in a developer’s life. As for the “How” — even ChatGPT can do that if you clearly explain “What” through “Why.”
So, let me ask you — “What state management library do you want to use for DevOverflow?”
If you understood what I mentioned earlier, the first question to ask yourself is, “Do we even need state management?” (WHY)
The best way to determine this is by looking at the actual application flow on Figma.
Open the link above in a new tab and examine it closely to understand the data requirements for our app.
💡 If your project doesn’t have a Figma design, outline the logical flow yourself. Identify how many pages there will be and what needs to be shown on each page. Then analyze whether state management is necessary.
Ask yourself:
Ready?
Your initial response might focus on user data, right? Exactly!!
We’re displaying this specific user's information across various apps, pages, and components. Storing it in a global state allows for reuse, saving us from additional database calls.
Some of you might also think that search and filter tag information should be in a global state, as these components are in sidebars and we're fetching and displaying results in the main area. Sound familiar?
Yes, some of you might consider simply passing them as props and keeping all states within the main home page, even if it involves some prop drilling.
All of these approaches are valid. If you’re unsure or don’t know how to proceed, don’t worry. We’ll cover everything in the next lesson.
Ciao 👋
How did you manage to remove the blur property and reach here?
Upgrading gives you access to quizzes so you can test your knowledge, track progress, and improve your skills.
By logging in, you'll unlock full access to this and other free tutorials on JSM Pro.
Why? Logging in lets us personalize your learning experience, track your progress, and keep you in the loop with new workshops, coding tips, and platform updates.
You'll also be the first to know about upcoming launches, events, and exclusive discounts.
No spam—just helpful content to level up your skills.
If that sounds fair, go ahead and log in to continue →
Enter your name and email to get instant access
As we dive into the complexities of UI that share common data across various pages, it becomes paramount to carefully consider state management within our applications. This lesson emphasizes the importance of questioning our choices in technology, particularly regarding the selection of state management libraries, and encourages developers to focus on the specific needs of their applications.
00:00:02 From this part of the course onwards, we'll focus on complex UI that shares common data across different pages.
00:00:10 And for that reason, we seriously need to think about how to approach state management within our applications.
00:00:16 So I prepared this quick lesson that I want to go over with you.
00:00:20 Let's go through it together.
00:00:21 One of the frequently misinterpreted ideas in frontend or library framework usage, whether it's React or Next.js, is our tendency to use flashy trends
00:00:31 over selecting what truly suits the situation or case at hand.
00:00:36 You know, before you read this, you probably thought about which state management library to use, like RTK for Redux, or nowadays much more popular,
00:00:45 Zustand.
00:00:46 It's normal.
00:00:47 Like, we like to show off in a good way and we like to use the tech that other people and YouTubers talk about.
00:00:53 That's totally okay.
00:00:55 But let's think a bit about the why.
00:00:58 Question everything you're doing and only settle for the best.
00:01:02 It's that why that plays a huge role in your developer life.
00:01:06 Regarding how, even ChatGPT can do that nowadays.
00:01:10 But let's explain the why properly.
00:01:12 So try to answer this why.
00:01:15 Which state management library would you like to use for DevFlow?
00:01:19 And if you got what I said earlier, the first thing you should ask yourself is, do we really need a state management library in the first place?
00:01:26 Well, the best way to do that is by looking at the actual application flow on Figma.
00:01:31 Here, we can ask ourselves, what kind of data are we working with?
00:01:35 That's the first question.
00:01:37 Are we working with questions where we're mapping over them and each question has the creator, the timestamp, the number of votes,
00:01:45 answers, views, and so on?
00:01:47 Are we working with the data of displaying these navigation bar links?
00:01:50 Maybe information about the user?
00:01:53 What about the top questions or popular tags?
00:01:56 How does that data change across different pages?
00:01:59 Like on the other page, we keep the left sidebar, the right sidebar, and the nav bar, but the middle content changes to show more details about a specific question.
00:02:09 You can go through a couple of these questions and try to figure out which pieces of data we're handling.
00:02:14 The second question, which I kind of answered already, you can see that that's how I naturally went through the design, is what kind of data is being repeated
00:02:22 on different pages.
00:02:24 So what would you say?
00:02:25 In this case, what is being repeated?
00:02:27 Well, we could say that left sidebar and right sidebar are being repeated, which is true, but we have already extracted those into separate reusable components.
00:02:36 We also have pages like the users and tags and jobs, but these are not really getting repeated, are they?
00:02:43 And finally, is there any particular kind of data that's being used across the application?
00:02:48 And in this case, your initial response might involve the user.
00:02:52 As you can see, the user data, which we can see right here at the top right, is being used in every single one of these pages.
00:03:01 Everywhere there's this little JSM logo or your logo in this case.
00:03:04 So that means that storing that piece of data, the user session in the global state would allow us to reuse it and save us from another database call.
00:03:14 Maybe some search and filtering information should be in global state as well, like I mentioned for the sidebars.
00:03:19 And that's a totally valid point.
00:03:21 But now we have to explore things in detail and really answer the why behind the question, Why do we need state management in the first place?
00:03:30 And if we do need it, what's the simplest and best way to implement it?