프론트 엔드 프레임 워크에 대해 들어봤을 것입니다. 

튜토리얼과 해커 뉴스 토론에는 React, Vue 및 Angular와 같은 이름이 많이 있습니다. 

이러한 프레임 워크를 사용하는 이유와 시기, 프로젝트에서 프레임 워크를 구현할 시기인지 궁금한 경우 혼자가 아닙니다. 몇 년 전, Hackterms라는 부업 프로젝트를 진행하면서 제 프론트 엔드가 다루기 어려워졌습니다. 

프레임 워크 구현이 올바른 다음 단계라는 것을 느꼈지만, 그들이 한 일에 대해서는 거의 알지 못했습니다. 

(기사 마지막 부분에서 그 결과를 다시 살펴 보겠습니다.) 이것이 내가 원하는 설명입니다. 

이 글에서는 프론트 엔드 프레임 워크가 해결하려고 하는 문제와 언제 이를 사용하고 싶을 지에 대한 조감도를 살펴 봅니다.

https://stackoverflow.blog/2020/02/03/is-it-time-for-a-front-end-framework/ 

구체적으로 살펴 보겠습니다.

1. 프런트 엔드가 어떻게 성장하는지
2. 확장에 따라 발생할 수 있는 아키텍처 문제
3. 프론트 엔드 프레임 워크가 이러한 문제를 해결하는 데 어떻게 도움이 될 수 있습니까?
4. 다른 대안도 고려해보십시오.

요약 :“프론트 엔드 프레임 워크”는 복합 형용사이므로 하이픈을 받습니다. 그러나 앱에는 "프론트 엔드"(명사, 하이픈 없음)가 있습니다. 나와 함께 살아남아

검토 할 용어 

우리는 프론트 엔드 프레임 워크에 대해 이야기 할 것입니다 (제목에서 힌트를 얻었을 것입니다).

소프트웨어 프레임 워크는 미리 작성된 앱 구조입니다. 

실제로, 그것은 당신이 당신의 자신의 코드와 파일을 추가하는 파일과 디렉토리의 모음입니다. 

프레임 워크는 일반적인 개발 문제를 해결하여 응용 프로그램을 보다 빠르게 빌드하고 다음과 같이 시작합니다.

• 대부분의 응용 프로그램에서 재사용 되는 기능을 다루는 상용구 코드.
• 디자인 철학을 따르는 디렉토리 구조.
• 응용 프로그램 유형에 자주 발생하는 일련의 설계 원칙. Ruby on Rails와 같이 이러한 원칙을 적용하는 프레임 워크는 일반적으로 의견이 있습니다.

프런트 엔드는 응용 프로그램의 프레젠테이션 계층입니다. 

종종 사용자가 보는 모든 것으로 묘사되지만,보다 일반적으로 사용자에게 데이터를 효율적으로 표시하는 역할을 하는 코드입니다. 

따라서 프런트 엔드에는 직관적이고 쾌적한 인터페이스를 구축 할 수 있을뿐 아니라 백엔드 또는 API에서 수신 한 데이터를 효율적으로 저장, 표시 및 업데이트 할 수 있습니다.

프론트 엔드 프레임 워크는 프론트 엔드를 구축하기 위한 스캐 폴드입니다. 

일반적으로 파일을 구성하는 방법 (예 : 구성 요소 또는 CSS 전처리기를 통해), AJAX 요청, 구성 요소 스타일 지정 및 데이터를 DOM 요소와 연결하는 방법이 포함됩니다.

성장하는 앱 

HTML, CSS 및 JavaScript의 세 파일만으로 간단한 프론트 엔드를 작성할 수 있습니다. 

그러나 앱이 확장됨에 따라 파일도 함께 커져서 다루기 어렵고 유지 관리 할 수 없는 스파게티 코드가 채워집니다.

전통과 마찬가지로 어리석은 예를 살펴 보겠습니다. 경쟁 보드 게이머를 위한 리더 보드 인 MySquare를 구축한다고 가정 해 보겠습니다. 

이 앱에서 사용자는 자신이 플레이 한 보드 게임, 리그 승인 경쟁 결과 (현재 리그가 포함되어 있음) 및 경쟁 경기에 대한 간단한 리뷰를 공유 할 수 있습니다. 

앱의 가장 중요한 기능은 사용자 프로필 페이지입니다.

HTML, CSS 및 JavaScript의 세 가지 기본 기술을 사용하여 이 프로파일 페이지의 첫 번째 버전을 빌드합니다. 다음과 같이 작동합니다.

