Forem: giangntse150746

React Context vs Provider vs Hook - What’s the Difference? 🤔

giangntse150746 — Thu, 29 May 2025 05:25:31 +0000

Okay, so you just got into a React project and suddenly you're surrounded by words like Context, Provider, and useSomething(). It's like walking into a secret club and everyone knows the handshake but you. Don't worry-I got you. 💪

Let’s break this down React-style, like you're explaining it to a friend over coffee (or boba, no judgment).

🧠 1. Context - The Idea Guy

Think of Context as the blueprint. It’s like saying:

“Hey, we’re going to have this thing called ‘Theme’, and it could be ‘light’ or ‘dark’. That cool?”

You define it like this:

const ThemeContext = React.createContext("light");

That’s it. No real data yet. Just a promise. Like someone saying, "We should totally hang out sometime." 😄

📦 2. Provider - The One Who Brings the Goods

The Provider is the one who shows up with pizza. 🍕

When you use a Provider, you're saying:

“Alright, everyone inside this component tree gets this value for the context.”

<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

Boom. Now your whole app (or part of it) knows the theme is "dark", without you passing props 7 levels deep like some kind of prop pack mule 🧳.

🪝 3. Hook - Your Access Pass

You want to use the theme? Like actually do something with it? Enter the hook:

const theme = useContext(ThemeContext);

Hooks are like, “Yo, I’m here for that context value you promised. Let’s roll.”

And hey, if you're fancy (and you should be), wrap it in a custom hook:

const useTheme = () => useContext(ThemeContext);

Now your components don’t need to know where or how the context works. They just go:

const theme = useTheme();

and move on with their lives. 🎉

🎯 TL;DR - Or as I call it, the Dev-Order Combo:

Context → Defines the shape (like the empty box 📦).
Provider → Fills the box with goodies 🧁.
Hook → Opens the box and uses the goodies 🎁.

💡 Real-World Example: Auth

You define AuthContext → your app knows there's an auth state.
You wrap parts of the app in <AuthProvider> → maybe it checks tokens, keeps user info.
Inside any component: const { user } = useAuth() → boom, you're logged in, baby.

So, next time you hear someone say,

“Just create a context and wrap your app in a provider, then use a hook to consume it,”
you’ll be like, “Easy. Been there. Done that. Got the useContext() tattoo.” 😎

#ReactJS #Frontend #WebDevelopment #ContextAPI #Hooks #Providers

DaisyUI vs. shadcn/ui: A Clear Comparison for Frontend Devs 🎨

giangntse150746 — Fri, 23 May 2025 04:00:02 +0000

Picking a UI library these days feels a bit like choosing a starter Pokémon - except instead of fire or water, you’re choosing between speed, flexibility, and how many dev headaches you’ll avoid.
In the React world, two familiar faces pop up at the party: DaisyUI and shadcn/ui (yep, we’re talking React-only today). Let’s break them down so you don’t accidentally pick Magikarp when you really needed Charizard.

🎯 Purpose

DaisyUI: A plugin for Tailwind CSS that gives you pre-built UI components with minimal setup. Think of it as utility-first meets component-first. Great for shipping fast without leaving Tailwind's paradigm.
shadcn/ui: Not a library, but a component generator built on top of Radix UI primitives and Tailwind CSS. You copy components into your project and own the code.

🧪 Tech Stack

DaisyUI
- Tailwind CSS plugin
- Pure HTML/CSS components
- Zero JS, framework-agnostic
- No build tools required
shadcn/ui
- Tailwind CSS + Radix UI (for accessibility + logic)
- Built with React (strictly)
- TypeScript-first
- Requires bundler setup (Next.js, Vite, etc.)

🧩 Flexibility

DaisyUI
- You use what’s given - excellent for prototyping and internal tools.
- Limited customization without diving deep into Tailwind overrides.
- Works out-of-the-box with HTML, Vue, React, etc.
shadcn/ui
- You own the components. Want to change markup, accessibility roles, or animations? You can.
- Great for design systems or teams that want control with a solid starting point.
- Only React-compatible - not for Vue/Svelte/HTML folks.

