상태란 컴포넌트 내부에서 변경 가능한 데이터를 의미합니다. 상태는 컴포넌트 내에서 변경되며, 이에 따라 컴포넌트가 다시 렌더링됩니다. React에서 상태는 클래스형 컴포넌트나 함수형 컴포넌트에서 uesEffect 훅을 사용하여 관리할 수 있습니다.
속성(prop)이란 컴포넌트에 전잘되는 읽기 전용 데이터를 의미합니다. 속성은 부모 컴포넌트에서 자식 컴포넌트로 전달되며, 컴포넌트 내에서 변경할 수 없습니다. 속성을 통해 부모 컴포넌트에서 데이터를 전달받아 사용할 수 있습니다.
상태와 속성을 잘 활용하여 React App을 개발하면, 유지보수성이 높고 코드의 가독성도 좋아집니다.
React에서 라이프사이클 메서드(lifecycle methods)는 컴포넌트의 생성, 업데이트, 제거와 관련된 이벤트에 대해 처리하는 메서드입니다. React 16 이전까지는 클래스형 컴포넌트에서만 사용할 수 있었지만, 16 이후부터는 함수형 컴포넌트에서도 사용이 가능해졌습니다.
React에서는 컴포넌트가 생성되고, 업데이트되며, 제거될 때 다양한 라이프사이클 메서드를 호출합니다. 이를 통해 컴포넌트가 마운트, 언마운트, 업데이트되는 동안 원하는 작업을 수행할 수
있습니다.
React의 라이프사이클 메서드는 크게 3가지 카테고리로 나눌 수 있습니다.
마운트(Mounting) : 컴포넌트가 처음으로 생성되어 DOM에 삽입되는 것
업데이트(Updating) : 컴포넌트가 업데이트 되는 것
언마운트(Unmounting) : 컴포넌트가 DOM에서 제거되는 것
React 16 이전의 클래스형 컴포넌트에서는 라이프사이클 메서드를 사용하여 위 세 가지 단계에서 원하는 작업을 수행할 수 있었습니다. 하지만 React 16 이후의 함수형 컴포넌트에서는 라이프사이클 메서드 대신에, useEffect 훅을 사용하여 원하는 작업을 수행할 수 있습니다.
React에서 라이프사이클 메서드를 사용할 때는, 컴포넌트의 상태와 속성에 대한 이해가 필요합니다. 라이프사이클 메서드를 적절히 활용하여, 컴포넌트의 마운트, 업데이트, 언마운트에 대한 동작을 제어할 수 있습니다. 그러나 최근에는 함수형 컴포넌트와 훅의 등장으로 라이프사이클 메서드를 사용하지 않고도 컴포넌트의 동작을 제어할 수 있게 되었습니다. 따라서, 최신 React에서는 라이프사이클 메서드 대신에 useEffect 훅을 사용하는 것을 권장합니다.
SPA는 한 개의 HTML 파일을 사용하고, 페이지의 일부분만을 변경하는 방식으로 동작합니다.
클라이언트 측에서 렌더링이 이루어지므로 서버 부담이 적습니다.
사용자 경험이 좋고, 빠른 속도를 제공할 수 있습니다.
초기 로딩 시간이 길고, SEO에 좋지 않을 수 있습니다.
CSR은 SPA의 한 종류로, 서버에서 제공되는 데이터를 받아와 클라이언트 측에서 렌더링을 수행하는 방식입니다.
초기 로딩 시간이 짧고, SPA처럼 빠른 속도를 제공할 수 있습니다.
SEO 문제와 초기 로딩 속도가 느릴 수 있는 단점이 있습니다.
SSR은 서버 측에서 HTML 파일을 생성하여 클라이언트에 전달하는 방식으로 동작합니다.
초기 로딩 시간이 빠르고, SEO에 우수합니다.
서버 부하가 높을 수 있으며, 전체적인 사용자 경험이 떨어질 수 있습니다.
초기 구성 비용이 높을 수 있습니다.
검색 엔진 최적화를 의미합니다. 즉, 검색 엔진에서 웹 페이지를 검색하여 순위를 매기는 방식에서 높은 순위를 얻을 수 있도록 웹 사이트를 최적화하는 기술이나 작업을 말합니다.
검색 엔진에서 사용자가 검색한 단어 또는 구를 검색해서 최적의 검색 결과를 보여주는데, 이 때 검색어와 관련된 웹 페이지를 높은 순위로 보여주는 것이 SEO의 목적입니다. 이를 위해서는 검색 엔진이 사용하는 알고리즘에 맞는 웹 페이지를 만들고, 검색 엔진이 크롤링하기 쉬운 웹 페이지를 만들어야 합니다. 이를 위해 HTML 태그, 제목, 내용, 이미지, URL, 링크 등에 키워드를 적절히 활용하고, 검색 엔진에서 웹 페이지를 검색하면 빠르게 로딩되는 웹 페이지를 제공하도록 개발합니다.
CORS(Cross-Origin Resource Sharing)는 웹 개발에서 발생하는 보안 이슈 중 하나입니다. 보안 상의 이유로, 브라우저는 한 도메인에서 실행되는 웹 페이지가 다른 도메인에 있는 리소스에 접근하는 것을 제한합니다.
CORS는 이러한 보안 이슈를 해결하기 위한 기술 중 하나입니다. CORS를 사용하면, 웹 페이지에서 다른 도메인의 리소스에 접근할 수 있습니다. 이를 위해 서버에서는 특정 HTTP 헤더를 설정하여, 클라이언트가 다른 도메인의 리소스에 접근할 수 있도록 허용합니다. 브라우저는 이러한 헤더를 확인하고, 해당 리소스에 대한 접근 권한이 있는지 확인합니다. 이를 통해, 서로 다른 도메인 간에도 안전하게 리소스를 공유할 수 있습니다.
CORS는 웹 개발에서 매우 중요한 보안 이슈이며, 개발자는 서버에서 CORS 설정을 올바르게 구성하여, 다른 도메인의 리소스에 대한 접근을 안전하게 허용해야 합니다.
CORS를 해결하는 방법은 크게 두 가지로 나눌 수 있습니다.
첫 번째 방법은 서버 측에서 CORS를 허용하는 설정을 추가하는 것입니다. 서버에서는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers와 같은 헤더를 설정하여 허용된 도메인에서만 리소스에 접근이 가능하도록 허용할 수 있습니다. 이를 통해, 브라우저에서는 서버에서 설정한 도메인에서만 리소스에 접근이 가능하도록 제한됩니다.
두 번째 방법은 JSONP(JSON with Padding)를 사용하는 것입니다. JSONP는 AJAX 요청을 보내는 대신, 동적으로 스크립트 태그를 생성하고, JSON 데이터를 콜백 함수로 전달하는 방식으로 동작합니다. JSONP는 브라우저에서 CORS를 우회하는 방법 중 하나이며, 서버에서는 JSONP 요청을 받을 수 있도록 응답을 구성해야 합니다.
서버에서 CORS를 허용하는 방법이 가장 일반적이며, 보안상의 이유로, JSONP는 사용하지 않는 것이 좋습니다. 따라서, 서버에서 CORS 설정을 제대로 구성하는 것이 중요합니다.
프록시 서버는 클라이언트와 서버 사이에서 중계 역할을 수행하며, 클라이언트와 서버 간의 통신을 대신 처리해줍니다. 클라이언트는 프록시 서버에 요청을 보내고, 프록시 서버는 서버에서 리소스를 가져와 클라이언트에게 반환해줍니다. 이를 통해, 클라이언트는 서버의 도메인과는 직접적으로 통신하지 않기 때문에 CORS 문제를 우회할 수 있습니다.
프록시를 이용하여 CORS 문제를 해결하는 방법은 보안성이 높아지는 장점이 있으나, 구성하기가 복잡하며, 프록시 서버의 성능 이슈가 발생할 수도 있습니다. 따라서, 프록시를 사용하는 경우, 이러한 문제들을 고려하여 적절하게 구성하는 것이 중요합니다.
프록시 서버란, 클라이언트와 서버 사이에서 중계 역할을 수행하는 서버를 말합니다. 프록시 서버는 클라이언트가 서버에 직접적으로 접근하는 것을 막고, 클라이언트와 서버 사이의 통신을 대신 처리해줍니다. 이를 통해, 클라이언트의 IP 주소나 위치 등의 정보를 숨기거나, 웹 콘텐츠를 캐시하여 빠른 로딩을 도와주는 등의 기능을 수행할 수 있습니다.
프록시 서버는 일반적으로, 브라우저나 애플리케이션 설정에서 직접 설정할 수 있으며, 클라이언트는 프록시 서버에 요청을 보내고, 프록시 서버는 서버에서 리소스를 가져와 클라이언트에게 반환해줍니다. 이를 통해, 클라이언트는 서버의 도메인과는 직접적으로 통신하지 않기 때문에, 보안성이 높아질 수 있습니다.
프록시 서버는 클라이언트와 서버 사이에서 중개자 역할을 수행하기 때문에, 웹 보안과 성능 개선 등에 활용될 수 있으며, 프록시 서버의 종류에 따라 다양한 기능을 수행할 수 있습니다.