JSP 스크립틀릿이 나쁜 경우 왜 JSX가 좋은가요?


21

React.js는 컴포넌트 및 요소 트리를 구성하기 위해 XHTML과 유사한 구문으로 JSX를 제공합니다. JSX는 Javascript로 컴파일되며 JSX에서 루프 또는 조건을 제공하는 대신 Javascript를 직접 사용합니다.

<ul>
  {list.map((item) =>
    <li>{item}</li>
  )}
</ul>

내가 아직 설명 할 수 없었던 것은 JSP에서 유사한 구조가 나쁜 것으로 간주되면 왜 이것이 좋은 것으로 간주됩니까?

JSP에서 이와 같은 것

<ul>
   <% for (item in list) { %>
     <li>${item}</li>
   <% } %>
</ul>

와 같은 태그로 해결해야하는 가독성 문제로 간주됩니다 <c:forEach>. JSTL 태그의 이유는 JSX에 적용될 수있는 것처럼 보입니다.

  • XHTML과 유사한 구문 (앵글 괄호, 중첩)과 Java / Javascript (곱슬, 쉼표, 괄호)를 토글하지 않을 때 읽기가 조금 더 쉽습니다.
  • 렌더링 기능 내에서 사용할 수있는 전체 언어와 플랫폼이 있으면 그에 속하지 않는 논리를 사용하지 않는 것이 좋습니다.

JSX가 다른 이유를 생각할 수있는 유일한 이유는 다음과 같습니다.

  • Java에서는 잘못된 일을 할 동기가 있습니다. JSP는 핫 리로드되므로 재 빌드 / 재시작주기를 피하기 위해 JSP에 코드를 넣는 것이 좋습니다. 즉각적인 생산성을 위해 유지 보수성이 희생되었습니다. 스크립틀릿을 제거하고 고정 된 템플릿 구성 세트로 제한하는 것은 사실상 유지 관리 성을 강화하는 방법이었습니다. JS 세계에는 그러한 왜곡이 없습니다.

  • JSP 및 Java 구문은 <% ... %>Java 코드를 요소 생성과 구별하기 위한 추가 foreach기능과 개념이나 일류 함수 가없는 Java의 기본 구문 (최근까지) 으로 인해 복잡 합니다 . JSX에서 루프와 조건부에 기본 Javascript를 사용하는 구문 페널티는 제로가 아니지만 (제 생각에는) JSP만큼 나쁘지 않으며 루프와 조건부에 대해 JSX 특정 요소를 도입 할만큼 충분히 나쁘지는 않습니다.

내가 놓친 다른 것이 있습니까?


1
JSP 자체에 루프가있는 것이 나쁘지 않다고 생각합니다. 문제는 스크립틀릿 태그에 코드를 포함시키는 것입니다. 이것을 추방하고 JSTL을 사용하면 JSP를 단순화해야합니다. 또한 JSTL 구문이 스크립틀릿 구문보다 약간 덜 까다 롭다는 추가 이점이 있습니다. JSX에 익숙하지는 않지만 권장되지는 않지만 방지하지는 않는 복잡한 논리가 많은 JSX 조각을 남용 할 수 있습니다.
PhilDin

답변:


11

기본적으로 JSX를 만든 사람들은 JSP를 싫어하는 사람들과 동의하지 않았습니다. 그들의 토론을 여기에서보십시오 : 왜 우리는 React를 만들었습니까? 뿐만 아니라 데이터 표시

템플릿은 페이지의 논리와 프리젠 테이션을 구분하려는 아이디어를 기반으로합니다. 이 이론에서 귀하의 자바 스크립트 (또는 자바) 코드는 어떤 마크 업이 표시되는지와 관련이 없어야하며 마크 업은 관련된 로직과 관련이 없어야합니다. 이 부서는 본질적으로 사람들이 템플릿 (PHP / JSP / ASP)과 코드를 쉽게 혼합 할 수있는 다양한 템플릿 언어를 비판하는 이유입니다.

반응은 구성 요소를 기반으로합니다. 반응의 저자는 구성 요소의 논리와 표현이 밀접하게 연결되어 있으며이를 분리하려는 시도는 의미가 없다고 주장합니다. 대신 페이지는 논리적 조각으로 나눠 져야합니다. 따라서 헤더 표시 줄, 주석, 게시물, 관련 질문 등을 별도의 구성 요소로 나눌 수 있습니다. 그러나 관련 질문에 대한 논리를 프레젠테이션과 나누려고 시도하는 것은 합리적이지 않습니다.

JSX와 JSP와의 주요 차이점은 JSP는 로직을위한 약간의 Java를 포함하는 템플릿 언어라는 것입니다. JSX는 html 조각을 쉽게 구성 할 수 있도록 구문 확장이 포함 된 Javascript입니다. 강조가 다릅니다. JSX는 이러한 접근 방식을 수용하므로 JSP 또는 친구가 수행하는 더 깔끔하고 깔끔한 접근 방식을 만듭니다.

그러나 궁극적으로 반응 한 사람들이 템플릿을 좋아하지 않았다는 사실에 기인합니다. 그들은 그들이 나쁜 생각이라고 생각하며 마크 업과 프리젠 테이션 로직을 같은 곳에 두어야합니다.


render다른 구성 요소 논리와 같은 위치에 함수를 캡슐화하는 것에 대해 불평하지 않습니다 . 나는 요소 생성을 다른 종류의 코드와 혼합하는 가독성에 엄격히 관심이 있습니다.
wrschneider

