저는 RoR 개발자이고 백본 또는 각도와 같은 다른 js 라이브러리를 사용하여 단일 페이지 솔루션을 연구했습니다.RoR을 사용하여 단일 페이지 응용 프로그램 만들기
오늘 내 RoR 응용 프로그램의 경우 내 컨트롤러에서 내보기 폴더에 저장되는 js 파일을 DOM에 jQuery를 사용하여 내가 지정한 div에서 원하는 부분을로드하도록 렌더링합니다. 이 간단한 접근 방식으로 단일 페이지 응용 프로그램을 만들 수 있습니다.
방금 언급 한 접근 방식의 단점은 무엇입니까? 누군가가이 접근법에 대한 철저한 백본의 장점을 설명 할 수 있습니까? 혹은 그 반대로도? 아니면 단순히 환경 설정입니까?
귀하의 간단한 접근 방식은 본질적으로 각도 또는 백본이 수행하는 것과 정확히 동일합니다. 그렇기 때문에 이러한 방식으로 단일 페이지 응용 프로그램을 구축 할 수 있습니다. 그러나 귀하의 간단한 예제는 내 의견으로는 단일 페이지 응용 프로그램으로 간주되지 않습니다. 나는 그것을 단순히 하나의 페이지라고 생각할 것이다. 단일 페이지 응용 프로그램에 경로가 있습니다 (여러 개의 "페이지"가 서로 다른 URL로 표시됨). 이를 수행하기 위해, 부분을 변경할 때 javascript의 window.location을 사용하여 URL을 조작합니다. 사용자가 중첩 된 라우트와 사용자가 브라우저에서 서브 페이지 (예 :/contact)로 직접 이동하는 경우를 처리해야합니다.
처리해야 할 까다로운 엣지 케이스가 많으며, 이것을 직접 구현하는 데 꽤 많은 시간이 걸릴 것입니다. 그렇기 때문에 이것을 위해 정확히 설계된 프레임 워크를 사용하지 않으시겠습니까? Rails는 멋진 웹 개발 프레임 워크이지만 단일 페이지 앱용으로 설계되지 않았습니다. Rails는 html 페이지를 서버 측에 렌더링하도록 설계되었으며 코드의 상당 부분이이를 수행합니다. 레일에 단일 페이지 앱을 만드는 것은 많은 체중을 운반하는 것을 의미합니다. 단일 페이지 응용 프로그램에 필요한 서버 측에 JSON API와 정적 파일 서버 (예 : NGINX) 만 있으면됩니다.
서버 측에서 동적 HTML을 렌더링하는 작업을 브라우저로 옮기는 것은 훨씬 더 많은 JavaScript 코드를 의미합니다. 일반 jQuery를 사용하여 혼란을 일으키는 것은 정말 쉽습니다. jQuery는 프레임 워크가 아니라 라이브러리입니다. jQuery는 구조를 제공하지 않으며, 재사용 패턴을 코딩하여 물건을 정리하지 못하게합니다. Angular와 Backbone은 Rails와 같은 MVC 프레임 워크이지만 브라우저는 아닙니다. 이들은 잘 구조화되고 테스트가 가능하며 유지 보수가 용이 한 애플리케이션에 핵심적인 코드 조직을 제공합니다. 순전히 jQuery 응용 프로그램에서는 종종 DOM 조작 (보기)과 직접 섞인 데이터 모델을 처리하는 코드를 볼 수 있습니다. MVC 프레임 워크에서 이것은 죄가있는 것으로 간주됩니다.
단일 페이지 응용 프로그램을 작성하는 데있어 프론트 엔드 프레임 워크를 사용해야하는지 여부는 전통적인 응용 프로그램을 빌드 할 때 백엔드 프레임 워크를 사용해야하는 것과 같은 질문입니다. Rails를 사용 하시겠습니까? 물론 일반 jQuery를 사용할 수있는 것처럼 일반 Ruby를 사용할 수도 있지만 왜 그렇습니까? 바퀴를 재발 명할 필요가 없습니다.
Tubolinks와 더 나은 사촌 WiseLinks와 같은 단일 페이지 앱의 환상을 얻을 수 있지만 서버가 렌더링 할 수 있도록 많은 경로 또는 경로 매개 변수가 필요하기 때문에 클라이언트와 서버 모두에서 진짜 난장판이 될 수 있습니다 클라이언트가있는 특정 상태에 맞는 부분입니다. 클라이언트 DOM을 올바르게 업데이트하고 전환을 수행하기 위해 html과 javascript를 보내면 지저분 해집니다. 나는 그것을 완전히 피하는 것을 강력히 권한다.
일반적으로 서버를 API로 유지하고 클라이언트 프레임 워크를 사용하는 것이 좋습니다. 서버가 훨씬 더 간단 해지고 언제나 좋은 일이 될뿐만 아니라 필요한 경우 네이티브 모바일 앱도 지원할 수 있습니다.
초기 학습 곡선에도 불구하고 Ember와 함께 많은 성공을 거두었지만 라우트/URL 상태 관리, 객체 속성 바인딩 및 관찰, 계산 된 속성 및 핸들 막대 템플릿 및 구성 요소를 포함하는 매우 우수한 추상화가 있습니다. 나는 또한 Oauth2 인증을 가지고 몇 분 안에 일했다. API 인증은 네일이 필요한 것입니다.
저는 Ember로 시작하지는 않았지만, Backbone/Marionette에 매우 야심 찬 앱을 작성했으며 재사용 가능한 구성 요소를 구현하고 애플리케이션 상태를 관리하려고 애 쓰고있는 앱을 구성하는 데 많은 어려움을 겪었습니다. API 인증은 단순하지도 않고 복잡한 사용자 정의 코드가 많이 필요했습니다. 나는 Ember가 필요로했던 추상화를 정확히 깨달았고 Ember는 적절하게 그것을 제쳤다. Backbone/Marionette은 내가 필요로하는 것 근처에 없었으며 특정 유형의 앱에는 유용하지 않지만 개인적으로는 뒤돌아 보지 않았다. Ember plus를 사용하여 빠른 성과 (즉, 막대한 생산성 증가)를 얻을 수 있었기 때문에 더 강력한 프레임 워크를 사용하여 변경했습니다. Ember가 작성해야하는 코드가 훨씬 적기 때문에 전체 코드 크기가 훨씬 작습니다. 누군가 프레임 워크 ABC가 XYZ보다 크다고 생각할 때 음식을 먹습니다. 앱 코드가 3 배 크고 작성하기가 어려우며 사용자 코드가 적을 때 누가 신경 쓰는지 작은 프레임 워크는 앱이 작거나 크기가 크고 자체 프레임 워크를 구현하거나 자갈 할 시간이 있고 더 많은 기능을 갖춘 프레임 워크에서 작업하는 것보다 더 나은 작업을 수행 할 수 있다고 생각하면 좋습니다. 당신보다 경험이 :) 단지 작업에 적합한 도구를 사용하고 프레임 워크가 페이지의 이미지보다 작을 수 있으므로 프레임 크기와 관련하여 관점에 넣어 두십시오.
모든 웹 프레임 워크는 많은 변화를 겪고 있으므로 사용자가 선택한 것과 상관없이 모든 것을 유지해야합니다. Ember의 문서는 매우 훌륭합니다. 비록 이것이 항상 그런 것은 아니지만. 저는 Ember의 야심적이고 역사적으로 논란의 여지가있는 부분 인 Ember Data를 피하고 저 대신 Ember Model을 저 위험 옵션으로 사용했습니다. 물론 ymmmv.
Angular와 같은 다른 프레임 워크에 익숙하다면 효과가 있으면 붙어 있어야합니다. 엠버 (Ember) 나 앵귤러 (Angular)를 선택하는 것은 너무 많습니다. 불공평합니다. 선택한 프레임 워크가 훌륭하게 작동한다면 좋겠지 만, 그렇지 않다면 좋은 프레임 워크가 있습니다. 내 자신의 경험, 다른 사람이 그렇게 말하기 때문이 아닙니다.
완전히 편파적이려면 TodoMVC을 비교하고 대조하는 것이 좋습니다. 확실하지 않을지라도 솔직히 말해서 분노에서 사용하기 시작할 때까지 어떤 것이 정말로 중요한지 알지 못할 것입니다. 짧은 목록 2 또는 3 프레임 워크를 제안한 다음 프레임 워크 템플릿 언어로 가장 중요한 뷰를 조롱하고 조명기 데이터를 사용하는 모델을 정의하고 어떤 것이 가장 효과적인지 확인하십시오.
jQuery가 지저분 해지는 부분은 완전한 의미를 갖습니다. 그러나 여러 개의 URL이없는 레일스에 대한 부분을 명확히 할 수 있습니까? 내 레일 앱에서 컨트롤러에 메서드가 있고 그 메서드에 대한 링크를 <% = link_to 'new_method', new_method_path, : remote => true %>'로 연결하면 해당 컨트롤러가 내 Views 폴더에'new_method.js.erb'에 링크하는'format.js'가 있습니다. URL은 http://www.app.com/controller/new_method입니다. 네가 진술 한 것을 성취 했어, 안 그래? 방금 설명한 워크 플로보다 백본에서이 비트가 어떻게 유리한 지 명확히 설명해 주시겠습니까? – jamesdlivesinatree
새로운 레일스 메소드에 링크하면 새 페이지를 요청하게됩니다. 서버의 rails 메소드는 요청을 받고 완전히 새로운 페이지로 응답합니다. 그것은 동일한 머리말과 꼬리말을 가질 수도 있지만, 레일스는 실제로 다시 전체 HTML 페이지를 다시 보내고 있습니다. 이것은 단일 페이지 응용 프로그램이 아닙니다. 단일 페이지 응용 프로그램에 인덱스를 한 번만 제공하면 링크를 클릭하고 서버와 다시 이야기하지 않고도 여러 개의 URL로 이동할 수 있습니다. 또는 서버와 대화를한다면 아약스 만 사용해야합니다. link_to를 사용하는 것은 아약스가 아니며 전체 페이지 응답을받습니다. –
또한 단일 페이지 응용 프로그램에서 모든 (비 아약스) 요청을 루트 URL로 리디렉션해야합니다. 즉, ajax가 아닌 모든 요청은 인덱스 페이지를 제공한다는 의미입니다. 이것은 레일없이 쉽게 할 수 있고 nginx 나 apache가 index.html (non-ajax가 아닌) 요청을 제공하는 것입니다. 루트 (/)가 아닌 다른 경로에서 index.html 이외의 페이지를 제공하는 경우 단일 페이지 응용 프로그램이 없습니다 –