• 초기 페이지 로드시 백엔드는 초기에 최소한의 스타일링으로 빈 프로파일 페이지를 보냅니다. 그런 다음 모든 향후 로드에 대해 프론트 엔드는 AJAX를 통해 사용자 데이터를 요청합니다.
• 백엔드는 일부 공용 사용자 데이터를 JSON으로 전송하고 JavaScript를 사용하여 게임 배지 및 레코드에 대한 DOM 요소를 페이지에 동적으로 추가합니다.
• 모든 사용자와 그 기록을 나열하는 게임 별 페이지를 만들려고 하면 동일한 게임 데이터를 사용하므로 많은 코드를 복제하는 새 JavaScript 파일을 만듭니다.
• 각 게임 배지 (및 일치 배지)는 동일한 HTML을 사용하므로 마크 업을 JavaScript 문자열에 저장하고 게임 특정 데이터를 주입 할 수 있는 방법을 찾아야 합니다. 예 :“<p> {{Game Name}} </ p>”. 그런 다음 모든 게임의 페이지에 배지 HTML을 추가합니다.
• 사용자가 페이지에서 일부 값을 업데이트하면 속성을 쿼리하거나 모든 요소에 이벤트 리스너를 연결하여 DOM에서 데이터를 읽어 DOM에서 데이터를 읽을 수 있습니다.

MySquare가 대중화되고 데이터 세트가 커짐에 따라 이 접근 방식은 빠르게 다루기 어려워집니다.

• <div> 값을 가져 오거나 ID 또는 데이터 속성을 읽어 페이지에 데이터를 추가 한 다음 DOM에서 읽습니다.
• JavaScript 및 CSS 파일의 수가 많아지고 그 사이에 반복되는 코드가 많이 있습니다.
• 입력 리스너 및 버튼과 같은 일반적인 UI 요소에 이벤트 리스너를 바인딩 한 다음 동일한 요소의 값을 업데이트하는 함수를 작성합니다.
• 약간만 변경해야 하는 경우 나머지 애플리케이션에 어떤 영향을 줄지 걱정됩니다.
• 친구가 개발 작업에 도움을 주겠다고 제안하면 (물론 일부는 물론) 코드 작동 방식을 설명하는 데 몇 시간을 보냅니다.

바닐라 JavaScript와 충분한 인내심으로 이러한 문제를 관리 할 수 ​​있습니다. 

계획과 예측을 통해 이러한 문제 중 일부를 예상하도록 앱을 구성 할 수 있습니다. 

그러나 프런트 엔드가 커짐에 따라 이러한 문제는 심화 될 뿐이므로 앱이 어떻게 발전 할 것인지 확신 할 수 없습니다.

DOM에 데이터를 저장하고 JavaScript 문자열에 저장된 HTML을 끊임없이 추가하는 것이 이 프로젝트를 수행하는 가장 좋은 방법은 아니라는 것을 알고 있습니다. 

다행히 휠을 재발 명할 필요가 없습니다. 견고하고 유지 관리가 가능한 UI를 구축해야 할 때가 왔다고 생각합니다. 

프론트 엔드 프레임 워크

Enter, framework 

많은 응용 프로그램에서 프런트 엔드가 커지고 예측 가능한 방식으로 변형되기 때문에 프런트 엔드 프레임 워크가 존재합니다. 

각 프레임 워크는 고유 한 디자인 철학을 제공하지만 이전에 겪었던 것과 동일한 일반적인 문제를 해결하려고 합니다.

• 코드는 유지 관리가 쉬워야 합니다. 본인과 다른 사람이 쉽게 읽고 테스트하고 변경할 수 있습니다.
• 복잡한 인터페이스는 일반적으로 동일한 구성 요소로 구성됩니다. 이러한 구성 요소를 작성하고 재사용하여 새 페이지를 쉽게 작성할 수 있어야 합니다.
• DOM 조작이 느리기 때문에 가능한 적은 요소 업데이트를 수행하려고 합니다.
• 데이터를 기반으로 UI를 쉽게 조작 할 수 있어야 합니다.
• UI는 일관되고 직관적이어야합니다. 이는 타이포그래피, 색상, 버튼, 입력 및 기타 요소를 표준화 하는 것을 의미합니다.
• 이러한 일반적인 프론트 엔드 문제를 해결하기 위해 휠을 재창조하고 수많은 상용구를 작성할 필요는 없습니다.
• 아이디어와 패턴을 다른 개발자와 의사 소통 할 수 있는 공통 언어가 있어야 합니다.

다른 프레임 워크는 이러한 질문 중 일부를 다루지 만 대개는 전부는 아닙니다. Bootstrap 및 SemanticUI와 같은 일부는 일관된 시각적 디자인을 강조하여 읽기 쉽고 유지 관리 가능한 HTML 및 CSS를 만드는 데 중점을 둡니다. 

Vue, React 및 Angular와 같은 다른 애플리케이션은 애플리케이션 전체에서 데이터 흐름을 구성하는 데 도움이 되므로 DOM이 아닌 데이터 조작에 집중할 수 있습니다.

