Опыт использования Angular&Rails в качестве цельного приложения

Картинка по запросу “Angular+Rails”

Небольшой рассказ о том, с какими трудностями пришлось столкнуться, приняв решение использовать Angular на полпути к сдаче проекта.


С чего все начиналось

Это был обычный проект — интернет-магазин с элементами социальной сети. Разработка началась еще до написания конкретного ТЗ заказчиком (суровые российские заказчики). А когда оно появилось, было уже поздно…

Обилие сложных форм сразу поставило на нет использование стандартных средств, предоставляемых таким мощным инструментом, как Ruby on Rails. 
Нет, конечно, достичь результат можно было и классическим путём, и я даже попробовал! Но это превратилось в огромный Form Object и не менее огромный кусок jQuery кода, который придавал динамичность. Всё работало, но опыт показал, что людям, пришедшим в проект, сложно поддерживать подобный подход.

Было принято решение остальной функционал реализовывать, опираясь на Angular-подход.

Во что это вылилось

Так как уже имелся Rails-роутинг, мы не стали делать гейт для angular клиента. Мы продолжили делать весь роутинг с помощью Rails.
Этот подход сразу поставил нас (меня) в некоторые рамки:

Resolve промисов? Ха. Ха. Нет, теперь мы не уверены в том, что данные, с которыми мы работаем в контроллере, действительно “Данные”. Это порождает чуть более лишнего кода, чтобы разрешить все promises.

В каждом контроллере приходится делать ng-init с передачей в функцию нужных параметров: самое частое — текущего пользователя. Иначе никак.

Смешивание rails-хелперов во view и angular директив! Я всеми силами пытался просить людей писать в angular-way, чтобы все было “в одном стиле”, но увы, много чего представлено именно в виде “Вот тут у нас кусок rails финтифлюшек, а вот тут снизу ng-show-ом работаем”.
Я читал блоги людей, которые делали так. Скорее всего, они не такие перфекционисты, как я :) Эх, молодость.

Роутинг превратился в огроменный api/v1 гейт со скромным клубочком базовых ресурсов на редактирование пользователей и добавление товаров. Это можно переписать, но нужно время, которого нет.

И еще кое-что: пришлось включать url объектов в api, т.к. хардкодить url-ки типа ng-href=”/objects/{{objectId}}” ну совсем не гибко, и вообще по рукам за это нужно бить. (Ах, где же наш ui-sref).

Однако

Все же архитектура приложения предельно понятна — и никакой жесткой каши не случилось. Если следовать заложенным принципам, то поддержка и доработка функционала не вызывают особых трудностей.

Тестирование

Ну, race conditions, без них никак.. Впрочем, есть маленький и неизвестный гем capybara-ng, который упрощает написание интеграционных тестов на angular-странички.
А с тестированием api все предельно ясно. Подаем что-то на вход, ожидаем что-то на выходе.

Вывод

Умные люди уже все написали в книгах, но велосипедить и придумывать что-то новое в образовательных целях нужно обязательно (хотя бы чтобы учиться на своих ошибках)! 
Однако чужой опыт еще никто не отменял.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.