리스코프 치환 원칙(LSP - Liskov Substitution Principle)
Hook/컴포넌트가 일부 props를 받아들이는 경우, 해당 훅/컴포넌트를 확장하는 모든 Hook과 컴포넌트는 확장하는 Hook/컴포넌트가 받아들이는 모든 props를 받아들여야 한다.
위의 훅을 사용하면 useLocalAndRemoteStorage는 useLocalStorage와 동일한 작업(로컬 스토리지에 저장)을 수행하지만, 데이터를 추가 장소에 저장하여 useLocalStorage의 기능을 확장했기 때문에 useLocalStorage의 하위 유형으로 볼 수 있습니다.
두 Hook에는 일부 공유 props와 반환값이 있지만, useLocalAndRemoteStorage에는 useLocalStorage가 허용하는 onDataSaved 콜백 props가 누락되어 있다. 반환 프로퍼티의 이름도 다르게 지정되어 있으며, 로컬 데이터는 useLocalStorage에서는 data로 이름이 지정되지만 useLocalAndRemoteStorage에서는 localData로 이름이 지정된다.
리스코프는 이를 지원하기 위해 Hook을 업데이트할 것입니다. 또한, useLocalStorage 훅의 로컬 데이터 변수 명도 useLocalAndRemoteStorage의 로컬 데이터 변수 명과 일치하도록 업데이트할 것이다.
Hook에 공통 인터페이스(들어오는 props, 나가는 반환값)가 있으면 교환이 매우 쉬워질 수 있다. 그리고 리스코프 치환 원칙을 따른다면, 다른 Hook/컴포넌트를 상속하는 Hook과 컴포넌트는 그 Hook이나 컴포넌트가 상속하는 Hook이나 컴포넌트로 치환할 수 있어야 한다.
React에서 LSP를 사용하는 이유는 무엇일까?
React에서 상속은 그다지 눈에 띄지는 않지만, 내부적으로는 분명히 사용된다. 웹 애플리케이션에는 종종 비슷해 보이는 컴포넌트가 여러 개 있기도 한다. 텍스트, 제목, 링크, 아이콘 링크 등은 모두 비슷한 유형의 컴포넌트이며 상속을 통해 이점을 얻을 수 있다.
IconLink 컴포넌트는 Link 컴포넌트를 래핑할 수도 있고 그렇지 않을 수도 있다. 어느 쪽이든 동일한 인터페이스(동일한 props 사용)로 구현하면 이점을 얻을 수 있다. 이렇게 하면 추가 코드를 편집할 필요 없이 애플리케이션의 어느 곳에서든 언제든지 Link 컴포넌트를 IconLink 컴포넌트로 교체하는 것이 간단하다.
Hook도 마찬가지이다. 웹 애플리케이션은 서버에서 데이터를 가져온다. 로컬 스토리지나 상태 관리 시스템을 사용할 수도 있다. 이러한 경우 props을 공유하여 상호 교환할 수 있도록 하는 것이 바람직하다.
애플리케이션은 백엔드 서버에서 사용자, 작업, 제품 또는 기타 데이터를 가져올 수 있다. 이러한 함수는 인터페이스를 공유하여 코드와 테스트를 더 쉽게 재사용할 수 있다.
