I have been curious about that how much effort developers have to make to adjust components to accommodate changes in UI design. Sometimes I think a design from UX is good and there's no problem for the developer to implement this new design, but the developers say this design is different from current component. Why can't they just change the component based on the design? Is it difficult for them?
This is a site for project management, not engineering, so I'm going to provide you a project management answer. If you want an engineering answer, you might have to find a different site to ask the question.
"Design" is often a term applied to some artistic rendering or wire-frame during product design, so it's more of a visual aid than a set of actionable specifications. There are exceptions (as there always are), but this is true often enough that you can generally assume that the user interface (UI) design (as opposed to the UI implementation) is easier to change than part of the product implementation itself.
There's no canonical answer here. The only generalizable solutions are better communication and collaboration between the roles of design and implementation.
Analysis and Recommendations
Depending on your product (let's pretend it's a web site for simplicity of the example), UI changes can be as simple as:
Can you please move this checkbox three pixels to the left?
and as hard as:
We want this field to be populated by the known set of users who live in Spokane with odd-numbered ZIP codes whose last name also ends in the letter
On its face, the first change is much easier to accomplish than making major changes to the back-end logic and database to implement the second change request. However, the only people who know for sure how difficult a change is are the people who need to make it, e.g. the designers, front-end developers, and back-end developers.
If you're lucky, all three things are handled by the same full-stack people, but at worst you should have all three skills sets represented within your team so that they can collaborate on the best way to implement any needed changes. Without that collaboration, and without communication and estimates from the people who will actually do the work, it's impossible to accurately assess the level of complexity for any part of the proposed work.
The project leadership's input should be a what, e.g. what changes need to be made in order to meet some measurable business objective. The team's input should be a how, e.g. how the team can most effectively meet the new product objective given the current state of the product, the skills and tools available to the team, and the level of effort involved in the ask.
The only way to accurately get that information is to ask the people involved. Ask the designers why they need this change. Ask the change-implementers what the change involves for them, and if there are options or circumstances that might affect the level-of-effort needed to implement the change.
If you're looking for a universal, canonical answer: there isn't one. However, as a purely pragmatic rule of thumb design is easier than implementation, especially if the implementation is treated as a downstream or "over the wall" task that doesn't take the complexity of implementation into consideration. The only generalizable solutions are better communication and collaboration between the roles of design and implementation. If it's not your role to facilitate that, then please escalate it to the role that does own the collaboration and communication within the product development organization.
Sometimes I think a design from UX is good and there's no problem to develop this design.
So... two people with no development skills think something must be easy to develop...
why they don't change component based on design? Is it difficult for them?
... and the actual developers tell you it's not.
Yes, developing components based on requirements is their job. And I will assume they can do it. It's not difficult per se. However, since it is very common for neither the UX guy nor the project manager to actually know anything about development, it mainly goes like this:
Hey, Mr. Car Mechanic, Sir, I was at the lake yesterday and it looked amazing. All those fine vehicles with all the little flags they had flying. I want them for our vehicles, too. Our marketing department is hyped. This is the best idea ever. We will sell millions. So when can we have a main mast on our car roof to fly our flags? ... What do you mean "it's difficult"? ... Don't you know how to work on cars?
There are things that are "standard". Changing tires. Changing gearboxes. Redoing the paint job. Those are normal. They take a little time, but it's nothing out of the ordinary.
In programming, that would be "picking a date from the operating systems calendar control" or "listing all images and have them wrap around on small screens by the predefined algorithm of the platform".
Now, what I do see in practice is that for example the UX person is not happy with the calendar control that exists and wants changes. But you cannot just "change" it, you can only redo it from scratch. Basically writing a new one. The same way that having a main mast coming out of the car roof will probably require a full remodel/rebuild.
Is it difficult? No. Someone wrote the original, they weren't a super hero genius either. It's just work. But it's a lot of work to do. We have an app where we have a built calendar control from scratch because the product owner did not like the look and feel of the native control. I think we spent easily a six-figure sum on this until it was done (planing, developing, redesigning, planning, developing, bugfixing the myriads of edge cases dates and timezones have, thinking about all the gestures and typing you could do to enter dates in different formats, testing, QA...). This money could have easily been used to develop a productive feature, instead of "another design" for an existing feature.
So I applaud every UX designer that comes up with new and innovative ways to do things. But the project manager has to keep tabs on the price of this design. As in manufacturing, making more of "the same old" comes cheap, making something new is extremely costly in comparison.
So for example, if you build a little app (lets say a few months with a few people, standard components used, ~100.000$) you have to decide whether it's worth to add another pricetag and double, triple or quadruple the price just because you don't "like" for example Material Design. Or the Apple look and feel. Or whatever device you are on. If you have that amount of cash to just throw out on looks, by all means, go for it. But the developers would probably be a little insulted if you told the world they needed a year and a half for that app. Because the app was functionally done after a few months.
So just get two price tags... let your developers tell you what they need to make your product. And then let them tell you what they need to make it to UX specifications. The difference is caused by the UX designer deviating from what is normal for that platform. You can like it and pay for it. But you need to be clear on the fact that you paid this extra price for design, not development.
Everybody is entitled to have a main mast through the roof of their cars if they can pay for it, but don't blame the mechanic for the price it costs or the manhours they spent.