it-source

AngularJs 앱을 작성할 때 Jade 또는 핸들 바를 사용하는 이유는 무엇입니까?

criticalcode 2023. 4. 1. 09:34
반응형

AngularJs 앱을 작성할 때 Jade 또는 핸들 바를 사용하는 이유는 무엇입니까?

저는 javascript full stack applications는 처음이고 Angular는 전혀 처음이라서 누군가 여기서 기록을 바로 잡아주셨으면 합니다.

Angular를 사용하여 클라이언트 측 앱을 작성할 때 Jade 또는 Handlebars와 같은 템플릿 프레임워크를 사용해야 하는 이유는 무엇입니까?JS.

나는 이 템플릿 프레임워크들 중 어느 것도 사용한 적이 없다고 말해야 한다.그래서 나는 이점에 대해 완전히 알지 못한다.예를 들어 핸들 바를 보면 루프 등 앵귤러에서와 같은 작업을 많이 합니다.

제가 알기로는 적절한 HTML을 사용하여 Angular에서 템플릿을 만든 후 모든 템플릿 클라이언트 측을 수행하고 이를 노드나 mongo를 사용하여 API 우선 접근과 결합하는 것이 가장 합리적입니다.

이러한 혼란의 이유는 GitHub에서 볼 수 있는 많은 예들이 Jade를 사용하고 있기 때문에 직감적으로 반대되는 것 같습니다.

제발 저를 깨우쳐주시고, 저를 바로 세워주세요.저보다 훨씬 더 많은 것을 알고 있는 사람들에게서 몇 가지 모범 사례를 배우고 싶습니다.

감사해요.

난 제이드로 앵글이 소비하는 템플릿을 생성한다.JS는 일반 HTML을 쓰는 것을 싫어하기 때문에 다음과 같이 보입니다.

.control-group(
  ng-form
  name='emailGroup'
  ng-class='{"ng-error": emailGroup.$invalid}'
)
  label.control-label Email
  .controls
    input(
      type='email'
      ng-model='user.email'
      required
      placeholder='you@example.com'
      focus-on='focusEmail'
    )

…일반 HTML보다 훨씬 깨끗하다고 생각합니다.

OP가 코멘트한 바와 같이 Angular 환경에서 Jade를 선호하는 사람들은 뷰 로직이 클라이언트에 있고 비즈니스 로직이 서버에 있다는 것을 이해하지 못합니다.

그럴 만한 충분한 이유가 없는 한 그것을 하지 마라.엔지니어링에서는 가동 부품이 적은 시스템이 보다 신뢰성 높은 시스템이며, 인터페이스 경계(클라이언트/서버)가 존중되는 시스템은 장기간에 걸쳐 유지보수가 용이하기 때문에 가능하면 가장 단순한 아키텍처와 깨끗한 분담을 기본으로 합니다.가장 중요한 이유가 있다면, 반드시 해야 할 일을 하라. 하지만 경고의 공허한 사람은.

최근에 저는 단순함을 유지하는 것만으로 Jade에 혼합하는 것보다 Straight Angular templating이 훨씬 더 잘 될 수 있는 코드를 검토했습니다.

템플릿 확장 외에, 제이드사는 Angular가 아직 제공하지 않은 테이블에 가치 있는 것을 제공하지 않습니다.솔직히 말해 봅시다."상속보다 선호하는 구성"(즉, 부분)이라는 건전한 원칙을 사용하면 템플릿 확장성이 필요하지 않습니다.Jade는 HTML보다 "해석하기 쉽다"는 것이 거의 없다.그들은 단지 세 가지 차이일 뿐이고, 제이드는 다른 차원의 간접적인 표현을 추가하는데 - 피하는 것이 가장 좋다.

서버측 템플릿 작성에는 다음 1가지 유효한 전문 사례가 있습니다.최적화, 섣부른 최적화는 일반적으로 나쁜 것임을 기억하십시오.퍼포먼스가 정말로 문제가 되어, 이것에 대응할 수 있는 서버 용량이 있는 경우, 서버측의 템플릿 제작이 도움이 됩니다.이는 Twitter나 Basecamp와 같은 제품에 적용됩니다.이 제품에서는 서버에 대한 요구가 줄어들기 때문에 많은 서버 사이드 작업을 하는 비용이 상쇄됩니다.

핸들바에 대해서는 Angular를 교체할 필요가 없습니다.JS의 (놀라운) 클라이언트 측 템플릿.

솔직히 왜 사람들이 이 차이를 신경 쓰는지 이해할 수 없다.

<html ng-app>
 <!-- Body tag augmented with ngController directive  -->
 <body ng-controller="MyController">
   <input ng-model="foo" value="bar">
   <!-- Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup -->
   <button ng-click="changeFoo()">{{buttonText}}</button>
   <script src="angular.js">
 </body>