🧠 Best Use Cases

DaisyUI
- Rapid MVPs
- Admin panels, dashboards, or quick prototypes
- Beginners learning Tailwind with components
shadcn/ui
- Scalable apps that need fully accessible, typed, and customizable components
- Teams building design systems
- Serious React + TypeScript projects

🧵 TL;DR

Feature	DaisyUI	shadcn/ui
Framework	Any (HTML, Vue, React)	React only
Based on	Tailwind CSS	Tailwind + Radix UI
Ownership	Library-owned	Developer-owned
Use Case	Fast prototyping	Customizable production apps
Setup	Drop-in Tailwind plugin	CLI-based component generation

🔥 My Take as a FullStack Dev:
If you're just shipping something fast or exploring UI, DaisyUI is gold. But if you're building a product that needs long-term maintainability and accessibility, shadcn/ui wins hands down. You own your components, and that’s powerful.

Which team are you on? 🧢
#TeamDaisyUI or #TeamShadcnUI?
Drop your thoughts ⬇️

#frontend #react #tailwindcss #shadcn #daisyui #javascript #webdevelopment #uiux

🌱 7 Habits to Keep Growing as a Frontend Developer

giangntse150746 — Mon, 12 May 2025 07:34:38 +0000

Hey there, frontend friend!
Being a frontend dev isn’t just about making things look good but also about keeping your brain sharp, your skills fresh, and your motivation high.
Here are 7 habits that I recommend to keep you leveling up (without burning out):

1. Read Code Like It's a Bestseller 📚

You learn a lot by reading other people’s code. It’s like reverse-engineering someone else’s brain (spooky, but cool).
Check open-source projects, GitHub repos, or even your teammates' PRs. You'll pick up real-life patterns, better structure, and maybe even realize your code isn’t that messy after all.

👉 Bonus tip: Reading your old code is also a great way to measure progress...or to humble yourself.

2. Practice the Boring Stuff (It Pays Off) 🧹

Keyboard shortcuts, regex, git commands, and even CSS layout quirks - mastering these "boring" skills is like upgrading your dev superpowers.

You’ll work faster, solve bugs quicker, and feel less like smashing your keyboard every time you deal with Flexbox.

3. Teach What You Learn (Even to a Rubber Duck) 🦆

Explaining something forces your brain to really understand it.
Write blog posts, create short tutorials, or just talk to a rubber duck on your desk (yes, it's a thing).

Remember: if you can teach it, you truly get it.

4. Stay Curious, Stay Relevant 🔍

Tech moves faster than JavaScript frameworks get released (which is saying something).
So keep an eye on new trends, tools, and browser features, but don't feel pressured to learn them all.

Pick one thing a month to explore: maybe a new UI library, accessibility tricks, or how to write cleaner tests.

5. Build Stuff Just for Fun 🛠

Not every project needs to be groundbreaking. Make silly things. Rebuild a site you love. Try a 1-day challenge. It's all practice, and it's all valuable.

Plus, fun side projects keep the burnout monsters away.

6. Make More Questions 💡

No one knows everything. The smartest devs are just better at asking good questions and "googling" like pros (or using AI Ass...istants - looking at you, Vibe Coder 👀).
If you're stuck, ask. If you're unsure, ask. Just want to see if there’s a better way? Ask.
Google is your BFF, but don’t forget Slack, Stack Overflow, Reddit,... or even your work chat, it’s all fair game.

7. Take Breaks and Touch Grass 🌳

Seriously. Step away from the screen.
Burnout is real, and creativity needs breathing room. Go outside, stretch, cook something (I know you can't), or just lie on the floor for 10 minutes like a cat.

Your code will thank you later.

💻 Final Thoughts

Being a great frontend developer isn’t about knowing everything. It’s about being consistent, curious, and kind to yourself during the journey.
Grow one step at a time, and before you know it—you’ll look back and be amazed at how far you’ve come.

✨ Happy coding! ✨