DEV Community: Vladyusha

Why I Chose Copy-and-Paste Components Instead of an npm Package

Vladyusha — Wed, 29 Jul 2026 02:09:50 +0000

If you've used React for a while, you've probably installed dozens of UI libraries.

npm install some-ui-library

It feels like the obvious solution.

So when I started building Motoko UI, I asked myself:

Should this be another npm package?

The answer surprised me.

I decided not to build a traditional component library.

Instead, every component is copied directly into your project.

Here's why.

You Own the Code

One thing always bothered me about traditional UI libraries.

The moment you install them, part of your application lives inside node_modules.

If you need to tweak a component, you have three options:

Override styles
Wrap the component
Fork the library

None of them feels ideal.

With copy-and-paste components, the code becomes yours from day one.

Rename it.

Refactor it.

Delete half of it.

Change every animation.

No restrictions.

No Black Boxes

One of the best ways to learn React is by reading real components.

When the code is inside your project, everything is transparent.

You can immediately see:

how state is managed
how animations work
how accessibility is handled
how styles are structured

Nothing is hidden behind an API.

Easier to Customize

Every project has different requirements.

Different colors.

Different spacing.

Different animations.

Different coding styles.

Instead of designing hundreds of configuration options, I prefer something much simpler:

Just edit the component.

Better Long-Term Stability

Traditional packages evolve.

APIs change.

Breaking changes happen.

Version conflicts appear.

With copy-and-paste components, your project doesn't suddenly break because of a package update.

The component becomes part of your codebase.

You decide if—and when—to update it.

Less Dependency Weight

Every dependency introduces maintenance.

Even a small package has to be:

installed
versioned
updated
audited
kept compatible

Copy-and-paste components avoid adding another runtime dependency.

Once the component is in your project, it's simply your code.

Why the Registry Matters

Copying code manually doesn't scale very well.

That's why Motoko UI uses a registry compatible with the shadcn CLI.

Installing a component is as simple as:

npx shadcn@latest add @motokoui/theme-switcher

The CLI copies the files directly into your project.

No runtime package.

No hidden abstraction.

Just React components you own.

Are npm Packages Bad?

Not at all.

They're the right choice for many things:

state management
routing
data fetching
utilities

But UI components are different.

They almost always need customization.

For that reason, I think owning the source code is a better developer experience.

Final Thoughts

Building Motoko UI changed the way I think about component libraries.

Instead of creating another package that developers depend on, I wanted to create a collection of components they could truly own.

That philosophy influences every decision in the project—from the registry to the documentation to the component APIs.

I'm curious where the React ecosystem goes next, but for now, I believe copy-and-paste components offer one of the best experiences for building modern applications.

If you've built a component library yourself, I'd love to hear which approach you prefer: traditional npm packages or copy-and-paste components?

7 Lessons I Learned While Building an Open-Source React Component Library

Vladyusha — Wed, 29 Jul 2026 01:53:20 +0000

A few weeks ago, I started building Motoko UI, an open-source React component library.

The goal sounded simple: build beautiful, reusable components.

The reality was very different.

Here are seven lessons I've learned so far.

1. Building Components Is the Easy Part

The first few components took only a couple of days.

The documentation took longer.

The installation flow took longer.

The registry took longer.

It turns out that a component library is much more than a collection of components.

2. Developer Experience Matters More Than Fancy Animations

A beautiful component is useless if developers struggle to install it.

I quickly realized that reducing setup time was more valuable than adding another animation.

That's why I invested time in a registry and simple installation flow.

3. Documentation Is Part of the Product

I used to think documentation came after development.

Now I think documentation is development.

If users can't quickly understand how to use a component, the component effectively doesn't exist.

4. Small Releases Keep You Moving

Instead of waiting until everything was perfect, I started shipping small releases.

Every release adds a few components, fixes issues, and improves documentation.

That momentum makes the project feel alive.

5. Design Consistency Is Harder Than It Looks

Every new component introduces new decisions:

spacing
shadows
colors
border radius
animation timing

Without clear design principles, the library quickly becomes inconsistent.