@ wrschneider, 반응 형 render함수 는 일반적인 템플릿 언어와 혼합되는 코드 유형이 어떻게 다른가요?
Winston Ewert

3

React의 외부인으로서 JSX는 매우 붐비는 프레임 워크 악취 동물원에서 또 다른 "프레임 워크 냄새"라고 생각했습니다. 나는 이것이 사실이 아니라고 여전히 확신하지 못한다.

"유용한"의 실행 가능한 정의는 라이브러리 / 프레임 워크 / 패턴이 발생하는 것보다 더 많은 문제를 해결한다는 것입니다. 그것은 "풍선을 쥐어 짜는"속담입니다. 당신은 여기서 문제를 풀고, 저기 튀어 나옵니다. 나에게 JSX는 특별한 문제를 해결하지 못한다. 단지 "다른"일 뿐이다.

공식화 된 빌드 프로세스가 필요한 컴파일 가능한 의미 체계를 도입한다는 개념은 일부 상황에서 유용합니다. 예를 들어, .css 파일의 LESS 컴파일은 css 주위에 매우 필요한 구조를 제공합니다. "스파게티 솔루션"에 매우 취약합니다. 그러나 자바 스크립트 프리 컴파일러는 그리 많지 않습니다.


"유용한 실행 가능한 정의는 ..."입니다. 그리고 JSX는 우리가 생각하는 것보다 더 많은 문제를 해결합니다. JSX를 사용하면 리 액트 뷰 컴포넌트가 더 단순하고 표현력이 좋습니다. 얕은 렌더링으로 단위를 테스트 할 수 있습니다. 냄새가 나면 JSP에서 냄새가 나고 오류가 발생할 가능성이 더 큽니다. 그리고 나는 agnest jsp가 아닙니다.
Sagar

죄송하지만이 질문에 어떻게 대답하는지 모르겠습니다.
sleske

문학적 비평에 헌신 한 슬레 스케는 그것을 "내부 읽기"라고 부를 것이다. 표면에 대한 질문은 비교를 요구하지만 내부에 대해서는 프레임 워크에 대해 묻습니다. 제 대답은 "원인보다 더 많은 문제를 해결하는 프레임 워크"의 개념을 다루고 있습니다. OP는 내 의견을 듣고, 그 독특하고 독특한 상황에 그 신조를 적용하고, JSX가 도움이 될지 아니면 방해가 될지를 결정할 수 있습니다. 어느 쪽의 문제라도 정확한 결과를 초래할 수 있기 때문에 답에 결함이 있거나 이해력에 결함이 있는지에 대한 진술을 질문 할 수 있습니다.
dwoz

1

한마디로 :

  • 프론트 엔드 개발자는 스크립팅과 템플릿을 알아야합니다
  • JSX와 JSP는 템플릿 언어입니다.
  • JavaScript는 스크립팅 언어입니다
  • 자바는 스크립팅 언어가 아니다

참고 문헌


0

설명에 따라 JSX를 사용하지 않지만 JSX 조각의 작업은 데이터를 표시하는 것입니다. 즉, MVC 용어의 뷰 구성 요소입니다. JSX 프래그먼트는 아마도 어디에서 데이터가 어디서 왔는지 알지 못하거나 신경 쓰지 않습니다.

잘 구성된 JSP 페이지에는 언급 한 것처럼 JSTL 지시문 만 포함됩니다. JSTL 지시문은 JSP를 단순화하여 스코프에서 가져 오기, null 등을 검사하여 혼란을 일으키지 않습니다. 이것이 얼마나 많은 혼란을 제거하고 그것을 어수선하게 유지하는 것이 좋습니다.

JSX 조각처럼; JSP의 유일한 임무는 데이터의 출처를 걱정하지 않고받은 데이터를 표시하는 방법을 알아내는 것입니다.

요약하면, 뷰가 JSX인지 JSP인지에 관계없이 올바르게 수행하면 뷰에 데이터가 표시됩니다.

서버에서 프레젠테이션을 수행하는 대신 프레젠테이션을 클라이언트로 옮길 수있는 이유는 더 유연합니다. 웹 사이트는 웹 서비스 (예 : ReST)를 통해 데이터를 가져올 수 있으며 다른 클라이언트 일 수도 있습니다. 나중에 기본 Android 또는 iOS 앱을 원하는 경우 웹 사이트와 동일한 웹 서비스 세트를 사용할 수 있습니다.


JSX는 클라이언트 측 또는 서버 측에서 사용될 수 있습니다. JSX를 사용하는 멋진 방법은 서버에서 초기 컨트롤을 렌더링 한 다음 클라이언트 측에서 서비스 요청에 대한 응답으로 DOM 업데이트를 수행하는 것입니다. 어쨌든 React가 뷰 레이어라는 것이 맞습니다 ( Facebook : "많은 사람들이 React를 MVC에서 V로 사용합니다").
브라이언

구체적인 질문은 React / JSX가 루프 / 조건에 기본 Javascript 구문을 사용하는 것이 좋으며 JSP가 기본 Java 구문 (스크립트 릿)을 제거하는 것이 좋은 이유입니다.
wrschneider 2014

미안, 그 시점을 놓쳤다. 나는 답을 작성하기 시작했지만 그것이 "당신의 추측이 나의 것만큼이나 좋다"는 단순한 사례라는 것을 깨달았습니다. JSX를위한 멋진 프리젠 테이션 레이어 구문이 유용 할 수 있습니다. JSX 디자이너가 아닌 Java 디자이너에게 이것이 중요하다고 추측 할 수 있습니다.
PhilDin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.