자기 자신을 호출하는 함수로써
재귀 함수를 잘 활용하면 반복적인 작업을 해야하는 문제를 좀 더 간결한 코드로 풀어낼 수 있습니다.
UI와 UX 모두 사용자에게 보이는 화면을 구성하는 방법, 사용자가 사용하게 될 기능을 구현하는 방식과 관련이 있다는 점에서 관련이 있습니다.
UI(User Interface, 사용자 인터페이스)는 사람들이 컴퓨터와 상호 작용하는 시스템을 의미하고,
UX(User Experience, 사용자 경험)는 사용자가 어떤 시스템, 제품, 서비스를 직•간접적으로 이용하면서 느끼고 생각하는 총체적 경험입니다.
UX는 UI를 포함하고. 또한 좋은 UX가 좋은 UI를 의미하거나, 좋은 UI가 항상 좋은 UX를 보장하지는 않습니다.
UI와 UX는 서로 다르지만 밀접한 관계이며, 서로를 보완하는 역할을 합니다.
장점:
CSS의 컴포넌트화로 스타일시트의 파일을 유지보수 할 필요가 없고, CSS 모델을 문서 레벨이 아닌 컴포넌트 레벨로 추상화할 수 있습니다. (모듈성)
JavaScript와 CSS 사이의 상수와 함수를 쉽게 공유 할 수 있습니다.
예를 들어, React에서는 props를 활용한 조건부 스타일링이 가능합니다.
마지막으로 짧은 길이의 유니크한 클래스를 자동으로 생성하기 때문에 코드를 경량화할 수 있는 것이 장점이 라고 생각했습니다..
단점 :
별도의 라이브러리를 설치해야 하므로 번들 크기가 커진다.
인터랙션한 페이지일 경우 CSS 파일을 따로 관리하는 방법에 비해 느린 성능을 보여줄 수 있다.
useRef는 리렌더링 하지 않는다. 컴포넌트의 속성만 조회&수정한다.
1.컴포넌트에 focus를 위치시킬 필요가 있는 경우.
예를 들어, 값을 여러개 일력하고 첫 번째 칸으로 이동해야 하는 경우 필요하다.
이것들 이외에도
텍스트 선택영역, 혹은 미디어의 재생을 관리할 때.
애니메이션을 직접적으로 실행시킬 때.
서드 파티 DOM 라이브러리를 React와 같이 사용할 때. 등
다양한 곳에서 사용이 가능합니다.
상태관리 라이브러리에는 여러가지가 있지만 대표적으로 Redux가 있습니다.
React 애플리케이션을 개발할 때 Redux를 사용하면 React 컴포넌트 간의 복잡한 데이터 흐름을 따라갈 필요가 없어집니다.
전역 상태 저장소가 있고, 어디서든 해당 저장소에 접근할 수 있다면 이러한 문제는 해결 된다.
Store는 상태가 관리되는 오직 하나뿐인 저장소의 역할을 합니다. Redux 앱의 state가 저장되어 있는 공간입니다.
Reducer는 Dispatch에게서 전달받은 Action 객체의 type 값에 따라서 상태를 변경시키는 함수입니다.
이때 Reducer는 외부 요인으로 인해 기대한 값이 아닌 엉뚱한 값으로 상태가 변경되는 일이 없어야하기 때문에 순수함수여야 합니다.
Action은 말 그대로 어떤 액션을 취할 것인지 정의해 놓은 객체이고,
Dispatch는 Reducer로 Action을 전달해주는 함수입니다.
각 개념들의 연결관계를 보자면,
짧게 요약하자면 Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 됩니다
개발자간 소통
여러 명의 개발자가 웹 페이지를 개발하면서 <div>
와 <span>
으로만 코드를 작성하면 요소의 이름을 보고서는 각 요소가 어떤 기능을 하는지 전혀 파악 할 수 없기 때문에 주석을 작성해서 설명하거나 id 나 class 를 사용해서 일일이 표기해야합니다. 시멘틱 태그들을 사용하면 부가적인 작업 시간을 줄일 수 있게 됩니다.
검색 효율성이 올라갑니다.
검색 엔진은 HTML 코드를 보고 문서의 구조를 파악하기 때문에,
시맨틱 요소를 사용하면, 어떤 요소에 더 중요한 내용이 들어있을지 우선 순위를 정할 수 있고, 우선 순위가 높다고 파악된 페이지를 검색 결과 상단에 표시할 수 있게 됩니다.
시맨틱 태그 만으로도 어느정도 광고 효과를 볼 수 있습니다.
마지막으로 웹 접근성의 향상입니다.
웹 접근성은 장애 여부, 사용 환경을 떠나서 항상 동일한 수준의 정보를 제공할 수 있어야 하는데 시멘틱 태그로
예를들어, 시각 장애인의 경우 웹 페이지에 접근할 때 음성으로 화면을 스크린리더를 이용하게 되는데요. 이 때, HTML이 시맨틱 요소로 구성되어 있다면 화면의 구조에 대한 정보까지 추가로 전달해줄 수 있어 콘텐츠를 좀 더 정확하게 전달할 수 있습니다.
결론부터 말하자면 클라이언트가 서버의 상황을 알 수 없기 때문에 발생할 수 있는 문제들임
IP 프로토콜은 IP주소를 컴퓨터에 부여하여, 지정한 IP 주소에 패킷(Packet)이라는 통신 단위로 데이터 전달하는 방식
(IP 패킷 : 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보 포함)
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송한다.
비신뢰성
1) 데이터의 소실
중간에 있는 서버가 데이터를 전달하던 중 패킷이 중간에 소실되어도 클라이언트는 파악할 수 없다.
2) 순서를 장담하지 못함
패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있어서 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있는 한계가 있습니다.
대부분의 파일 형식이 전송 가능합니다. 자주 사용하는 JSON, TEXT, IMAGE 파일이나 임성파일도 전송 가능합니다.
클라이언트 - 서버 구조입니다.
클라이언트의 요청이 있을 때 서버가 응답하는 단방향 통신입니다.
서버는 클라이언트에 요청하지 않으며 클라이언트의 요청에 대한 응답만 하게됩니다. 이때 서버의 응답에는 요청 처리에 따라 응답 코드가 다르게 오는데, 이에따라서 별도의 로직을 만들어 서버의 상황에 대한 대응이 가능해집니다.
크게 두가지
3. Stateless (무상태성)
HTTP통신에서 서버는 클라이언트의 상태를 저장하지 않습니다.
그 이유는 서버가 확장 가능해야 하기 때문입니다.
서버가 많아지면 많아질수록 서로간에 정보를 공유하기 위한 비용이 비싸집니다.
Stateless하게 사용할 경우 정보공유가 최소화되어 정보를 공유하기 위한 비용을 최소화 할 수 있습니다.
이런 특징 해결책은 쿠키와 세션 방식사용 입니다.
(
※ 쿠키 : 서버에 저장지않고 클라이언트에 저장되는 방식으로 개별 클라이언트 상태정보를 HTTP 헤더에 담아 전달하는 데이터입니다.
세션 : 쿠키와 반대로 클라이언트에 저장되는것이 아니라 서버에 데이터를 저장하는 방법입니다.
)
별도 옵션을 통해 일정시간 유지하게 할 수도 있긴 하지만 Connection을 유지하게 되면 지속적으로 리소스가 사용되기 때문에 연결 유지는 최소화 하는 것이 좋다고 알고 있습니다.
(이러한 특징의 해결책은 Keep-Alive 속성을 추가하는 것 등이 있습니다.
HTTP 1.0 이하 버전은 연결을 바로 종료했지만 HTTP 1.1부터 헤더에 Keep-Alive 옵션이 추가되어 연결을 지속시킬수 있게 되었습니다.)
쿠키가 유효한 기간을 정하는 옵션입니다.
MaxAge는 쿠키가 유효한 시간을 초 단위로 설정하는 옵션이고,
Expires은 쿠키의 유효 일자를 지정하는 옵션입니다.
(이때 옵션의 값은 클라이언트의 시간을 기준으로 합니다.)
이후 지정된 시간, 날짜를 초과하게 되면 쿠키는 자동으로 파괴됩니다.
만약 쿠키가 영원히 남아있다면 그만큼 탈취되기도 쉬워지기 때문에 이러한 유효기간을 설정하는 것이 보안 측면에서 중요합니다.
둘 다 설정하지 않은 쿠키를 세션 쿠키라고 하는데
브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키이고. 브라우저를 종료하면 해당 쿠키는 삭제됩니다.
(영속성 쿠키: 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효시간만큼 사용가능한 쿠키입니다.
)