6. Open Source Means Listening

Some of the best ideas didn't come from me.

They came from developers trying the project and asking:

"What if this component supported...?"

Those conversations improve the library more than coding alone.

7. The Project Is Never Finished

There's always another component.

Another improvement.

Another refactor.

I've stopped thinking about "finishing" the library.

Now the goal is simply to make it a little better with every release.

Final Thoughts

Building Motoko UI has already taught me far more than I expected.

Whether the project ends up with 100 stars or 10,000, the experience of designing, documenting, and maintaining an open-source library has been worth it.

If you're thinking about starting your own open-source project, my advice is simple:

Start before you think you're ready.

Website
Github

I Built Another React UI Library — Here's Why

Vladyusha — Wed, 29 Jul 2026 01:49:17 +0000

If you've been building React apps for a while, you've probably had the same thought:

"Not another React UI library..."

Honestly, I had it too.

The ecosystem already has amazing projects like shadcn/ui, Magic UI, Aceternity UI, Origin UI, and many others.

So why would anyone build another one?

It Started With Copying the Same Components

Every new project looked familiar.

I needed a modal.
Then tabs.
A tooltip.
A navigation menu.
A badge.
A hero section.

Sometimes I'd build them from scratch.
Sometimes I'd copy them from an old project.
Sometimes I'd spend an hour tweaking styles to match a new design.

Eventually I realized I wasn't building products—I was rebuilding the same UI over and over again.

I Wanted Components That Felt Production-Ready

Many libraries solve the problem of functionality.

I wanted to focus on something slightly different.

I wanted components that looked polished out of the box while still being easy to customize.

That meant:

Modern design
Smooth animations
Clean code
TypeScript-first
Tailwind CSS
Easy installation
No unnecessary abstractions

Why Not Just Use shadcn/ui?

I actually do.

Motoko UI isn't trying to replace shadcn/ui.

Instead, I see it as an extension of that ecosystem.

If shadcn/ui gives you the building blocks, Motoko UI focuses on higher-level components, interactive elements, and polished UI patterns that you can drop into real applications.

Building in Public

One decision I made early was to build everything in public.

Every component.
Every release.
Every improvement.

That keeps me accountable and gives other developers the opportunity to suggest ideas before they become part of the library.

The First Releases

So far I've added components like:

Accordion
Animated Tabs
Waves Shader
Theme Switcher
Badge
Modal
Tooltip

Along with:

Documentation
Registry support
Backgrounds & Shaders
Simple installation through the shadcn CLI

It's still a small project, but it's growing with every release.

What Comes Next

My goal isn't to create the biggest component library.

I want to create one that developers genuinely enjoy using.

Over the coming months, I'll be adding:

Dashboard components
Landing page sections
More shaders and animated backgrounds
Data visualization components
Better documentation
More polished developer experience

I'd Love Your Feedback

Open source gets better through feedback.

If you have ideas for components, improvements, or features you'd like to see, let me know.

And if you think Motoko UI is useful, I'd really appreciate a ⭐ on GitHub.

Thanks for reading.

Website
Github

Just Launched My Side Project — Would Love Your Feedback! 🚀

Vladyusha — Tue, 25 Feb 2025 08:57:13 +0000

Hey everyone! 👋

I’ve been working on a little side project called Rinkuit, and I’d love for you to check it out! It’s nothing too fancy, just something I built in my spare time, but I’m pretty excited about it. I’d really appreciate it if you could take a look, click around, and let me know what you think. Feedback is super welcome—good, bad, or ugly! 😄

👉 Visit Rinkuit

Thanks in advance, you’re awesome! 🙌

What’s New in React 19? A Quick Guide with Code Examples

Vladyusha — Mon, 02 Dec 2024 22:47:31 +0000

React 19 has arrived, bringing new features that make our apps faster and smarter while making development smoother. Here’s a quick look at the top highlights, complete with code snippets to get you started. 🚀

1. Enhanced Server Components

Server Components are now easier to use and more powerful. You can mix server-rendered and client-rendered components seamlessly.