</html>

또, 이하와 같이 됩니다.

html(ng-app="ng-app")
  // Body tag augmented with ngController directive  
  body(ng-controller="MyController")
    input(ng-model="foo", value="bar")
    // Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup
    button(ng-click="changeFoo()") {{buttonText}}
    script(src="angular.js")

사람이 읽을 수 있는 게 하나 더 있다는 것만 빼면요살짝.왜 사람들이 그 주제에 그렇게 열광하는지 모르겠어요.자전거 타느라 정신이 없어요.그 차이는 무시해도 좋을 정도로, 유능한 프로그래머라면 누구나 구글에서 5초 후에 다른 프로그래머로 쉽게 번역할 수 있다.네가 원하는 것을 쓰고 다른 사람들은 아무 것도 아닌 일로 싸우게 하라.전쟁을 선택하고 원자로와 같이 실제로 중요한 것들에 대한 토론에 참여하세요.

  1. 모서리가 있는 핸들 바를 사용할 필요가 없습니다.JS는 자체 템플릿엔진을 가지고 있기 때문에
  2. Jade를 사용하는 이유는 서버 렌더러에 불과하기 때문에 html로 컴파일되고 각이 있는 서비스를 제공하기 때문입니다.JS는 나중에 프런트엔드로.

따라서 TL;DR은 서버에서 임의의 언어(jade, haml,...)를 사용하여 응용 프로그램의 html 구조만 생성할 수 있으며 각도와는 무관합니다.JS는 프런트엔드의 런타임에 HTML을 렌더링하여 사용할 수 있기 때문입니다.

서버에서 Jade를 사용할 필요는 없으며, 신규 개발자에게 혼란을 주기 때문에 사용하지 않는 것이 좋습니다.Jade가 더 깨끗하고 익숙하기 때문에 Jade를 사용하고 있으며, angularJS와 함께 사용할 경우 논리 없이 플레인 html을 생성하는 것이 유일한 작업입니다.

인정된 답변은 다소 일방적이며 HTML용 프리 컴파일러의 어떠한 설정도 어떠한 종류의 HTML 프로젝트에서도 매우 유용하다는 사실을 간과하고 있습니다.구성 및 그에 따른 마크업 유연성

각진 앱으로 혼자 작업하는 거?제이드 한번 해봐.

Jade는 HTML 모듈화 기능을 향상시키고 HTML 디버깅에 소요되는 시간을 단축하며 마크업 인벤토리 구축을 장려합니다.

디자인 시간 동안 HTML 부품에 엄청난 양의 반복이 있을 수 있습니다.HTML 출력이 일련의 옥 파일을 기반으로 하는 경우, 팀은 변화하는 요구사항에 유연하게 대처할 수 있습니다.또, 옥 인크루드(jade include)의 재구성에 의한 마크업 변경은, 순수 HTML의 개서보다 훨씬 견고합니다.

그렇다고는 해도, 생산이나 개발 단계에서 옥과 각을 이루는 것에 대한 일반적인 거부감을 인식하고 있습니다.대부분의 팀에서는 다른 필수 구문 지식을 도입하는 것은 좋지 않습니다.또한 Jade를 사용하면 DRY 원칙에 의해 금지되어 있는 작업(마크업 준비를 게을리 하는 등)을 추상화함으로써 비효율적인 프로젝트 관리를 숨길 수 있습니다.

나는 위의 모든 답을 읽었고 아무도 Angular를 생성하는 것보다 옥을 사용하는 한 가지 측면에 대해 언급하지 않은 것에 약간 놀랐다.JS 템플릿은 매우 유용합니다.

이미 말한 바와 같이 실제 제작에서는 raw html과 jade를 입력하는 현실적인 시나리오의 차이가 눈에 띄지만, 더 중요한 것은 angularjs 템플릿을 동적으로 변경재초기화할 필요가 있다는 것입니다.

간단히 말하면, html을 inner를 통해 변경해야 할 때가 있습니다.HTML을 누른 다음 Angular 강제 적용JS: 콘텐츠를 다시 컴파일합니다.그리고 이것이 바로 옥을 통해 그러한 관점을 만들어 내는 것이 이점을 가져다 줄 수 있는 작업입니다.

또한, 각도JS는 정의상 잘 알려진 모델에서 잘 작동합니다.실제로 정확한 구조를 알 수 없는 경우가 있습니다(예를 들어 JSON 렌더러).각진JS는 (각진 앱을 만들고 있다고 해도) 여기서는 꽤 서투릅니다만, JS는 제이드로 할 수 있습니다.

Jade를 통해 각 템플릿을 포함할 수 있습니다.

script(type="text/ng-template", id="admin")
  include partials/admin

캐싱 템플릿의 경우 이스케이프 템플릿을 javascript 파일에 포함시키는 것보다 훨씬 취약하지 않다고 생각합니다.

