Wrapping ReactJS UX component library in another layer of abstraction, pros and cons?

Question

There's AntD library with various UX components. Right now I required to wrap all components which I'm using in another layer, to make an abstraction. For example, if I'm using AntForm component I required to wrap it as follows:

import React from 'react';
import AntForm from 'antd/es/form';

import { FormProps } from './form.types';

export function Form(props: FormProps): JSX.Element {
  return (
    <AntForm {...props} />
  );
}

and redefine all types internally in form.types.ts as following:

export interface Form { ... }

The justification which I get for this step that if we ever will be required to change a library, we will need to make changes to only this abstraction layer the rest of the code will remain untouched.

I don't like this approach. It requires a tremendous amount of work, especially redefine all the types, and internal types, and internal types of internal types. Personally I would avoid such an architecture solution, especially redefine all the types. In this way, we become bound to specific AntD implementation, and if it will be break changes in AntD, it adds another layer where we will need to make changes. Another point against it, if we will ever need to change the library, we, in any case, will be required to change all the components which using this library, it can't be done 100% abstraction, but it's just a gut feeling based on my previous experience and most likely biased.

Before I'm going to discuss with other people regarding this issue I would like to hear another unbiased opinion, cons, and pros of such an approach.

Answer 1

This is one of those things where I both understand it and I don't at the same time. There is something to be said for not tying yourself to a given library, especially if it looks likely (or even just somewhat possible) that that library will stop being maintained in the future or that there is a reasonable chance you would need to change. It does give you flexibility to change things if needed. However, its also a lot of work. If there isn't a good reason to do that work (and just saying we want the flexibility without being able to justify a real, concrete need for it doesn't count for me), then it isn't worth doing. It feels like lots of future proofing for a need you may never have.

If you somehow do have this need or your company/team decides to go through with this anyway, the way you are doing it adds no value. If your "abstraction layer" isn't abstracting things and is just copying the underlying library, you aren't distancing yourself from the library in any way. If the replacement library you choose doesn't support things that the current one does, you are going to have to change calling code anyway. (Assume the current library supports an on-foo event that you use all throughout your code. Assume the replacement library doesn't support that at all. Now you have to change your abstraction layer to support this somehow or, if that isn't possible, you have to change all the calling code to do something different now.)

If you are going to create an abstraction layer, you need to define what capabilities that layer needs to support. Then that abstraction layer (aka facade/adapter pattern) is going to provide a translation from your defined interface to the library's interface. That would be a much more useful way of writing it. That would give you the flexibility your team is trying to achieve. Just copying AntD's interfaces means any future library is going to have to look and behave like AntD. Which begs the question, if you want AntD's interfaces and behavior, why are you switching from AntD?