Here’s a simple example:

// Server Component
export default function ServerComponent() {
  return <div>This is rendered on the server!</div>;
}

// Client Component
import ServerComponent from './ServerComponent';

export default function ClientComponent() {
  return (
    <div>
      <ServerComponent />
      <p>This part is interactive on the client.</p>
    </div>
  );
}

Result: Faster initial load times and better interactivity.

2. Smarter Concurrent Rendering

React 19 fine-tunes concurrent rendering. With useTransition, you can prioritize urgent updates while deferring others.

Example:

const [isPending, startTransition] = useTransition();

function handleClick() {
  startTransition(() => {
    setExpensiveState(someLargeData);
  });
}

Users won’t experience lag while React processes updates in the background.

3. Auto-Bundling for Lazy Components

Lazy-loading components is now simpler with auto-bundling, which ensures that only the required code is loaded.

Example:

const LazyComponent = React.lazy(() => import('./LazyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

No extra configurations—React handles the bundling for you!

4. Faster Hydration

Hydration is now selective, meaning React hydrates only what’s visible first. No extra code is needed—it’s enabled out of the box.

// In React 19, hydration automatically prioritizes critical content:
ReactDOM.hydrateRoot(document.getElementById('root'), <App />);

This speeds up interactivity for users with large apps.

5. New Hooks: `useOptimistic` and `useEvent`

useOptimistic hook simplifies optimistic UI updates by managing temporary state.
Example:

const [optimisticLikes, setOptimisticLikes] = useOptimistic(0, (prev, newLike) => prev + newLike);

function handleLike() {
  setOptimisticLikes(1); // Update UI instantly
  postLikeToServer();    // Sync with server in the background
}

Instant feedback for users, even with slow network responses.

useEvent helps with stable event handlers, avoiding unnecessary re-renders.
Example:

const handleClick = useEvent(() => {
  console.log('Button clicked!');
});

<button onClick={handleClick}>Click me!</button>

Cleaner code and improved performance in scenarios with frequent event handling.

Conclusion

React 19 is all about speed, efficiency, and developer happiness. From smarter hydration to exciting new hooks.

What feature are you most excited about? Share your thoughts in the comments!

More features https://react.dev/blog/2024/04/25/react-19

The Operator Survival Guide for TypeScript Devs

Vladyusha — Tue, 26 Nov 2024 15:54:57 +0000

Picture this: You're debugging your TypeScript code at 2 a.m.
Sipping on your nth cup of coffee(I don't drink coffee), and staring at line like this:

if (a == b) { /* mysterious bug */ }

“What's the problem? They look equal enough!” you think. But then you remember your strict buddy ===, who clearly needs to step in here.

TypeScript, like any good mentor, loves precision and order. Operators are its way of making sure your code knows exactly what you want from it.

In this article, we'll dive into the world of TypeScript operators, discover who they are, how they differ, and when to befriend them (or avoid them entirely).

Content:

Logical operators
Relational operators
Bitwise operators
Ternary Operator
Type Operators

Logical operators

Logical AND (`&&`)

Explanation
The && operator checks if both conditions are true. If one fails, it's game over.

Example:
Imagine you're trying to buy snacks from vending machine. You need money and the machine needs to works.

const hasMoney = true
const machineWorks = false
if (hasMoney && machineWorks) {
  console.log("Yay! Got my snack!")
} else {
  console.log("No snack for you.")
}

“I had the money, but the machine didn't cooperate. Guess I'm snackless today.”

Logical OR (`||`)

Explanation:
The || operator checks if at least one condition is true. It's all about backup plans!

Example:
You're craving pizza, but the local pizza is closed. Luckily, you've got leftovers in the fridge.

const pizzaPlaceOpen = false
const haveLeftovers = true
if (pizzaPlaceOpen || haveLeftovers) {
  console.log("Dinner is saved!")
} else {
  console.log("Time to go hungry.")
}

“Pizza place closed? No problem. Cold pizza it is!”

Logical NOT (`!`)

Explanation:
The ! operator flips a condition. True becomes false, and false becomes true.

Example:
Your friends says they're not coming to the party. But you know them: if they says no, it usually means yes.

const friendSaidNo = true
if (!friendSaidNo) {
  console.log("Surprise! They’re at the party!")
} else {
  console.log("Guess they’re serious this time.")
}

“Told you, they always show up last minute!”

Relational Operators in Action (`==`, `===`, `!=`, `!==`)

Equality (`==`)

Explanation:
The == operator checks if two values are loosely equal. It doesn’t care about their type, as long as they look the same.

Example:
Imagine your friend asks for “5 apples,” but you only have “5” written on a sticky note. They shrug and say, “Close enough!”

const applesOnNote = "5"
const applesNeeded = 5
if (applesOnNote == applesNeeded) {
  console.log("Friend: Good enough, I’ll take it.")
} else {
  console.log("Friend: Nope, I need *real* apples.")
}

“Turns out, a number written on paper isn’t quite the same as an actual apple.”

Strict Equality (`===`)

Explanation:
The === operator is more picky. It checks both value and type. No shortcuts here!

Example:
This time, your friend insists: “I need 5 actual apples, not just a sticky note with the number!”

if (applesOnNote === applesNeeded) {
  console.log("Friend: Perfect, these are actual apples.")
} else {
  console.log("Friend: Hey, this is just a note! Not what I asked for!")
}

“Lesson learned: Strict friends need strict checks.”

Inequality (`!=`)

Explanation:
The != operator checks if two values are not loosely equal. It doesn’t mind small mismatches, like different types.

Example:
You promise your friend you’ll bring “not oranges.” You show up with a basket of bananas.

const fruitBrought = "bananas"
if (fruitBrought != "oranges") {
  console.log("Friend: Thanks! At least it’s not oranges.")
} else {
  console.log("Friend: Seriously? I said no oranges!")
}

“Bananas passed the test, but only because the bar was so low.”

Strict Inequality (`!==`)

Explanation:
The !== operator makes sure values are not equal in value or type. It’s the strict version of !=.

Example:
Your friend clarifies: “I don’t just want ‘not oranges,’ I want something completely different, like actual fruit!”

const gift = "orange"
if (gift !== "oranges") {
  console.log("Friend: Thanks, this is acceptable.")
} else {
  console.log("Friend: Come on, I said no oranges, and this is one.")
}

“When your friend’s picky, even being close isn’t good enough.”

Let's get some rest

Here you can go with a cup of tea or coffee

Bitwise Operators in Action

"When your computer starts playing with bits like building blocks."

Bitwise AND (`&`)

Explanation:
The & operator compares two numbers bit by bit and keeps a 1 only where both bits are 1.

Example:
Imagine two friends trying to agree on a movie night. They’ll only go if both want to see the same movie.

const myPreference = 0b1010 // Movies A and C
const friendPreference = 0b1100 // Movies B and C
const mutualChoice = myPreference & friendPreference // Only C (0b1000)

console.log(mutualChoice ? "Movie night is on!" : "No agreement, no movie.")

"Friendship survives, but only if we both agree!"

Bitwise OR (`|`)

Explanation:
The | operator compares two numbers bit by bit and keeps a 1 if either bit is 1.

Example:
This time, you and your friend decide to list all the movies you’d consider watching — even if only one of you likes them.

const combinedChoices = myPreference | friendPreference // A, B, C (0b1110)

console.log("Here’s our list of possible movies:", combinedChoices)

"Compromise: we’ll pick from everyone’s favorites!"

Bitwise XOR (`^`)

Explanation:
The ^ operator compares two numbers bit by bit and keeps a 1 only where the bits are different.

Example:
You and your friend each make a unique suggestion for dinner. XOR helps filter out any overlap.

const uniqueChoices = myPreference ^ friendPreference // A and B (0b0110)

console.log("These are unique picks:", uniqueChoices)

"Let’s focus on what makes us different — in a good way!"

Bitwise NOT (`~`)

Explanation:
The ~ operator flips all the bits of a number. A 1 becomes 0, and vice versa.

Example:
Your pessimistic friend looks at your list and says, “Here’s what’s NOT on the table.”

const allOptions = 0b1111 // All movies
const notMyPreference = ~myPreference & allOptions // Movies B and D

console.log("Movies I don’t want:", notMyPreference)

"Fine, let’s skip my least favorites..."

Left Shift (`<<`)

Explanation:
The << operator moves the bits of a number to the left, filling in with zeroes on the right. It’s like multiplying by 2 for every shift.

Example:
Imagine packing for a trip. Each bag can hold double the amount if you rent a bigger car.

const bags = 0b0010 // 2 bags
const biggerCar = bags << 2 // 8 bags

console.log("We can pack this many bags now:", biggerCar)

"Time to bring more snacks!"

Sign-propagating Right Shift (`>>`)

Explanation:
The >> operator shifts bits to the right, keeping the sign (positive or negative). It’s like dividing by 2 for every shift.

Example:
You’re splitting up leftovers. Start with a big portion and share until it’s all gone.

let leftovers = 0b1000 // 8 portions
const nextPortion = leftovers >> 1 // 4 portions

console.log("Leftovers after sharing:", nextPortion)

"Sharing is caring, but don’t leave me hungry!"

Zero-fill Right Shift (`>>>`)

Explanation:
The >>> operator shifts bits to the right, filling with zeroes. It works the same for positive numbers but ignores signs for negatives.

Example:
Imagine clearing out space in your garage by throwing out junk. New space is always clean (zeros).

const junk = -8 // Negative binary
const clearedSpace = junk >>> 1

console.log("Cleaned-up garage space:", clearedSpace)

"Who cares if it’s negative? Clean slate it is!"

Ternary Operator

Explanation:
The ternary operator (condition ? expressionIfTrue : expressionIfFalse) is a shorthand for making quick decisions. Think of it as flipping a coin when you need to make a choice, but smarter — it looks at the condition and picks the right answer for you.

Example:
Imagine you’re deciding whether to take an umbrella before heading out. If it’s raining, you take one; otherwise, you don’t bother.

const isRaining = true
const umbrella = isRaining ? "Take the umbrella!" : "No umbrella needed."

console.log(umbrella)

"The sky decides for me: rain or shine, I’m ready!"

When NOT to use it:
The ternary operator is great for short and simple choices, but if you’re stacking a dozen conditions, you’ll end up with something that looks like a spaghetti monster:

// Don’t do this!
const mood = isRaining ? "sad" : isSunny ? "happy" : isCloudy ? "meh" : "confused";

"Readable code is happy code. Don’t overdo it!"

Type Operators

`typeof`

Explanation:
The typeof operator is like a detective — it checks the type of a value at runtime or extracts the type of a variable for use in your TypeScript code.

Example:
Imagine someone hands you a mystery box. You use a label scanner (typeof) to figure out if it’s a fruit or a gadget.

const mysteryBox = "apple"
const boxType = typeof mysteryBox

console.log(boxType === "string" ? "It’s a fruit!" : "Unknown gadget.")

"When in doubt, always check the label."

`keyof`

Explanation:
The keyof operator creates a type that includes all the keys of an object. Think of it as flipping through a dictionary to see all the available words.

Example:
Your friend hands you a shopping list, and you check what categories (keys) they’ve written down:

type ShoppingList = {
  fruits: string[]
  veggies: string[]
  snacks: string[]
}

type ListCategories = keyof ShoppingList // 'fruits' | 'veggies' | 'snacks'
const chosenCategory: ListCategories = "fruits" // valid!

"When you know all the categories, choosing one is easy!"

`Mapped Types`

Explanation:
Mapped types let you apply the same transformation to all properties of a type. Think of it as photocopying a document but adding a filter to every page.

Example:
Suppose you have a task list, and you need to mark every task as optional.

type TaskList = {
  homework: string
  chores: string
  shopping: string
};

type OptionalTaskList = {
  [Key in keyof TaskList]?: TaskList[Key]
};

// Result: All tasks become optional
const myTasks: OptionalTaskList = { homework: "Math" } // Valid!

"It’s like giving yourself an excuse to skip a task — because now it’s optional!"

`Conditional Types`

Explanation:
Conditional types let you write logic to decide between types based on conditions. It’s like asking, “If this happens, what should I do?”

Example:
Imagine deciding the size of a meal based on hunger.

type MealSize<HungerLevel> = HungerLevel extends "starving"
  ? "large"
  : "small"

type MyMeal = MealSize<"starving"> // 'large'
type FriendMeal = MealSize<"full"> // 'small'

"If you’re starving, go big. If you’re full, maybe just dessert!"

Practical Use:
Conditional types are powerful for creating reusable, dynamic types in your code. For example:

type Response<T> = T extends "success" ? { data: string } : { error: string };

"Adapt your type to the situation!"

A Quick Note from Your Friendly Guide

Before we wrap up, I have to confess: I didn’t include every single operator here. Why? Well, some operators are so simple they don’t need much explaining (like the classic = — we’ve all seen that one in action). Others just didn’t make the cut because I wanted to keep things snappy and focus on the fun and fascinating ones.

But hey, don’t just take my word for it! TypeScript has a treasure trove of operators waiting for you to explore. Head over to the official TypeScript documentation and give them a look. Trust me, your future self (and your code) will thank you.

"Because even the small and simple operators deserve some love, right?"

End

Thx for reading)

Subscribe to my telegram

DEV Community: Vladyusha

Why I Chose Copy-and-Paste Components Instead of an npm Package

You Own the Code

No Black Boxes

Easier to Customize

Better Long-Term Stability

Less Dependency Weight

Why the Registry Matters

Are npm Packages Bad?

Final Thoughts

7 Lessons I Learned While Building an Open-Source React Component Library

1. Building Components Is the Easy Part

2. Developer Experience Matters More Than Fancy Animations

3. Documentation Is Part of the Product

4. Small Releases Keep You Moving

5. Design Consistency Is Harder Than It Looks

6. Open Source Means Listening

7. The Project Is Never Finished

Final Thoughts

I Built Another React UI Library — Here's Why

It Started With Copying the Same Components

I Wanted Components That Felt Production-Ready

Why Not Just Use shadcn/ui?

Building in Public

The First Releases

What Comes Next

I'd Love Your Feedback

Just Launched My Side Project — Would Love Your Feedback! 🚀

What’s New in React 19? A Quick Guide with Code Examples

1. Enhanced Server Components

2. Smarter Concurrent Rendering

3. Auto-Bundling for Lazy Components

4. Faster Hydration

5. New Hooks: useOptimistic and useEvent

Conclusion

The Operator Survival Guide for TypeScript Devs

Logical operators

Logical AND (&&)

Logical OR (||)

Logical NOT (!)

Relational Operators in Action (==, ===, !=, !==)

Equality (==)

Strict Equality (===)

Inequality (!=)

Strict Inequality (!==)

Let's get some rest

Bitwise Operators in Action

Bitwise AND (&)

Bitwise OR (|)

Bitwise XOR (^)

Bitwise NOT (~)

Left Shift (<<)

Sign-propagating Right Shift (>>)

Zero-fill Right Shift (>>>)

Ternary Operator

Type Operators

typeof

keyof

Mapped Types

Conditional Types

A Quick Note from Your Friendly Guide

5. New Hooks: `useOptimistic` and `useEvent`

Logical AND (`&&`)

Logical OR (`||`)

Logical NOT (`!`)

Relational Operators in Action (`==`, `===`, `!=`, `!==`)

Equality (`==`)

Strict Equality (`===`)

Inequality (`!=`)

Strict Inequality (`!==`)

Bitwise AND (`&`)

Bitwise OR (`|`)

Bitwise XOR (`^`)

Bitwise NOT (`~`)

Left Shift (`<<`)

Sign-propagating Right Shift (`>>`)

Zero-fill Right Shift (`>>>`)

`typeof`

`keyof`

`Mapped Types`

`Conditional Types`