Rails: Rails Prototype против ненавязчивого Javascript с использованием jQuery - PullRequest
Новая
       22

Rails: Rails Prototype против ненавязчивого Javascript с использованием jQuery

3 голосов
/ 25 апреля 2010

Я работал над двумя проектами, используя Ajax и Ruby. В одном проекте я использовал помощников Rails Prototype и RJS. В другом проекте я использовал HAML и ненавязчивый Javascript с jQuery. У каждого была кривая обучения, которую я преодолел. Тем не менее, долгосрочные затраты и выгоды любого из подходов не ясны. Для моего следующего проекта я пытаюсь выбрать между:

  1. Rails + HAML + jRails + jQuery
  2. Rails + HAML + ненавязчивый jQuery

Тенденция в Rails, особенно в Rails 3.0, похоже, заключается в использовании ненавязчивого Javascript, но мне не ясно, почему это лучше, особенно когда вы получаете так много полезных помощников (таких как remote_form_for) из Rails / jRails. В попытке принять это решение у меня возникли следующие вопросы:

  1. Какой подход приводит к уменьшению количества кода для достижения того же объема функциональности?
  2. Какой подход менее подвержен ошибкам?
  3. Какой подход легче протестировать?
  4. Какой подход легче читать, поддерживать и развивать?
  5. Какой подход позволяет вам легче изящно деградировать ваше веб-приложение (предоставляя ту же функциональность без Ajax), когда Javascript отключен в клиентском браузере?

Я ценю любую помощь или понимание, которое вы можете предоставить.

1 Ответ

2 голосов
/ 13 сентября 2010

У меня есть несколько ответов на ваши вопросы - по крайней мере, с моей точки зрения. Ответы на подобные вопросы действительно зависят от вашего опыта и предпочтений.

1) Я бы сказал, что ненавязчивый JavaScript приведет к уменьшению общего кода, особенно если вы повторно используете методы JavaScript.

2 & 3) Я собираюсь пойти с ненавязчивым JavaScript для обоих из них. Когда JavaScript отделен от структуры страницы, у вас есть лучшее представление о том, что делает этот конкретный фрагмент кода, и вы можете его протестировать, а также знаете, что у вас есть тесты для этих методов. Смешанный код обычно (по моему опыту) намного сложнее получить хорошее тестовое покрытие. Это поможет сохранить код менее подверженным ошибкам.

Одна из проблем с развязанными js - если вы удалите функцию, вы можете оставить код позади или удалить зависимый код. Конечно, именно поэтому у вас должны быть автоматизированные тесты и хорошее покрытие.

4) Я думаю, что встроенный js легче понять, потому что все в порядке, но что-то над одной строкой, и вы уже снижаете читабельность, так что вы могли бы просто пройти ненавязчиво до конца для других преимуществ. Ненавязчивый js также упрощает поддержку и документирование для других членов команды.

5) По моему опыту это стирка. Вы должны предоставить дополнительные методы в любом случае.

В качестве заключительного замечания я согласен с тем, что Rails 3 также обеспечивает гораздо лучшую поддержку ненавязчивых js, и я считаю, что это лучшая практика. Я только начал исправлять старое приложение для клиента, и со смешанными представлениями html, js, logic у меня было действительно трудно понять, чего они пытаются достичь. Если бы вещи были отделены друг от друга, было бы намного легче принять.

Надеюсь, это поможет.

...