프록시 구성 요소

재구성은..한 단어가 아니지만, 그것은 마땅히, 그것은 정의되어야 한다

To which degree or factor a piece of code or application is able to be changed with minimal impact on the code/application as a whole.

내가 보기에 재구성과 유지성은 밀접하게 관련되어 있지만 서로 독립된 개념이다.
유지보수 가능 코드는 작성할 수 있고 유지보수성을 유지하려고 노력할 수 있는 코드이다. 물론 우리 모두는 열심히 작성해야 한다
유지보수 가능한 코드, 그러나 재구성 가능한 코드는 무엇입니까?
나는 답이 있다고 생각하지 않는다. 나는 내가 최근의 한 항목에서 이 문제를 생각하고 있다는 것을 발견했다.
만약 우리가 위의 정의를 채택한다면 재구성 코드는 쉽게 변경할 수 있고 이 코드를 사용하는 다른 코드에 큰 영향을 미치지 않을 것이다.
나는 6개월 전의 소프트웨어 패키지를 사용하고 있으며, 전방 세계에서 남겨진 프로그램을 개발하고 있다.
낡은 소프트웨어 패키지를 가지는 것 자체는 문제가 되지 않지만, 응용 프로그램은 기본적으로 하나의 대형 동적 형식으로 처음 출현한 이래로 이미 많이 증가하였다.
우수한 formik 라이브러리를 사용했기 때문에 우리는 입력이 느린 문제에 부딪혔다.
그래서 저는 react-final-form 라이브러리를 사용해서 더욱 세밀한 입도 제어를 통해 렌더링을 최적화하기로 결정했습니다.
몇몇 초보적인 테스트를 통해 희망이 있어 보였기 때문에 formik를 바꾸기로 결정했을 때 나는 각 부품에 import { Field } from 'formik'을 뿌렸다.
탄식하다.
하지만 나는 빠르게 검색하고 바꿀 것이다import { Field } from 'formik' -> import { Field } from 'react-final-form'다 잘 될 거야, 그렇지?
그렇게 빠르지 않아, Field의 formik은 react-final-form의 아이템과 똑같은 아이템이 없어
따라서 제가 Field을 사용하는 곳마다 도구를 Field의 react-final-form 구성 요소의 기대에 부합하도록 변경해야 합니다.
나는 현지의 components/Field 구성 요소가 있는 것이 가장 좋다고 결정했다. 여기서 나는 도구를 react-final-form Field에 적합한 모양으로 바꾸었다

import { Field as FinalFormField } from "react-final-form"
export default function Field(props) {
  //... tranform the props
  return <FinalFormField {...transformedProps} />
}

나는 이제부터 행복한 생활을 하고 있다...거의 마지막 순간에 우리는 내부 구성 요소 라이브러리의 버전을 업데이트하기로 결정했는데 그 중에서 Input 구성 요소를 돌파적으로 변경했다.
도처에 우리가 수입한 것이다

import FormInput from "componentlib/lib/FormInput"

나 지금 하나 해야 돼.

import { FormInput } from "componentlib"

이봐, 이거 익숙해 보여.'제3자'구성 요소/라이브러리야. 변경이 필요해. 어떻게 해야 할지 알아.component/FormInput 구성 요소를 만들었습니다. 이 프로그램을 사용하고 새 버전의 구성 요소가 필요하면 한 곳에서 도구를 변환할 수 있습니다.

import { FormInput as XFormInput } from "componentlibX"
export default function FormInput(props) {
  //... tranform the props
  return <XFormInput {...transformedProps} />
}

이것은 또 몇 번을 반복해서 나로 하여금 이것이 좋은 모델인지 생각하게 했다.

패턴

For each component imported from a external library, create a local proxy component, so that if changes to the external library needs to be adapted
you can do it in one place

모든 비평범한 응용 프로그램에서 제3자 구성 요소를 사용해야 합니다.그러나 실제 구성 요소 구조를 작성할 때 material-ui 또는 uilibX에서 온 입력을 주의해야 합니까?
나는 항상 components/*에서 모든 구성 요소를 가져오는 것이 의미가 있다고 생각한다. 따라서 material-ui의 입력이 있다면 프록시 구성 요소를 만들어서 응용 프로그램에 사용해야 한다.

찬성 의견

은 타사 라이브러리를 추상화하여 한 위치에서 베이스 라이브러리를 변경하거나 업데이트할 수 있도록 합니다.

은 응용 프로그램의 측면에서 볼 때 로컬 구성 요소로만 가져올 수 있습니다. 이것은 특정한 라이브러리와 더 적게 연결됩니다. Input 구성 요소를 사용자 정의 입력으로 변경하려면 전체 코드 라이브러리의 100개 위치가 아닌 로컬 구성 요소에서 변경할 수 있습니다.

기만하다

은 제3자 구성 요소를 사용하고 싶을 때마다 약간의 비용이 들 수 있습니다. 응용 프로그램에 해당하는 구성 요소를 만들어야 합니다. 이것은 약간 군더더기를 느낄 수 있습니다.

에서 사용하는 라이브러리를 숨기는 것은 항상 필요하지 않습니다. 비록 Input 구성 요소 내부에 들어가면 어디에서 가져오는지 알 수 있습니다.

무엇이 코드를 재구성할 수 있습니까?
모든 구성 요소를 사용하는 데 영향을 주지 않거나 최소한 제어할 수 있는 방식으로 변경하여 밑바닥의 편의성을 변경할 수 있다.
상기 모드를 사용하면 우리는 기초 라이브러리를 업데이트하거나 직접 변경할 수 있으며 도구를 임시로 변환하여 우리가 더욱 제어할 수 있는 방식으로 사용하는 위치를 업데이트할 수 있도록 할 수 있다.

결어
이것은 새로운 일이 아니다. 우리는 응용 프로그램에서 제3자 구성 요소를 사용하는 더욱 구체적인 구성 요소를 만드는 데 익숙하다. 예를 들어 우리는 Login과 다른 조수를 사용하는 Auth0 구성 요소를 만들 수 있다. 이것은 단지 나의 생각일 뿐이다. 나는 어떻게 하면 나의 응용 프로그램이 라이브러리 등의 근본적인 변화에 더욱 적응할 수 있는지 생각한다.