참조: https://docs.angularjs.org/api/ng/service/$templateCache

Jade는 Haml보다 html에 훨씬 더 가깝다.콘텍스트스위치는 실제로 매우 작습니다.그러나 그것은 완전히 부재한 것은 아니다.개발자에게는 전혀 문제가 되지 않을 수 있습니다.그러나 디자이너가 와서 중첩된 태그가 올바르게 작동하도록 하는 방법을 묻는다면, 당신은 애초에 만든 불필요한 문제를 해결하고 있는 것입니다.

HTML은 여전히 매우 읽기 쉽게 쓰여질 수 있고 부분적인 부분을 사용하여 더 이해하기 쉽게 만들 수 있습니다.Jade든 HTML이든 500줄은 읽기 어렵다.

여기 제이드 템플릿이 있습니다.

.product-container

    .input-group.msB.col-md-5.no-padding
        .fnt-light-navyblue.mtB(for='name')
            strong Name the sticker
        input.full-input(type='text', placeholder='Awesome Batman Sticker')
    .clear

    .form-group.mmT
        label.form-label.fnt-light-navyblue
            strong Choose size
        .selector-group(ng-repeat="size in sizes", ng-class="{ 'msT': !$first}")
            - raw
            span.radio
                input.radio(name='choose_sticker_size',
                            ng-model="selectedSize",
                            type='radio',
                            value='{{size}}',
                            id="sticker-{{size}}")
                span.fake-radio
            label(for='sticker-{{size}}') {{size}} inch
            - endraw
    // end form-group
    .clear

그리고 동등한 HTML은

<div class="product-container">

    <div class="input-group msB col-md-5 no-padding">
        <div for="name" class="fnt-light-navyblue mtB">
            <strong>Name the product</strong>
        </div>
        <input type="text" placeholder="Awesome Batman Sticker" class="full-input" />
    </div>
    <div class="clear"></div>

    <div class="form-group mmT">
        <label class="form-label fnt-light-navyblue">
            <strong>Choose size</strong>
        </label>
        <div
            class="selector-group"
            ng-class="{ 'msT': !$first}"
            ng-repeat="size in sizes">
                {% raw %}
                <span class="radio">
                    <input
                        id="sticker-{{size}}"
                        class="radio"
                        name="choose_sticker_size"
                        ng-model="selectedSize"
                        type="radio"
                        value="{{ size }}" />
                    <span class="fake-radio"></span>
                </span>
                <label for="sticker-{{size}}">{{size}}</label>
                {% endraw %}
        </div>
    </div><!-- end form-group -->
    <div class="clear"></div>
</div>

알기 쉽게 쓰면 HTML이 특별히 불리하다고 생각하지 않기 때문에 스위치가 보증됩니다.아니나 다를까, 각 괄호는 눈에 거슬린다.하지만 제가 소개한 간접방법이 HTML을 깨는 것이 아닌가 하는 디자이너의 의구심에 대처하기보다는 차라리 갖고 싶습니다.(그렇지 않을 수도 있습니다.하지만 그것이 가치 있는 노력이 아니라는 것을 증명한다.)

우선, 항상 서버측 템플릿이 필요합니다.

순수 클라이언트측 템플리트는 로딩 시간에 큰 단점이 있기 때문에 서버에 정적 요소를 렌더링함으로써 종종 완화됩니다.이렇게 하면 사용자가 페이지를 부분적으로 로드할 때 페이지의 일부 요소를 이미 볼 수 있습니다.

이 경우 템플릿은 편리합니다.다만, 지킬과 같은 정적 HTML 생성기를 사용하는 경우도 있습니다.


여기서 언급되지 않은 제이드 제품을 사용하는 또 다른 이유가 있습니다.

공백.

들여쓰기 및 줄 바꿈을 사용하여 사람이 유지관리할 수 있는 HTML을 작성할 경우 줄 바꿈마다 공백 텍스트 노드가 생성됩니다.경우에 따라서는 인라인 요소의 포맷을 거의 스크류하여 javascript 코드를 더 이상하게 만들 수 있습니다.

상세한 것에 대하여는, https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM 를 참조해 주세요.

Jade 코드를 쓰는 경우 이 문제가 없는 한 줄 HTML로 컴파일됩니다.

팀에서 작업할 때 프론트 엔드는 페이지를 정적 html로 설계하는 것을 선호할 수 있습니다.이 정적 html을 동적 템플릿으로 변환하면 오류가 발생하며, jade를 추가하면 이러한 변환 단계가 추가됩니다.

다른 많은 사람들과 마찬가지로, 나는 단순함을 선호한다!

언급URL : https://stackoverflow.com/questions/18174856/whats-the-use-of-jade-or-handlebars-when-writing-angularjs-apps

반응형