2022/056 [React] React-dom에서의 innerHTML 리액트의 경우 리액트(jsx,정의 등)와 렌더러(웹의 경우 보통 react-dom)를 사용해서 어플리케이션의 UI를 렌더링한다. 렌더러의 경우 그 내용이나 구조등이 복잡한 편이라 정리해서 쪼개서 글을 쓰자니 너무 양이 많아지는 문제점이 있다. 그래서 소스코드 일부를 작게작게 쪼개서 정리하는 포스팅을 추가적으로 하기로 했다. 리액트의 경우 v-dom을 만들어서 DOM 자체를 리액트에서 관리하다보니 XSS 공격등 상대적으로 프론트엔드 영역에서의 보안이 안정적이다. 내부 dom을 직접 모두 관리하고 innerHTML등의 기존 js API를 최대한 사용하지 않아서 그런데 문제는 개발을 하다보면 innerHTML등의 API가 필요한 상황이 존재한다는 것이다. HTML 태그가 포함된 문자열을 DOM으로 추가하는 경.. 2022. 5. 31. 프론트엔드 설계 고민 -4- UI적인 측면은 컴포넌트와 아토믹 패턴을 통해서 feature를 구성한다. 데이터 처리 관련은 스토어, 커스텀훅(컨테이너)으로 처리한다.(model, viewmodel) 그렇다면 공통 feature는 어떻게 처리할까? 그러니까 위젯처럼 동일한 UI로 데이터 패칭이 필요해서 그 컴포넌트 내부에서 데이터를 패칭하고 그 구성을 여러 도메인에서 가져다 쓰는 경우가 존재 하는 경우 말이다. 개인적으로는 이럴 경우 해당 로직이 아예 동일하다 할지라도 도메인 영역이 다르기 때문에 공통되는 feature를 공유하기 보다는 같이 쓰는게 맞다고 본다. 도메인 별로 컨셉이 달라질 수 있는데 그럴 경우 영향을 받는게 바람직 하지 않다고 생각 되기 때문이고, 만약에라도 도메인에 상관 없이 동일한 인터페이스와 데이터를 제공해야 .. 2022. 5. 21. 기술부채에 대하여. 개발자는 좋은 소프트웨어를 만들기 위해서 노력해야 한다. 그렇다면 좋은 소프트웨어라는 것은 무엇일까? 견고한 아키텍처와 잘짜여진 코드? 물론 맞다. 많은 사용자가 사용하는 소프트웨어가 견고한 아키텍처를 가져서 안정적이고 잘 짜인 코드로 기능의 개선이나 확장이 용이하면 잘 만들어진 소프트웨어다. 다만 소프트웨어 자체의 품질 이전에 결국 소프트웨어는 사용자에게 중요한 가치를 제공 할 수 있어야 한다. 이것을 다른 사람들은 비즈니스로 표현하던데 좀 더 간단히 말하면 그냥 목적이다. 해당 소프트웨어를 통해서 이루고자 하는 목적에 적합한 소프트웨어가 좋은 소프트웨어다. 그게 잘 만들어졌다면 더 좋고, 그럼 잘 만들어지고 좋은 소프트웨어가 된다. 이건 굳이 개발이 아니라도 당연한 것이다. 어떤 행위는 특정 목적에 .. 2022. 5. 11. SOLID 원칙에 대하여 SOLID: 단일 책임, 개방 폐쇄, 리스 코브 치환, 인터페이스 분리, 의존성 역전 원칙을 두 문자어 법칙으로 정리한 용어. 객체 지향 설계에 대한 원칙이라고 하지만 사실 모던 프로그래밍 전반에 널리 적용되는 클린 코드 원칙이라고 볼 수 있다. 해당 원칙을 한마디로 간단히 정리하면 하나의 책임 단위로 코드를 잘 분리해서 잘 추상화 시키고 추후 변경이 적게 설계해라이다. 단일 책임 원칙의 경우 하나의 객체가 하나의 책임을 가지도록 설계하는 원칙이다. 그 책임에는 명확한 범위가 없다. 예를 들어서 식사라는 프로그램을 만들려고 하면 식사라는 행위 자체가 하나의 책임이 될 수 있고 그 식사를 사람과 메뉴, 식기, 예절, etc 등의 세부적인 책임으로 분리할 수 있다. 이걸 어떻게 분리하는지는 판단에 따라 다르.. 2022. 5. 4. 이전 1 2 다음