Cложно ли будет перевести большой проект с angular 1.4 на angular 2?

Question

[danikkk]

Нужно написать UI к crm. И стоит вопрос какой фреймворк выбрать - писать сейчас на angular 1.4 и затем проапгрейдить до 2.0, или поискать другие альтернативы, например reactjs.

Answer 1

[Сергей Протько]

Angular 1.3 meets Angular 2 - описание того как упростить переход с angular 1.x на angular2, а точнее каким правилам стоит придерживаться для этого.

p.s. тыкал angular2, пишу на angular1.4, разница конечно существенна но не настолько критична что б уж совсем паниковать.

Answer 2

[Алексей Уколов]

Учитывая, что вторая версия еще даже из альфы не вышла, вы для ответа на свой вопрос можете монетку использовать.

Comments

[danikkk]

А из фреймворков для single page application, который сейчас дышит в спину angular? Как я знаю reactjs это не альтернатива ангуляр, они о разном?

[Алексей Уколов]

Я использую исключительно backbone, так что на ваши вопросы не отвечу, но, может быть, кто-нибудь другой подтянется. Ну и по сайту поищите, наверняка этот вопрос кто-то уже задавал.

[danikkk]

Алексей Уколов: спасибо!

[Сергей Протько]

danikkk: reactjs + flux о том же, но чуть по другому. И как по мне angularjs удобнее + решений готовых и качественных побольше будет.

Answer 3

[Арам Арамян]

Да, это будет сложно. Даже почти невозможно.

Comments

[Сергей Протько]

не вводите людей в заблуждение. Если соблюдать angular styleguide, придерживаться подхода с компонентной организацией проекта - то без проблем.

[Арам Арамян]

Сергей Протько: время нас рассудит

[Сергей Протько]

Арам Арамян: ну как бы у меня 2-х летний опыт с 1.x и чуть чуть с 2.0 40-ые альфы, и могу сказать, что если у нас логика приложения написана нормально и структура приложения адекватна - все не так уж плохо. Но конечно можно легко сделать непереносимую апу.

[Сергей Протько]

Арам Арамян: точнее не так, если у нас бизнес логика отделена от фреймворка, и UI поделен на компоненты, нет прямой работы с DOM - то проблема не настолько серьезная как вам возможно кажется.

[Арам Арамян]

Сергей Протько: Вот именно, у вас 2-летний опыт и конкретно у вас, возможно, особых проблем не возникнет.

[lega]

> если у нас бизнес логика отделена от фреймворка

Кстати этим и плох Ангуляр что заставляет использовать свои враперы сервисов, фабрик и прочего, когда это делается проще и компактней на чистом JS, а главное можно было бы лекго менять, подключать другие фрейморвки.

[Сергей Протько]

lega: ангуляр тут не причем и никакие "обертки" он не навязывает. "сервис" обертка это не обертка, это вызов конструктора, когда все зависимости передаются явно внутрь. Но поскольку JS чуть более чем убог, и только с ES2015 можно делать удобно объекты (либо со штуками типа klass.js), то люди юзали как могли что могли. Ну и да, если вам надо возвращать не объект а функцию - то фабрика - норма вариант. Если вам надо иметь возможность конфигурить фабрику - то провайдер. Но в 99% случаев хваает сервиса.

Так что все хорошо у ангуляра, но да, легко можно выстрелить себе в ногу.

[lega]

Сергей Протько: сервис, фабрика, ... - это всего лишь паттерны, и что-бы их использовать ангуляр не нужен, вот пример на js и аналога под ангуляр: https://gist.github.com/lega911/bce33922049929aa6300

Вариант на js проще, короче, используется аналогично DI, так же можно использовать в тестировании, нет проблем с минификаторами, можно менять фреймворки, можно загружать асинхронно (например через require).
И зачем нам тут ангуляр?

[lega]

под ангуляр пример не тот, но суть думаю понятна.

[Сергей Протько]

lega: я прекрасно знаю что такое фабрика и что такое Dependency injection container (я как бы еще на php пишу и у нас это тип в любом уважающем себе фреймворке есть).

То что вы называете не нужной оберткой я называю регистрацией сервисов в контейнере. И там все с этим хорошо.

[lega]

> я прекрасно знаю что такое фабрика
Я не сомневаюсь.

> я называю регистрацией сервисов
Регистрация сервиса есть и в js примере.

Вопрос в том, чем хороша реализация Ангуляра, какие плюсы? Я вижу только 2 сомнительных плюса:
1) Некая стандартизация - всем приходится именно так делать (регистрировать) сервисы.
2) Возможность обработать/перехватить момент регистрации, т.к. он идет через вызов ф-ии (это легко делается и в js версии)

Ну а ряд минусов я уже озвучил выше.

Я считаю что в Ангуляре 1.х некоторые вещи плохо спроектированы, а некоторые сделаны не потому что оно нужно, а просто прилепили что-бы хоть что-то прилепить. А разработчикам приходится с этим жить. Вот один из примеров тупых решений, который уже давно исправили, хотя 30% считают, что так и должно было быть... 8\ (фанаты?)

Хотя, глядя на Ангуляр 2, его авторы отказываются от некоторых "подходов" 1-й версии, т.е. признали их неудачными - и это подтверждает мои доводы.

[lega]

Хотя некоторые ошибки* они повторяют и во 2-й версии...

Answer 4

[lega]

А зачем переводить, если текущий фреймворк решает задачи? после релиза Angular 2, первая версия не протухнет, она будет активна ещё год, два, (пять?). Некоторые вообще на backbone и knockout все ещё сидят :P
А вторую версию ещё может помидорами закидают...

Answer 5

[Василий Мажекин]

Можно, но для этого вам нужно будет подготовить код приложения в соответсвующем стиле, тут полное описание миграции https://angular.io/docs/ts/latest/guide/upgrade.html