0

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.

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?

  • Paradoxically, but your answer caused me to believe that it isn't such a bad solution. The point which you raised about lack of functionality in a new library can be easily solved by extending new libraries's component which easily can be done in React. But anyway I'll bring it to the team and we will need to answer the questions you raised here. After that, it will be much easier to decide to abandon or stay with this approach. Thank you for your answer! – Anatoly Jan 14 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.