(Sarah Drasner는 DOM에서 데이터를 읽고 JS에 저장하는 것의 차이점을 보여주는 환상적인 소개를 제공합니다. 그녀의 예제는 jQuery에서 Vue 로의 전환에 대해 설명하지만 DOM 조작에서 데이터에 초점을 맞추는 것에 이르기까지 더 넓은 사고 방식 전환으로 읽을 수 있습니다. 구조.)

React와 같이 널리 사용되는 프론트 엔드 프레임 워크를 구현 한 경우 MySquare는 어떤 모습입니까? 다음과 같은 몇 가지 변경 사항이 있습니다.

1. 게임 배지, 경기 기록 및 기타 일반적인 요소에 대한 데이터 자리 표시 자와 함께 재사용 가능한 HTML / CSS / JavaScript 구성 요소를 만듭니다. 그런 다음 프레임 워크는 들어오는 데이터 (서버 또는 API에서 얻은 JSON)를 기반으로 이러한 요소를 렌더링 합니다. 예를 들어 JSON에 9 개의 게임 레코드가 있는 경우 일치 데이터가 자동으로 삽입 된 9 개의 <Match> 구성 요소를 렌더링 합니다.
2. 상용구 디렉토리 구조에 따라 구성 요소, 스크립트 및 스타일 시트를 쉽게 따르고 유지 보수 할 수 있는 방식으로 작성합니다. 게임 레코드의 구조와 스타일을 변경해야 합니까? 작은 독립형 <Match> 구성 요소를 찾아 변경하십시오.
3. 간결하고 표현력 있고 현대적인 코드를 작성하기 위해 최신 JavaScript 기능과 SASS와 같은 CSS 프리 프로세서를 활용할 수 있습니다. 프레임 워크는 이를 브라우저가 이해하는 HTML / CSS / JavaScript로 변환합니다.
4. 이 인프라를 사용하면 DOM에 대해 걱정하지 않고 데이터 조작에 집중할 수 있습니다. Google 프레임 워크의 데이터 바인딩 기능은 데이터가 변경 될 때 관련 구성 요소를 자동으로 다시 렌더링 합니다. 예를 들어, 서버에서 새로운 일치 결과에 대한 데이터를 수신하면 프레임 워크는 자동으로 다른 <Match> 구성 요소를 화면에 추가합니다.
5. 문제가 발생하면 프레임 워크 커뮤니티를 활용하여 도움을 받을 수 있습니다. 널리 사용되는 프론트 엔드 기능을 구축하는 데 도움이 되는 프레임 워크 규칙을 따르기 때문에 문제를 쉽게 설명 할 수 있습니다.
6. 널리 사용되는 프레임 워크는 유사한 디자인 원칙을 따르기 때문에 특정 프레임 워크에서 개발하지 않은 개발자까지도 다른 개발자와 공동 작업하는 것이 더 쉬울 수 있습니다. 새로운 개발자에게 고유 한 사용자 지정 코드 구조를 안내하지 않아도 됩니다.

Separation of concerns 

이상적으로는 프런트 엔드가 독립 실행 형 응용 프로그램으로 작동하여 백 엔드에서 데이터를 요청하고 처리하고 표시하는 것이 좋습니다 ( "API 소비"라고 들릴 수 있음). 이를 뒷받침하는 원칙을 "관심 분리"라고 하며, 프로그램의 각 부분이 독립적으로 작동하고 명확하고 독창적 인 목적을 가지고 잘 정의 된 인터페이스를 통해 통신해야 한다고 명시되어 있습니다. 프론트 엔드가 우려 분리 원칙을 따르기 위해 프레임 워크를 구현할 필요는 없지만 대부분의 프레임 워크는 이 아키텍처 패턴을 권장합니다.

결과 모듈 식 설계의 장점은 개발자가 컴포넌트가 예측 가능한 입력을 수용하고 예측 가능한 출력을 제공하는 한 애플리케이션의 다른 부분에서 독립적으로 작업 할 수 있다는 것입니다. 단일 책임 (동일한 원칙을 따르는 모듈 식 구성 요소로 구성)으로 프론트 엔드를 갖추면 변경에 쉽게 적응할 수 있습니다. 예를 들어 Angular에서 React로 이동하기로 결정한 경우 자신 있게 그렇게 할 수 있습니다. 두 프레임 워크 모두 백엔드의 데이터를 필요로 하므로 프런트 엔드가 더 큰 애플리케이션에 포함되는 방식이 아니라 React의 인터페이스가 해당 데이터를 수신하는 방법과 데이터 사용 방법에 집중할 수 있습니다.

응용 프로그램의 전용 뷰 계층 인 프런트 엔드는 전적으로 논리에 대한 책임을 져야 합니다.

....