Переход с ASP.NET на Angular2 с особенностями (личный опыт)

[@denismaster]

Еще доступны генераторы для yo и dotnet new, возможно вы найдете в их репозиториях что-то полезное, например, автосборку. Успехов!

[@Shwed_Berlin]

Спасибо. Пользовался этим генератором. И в принципе слежу за парой репозиториев на GitHub по этой тематике.
Автосборка (webpack dev middleware) там привазана к Core библиотеке.

[@MasMaX]

Вместо npm попробуйте yarn. На фронтенде он выигрывает в скорости сборки значительно. И проще разрешает зависимости зависимостей.

[@Shwed_Berlin]

Немного озадачен вашим комментарием. Сборка в моем случае осуществляется не npm, а webpack.
npm лишь пакет-менеджер. Или я что-то неправильно понимаю?

[@socrat3z]

Все верно. Yarn — замена npm (после выхода node.js 8 достаточно сомнительная). Для ускорения сборки используйте кеш к webpack и к awesome-typescript-loader + можно поэкспериментировать с HappyPack

[@Shwed_Berlin]

Спасибо, буду разбираться.
Пока приоритет поставлен на другие пункты — мне нужно понять подойдет ли для реального проекта (аутентификация и полная работоспособность в IE).

[@zodchiy]

Перехожу с mvc 5 + Angular 1.x на net core webapi + Angular 2/4.
Тоже корпоративная разработка.
Прошел ваш путь. Понял, что этот путь для меня избыточен. Побаловался и пришел к выводу, что разделить проект на 2 части будет проще.

Фронт-энд на VS Code под Angular 2/4 билдит файлы в wwwroot бэк-энд проекта.
Бэк-энд на VS 2017 net core webapi.

[@Shwed_Berlin]

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

[@SergeyVoyteshonok]

В продакшене web api и view обычно разделяют, объясню:
1. Часто разные люди отвечают за backend и front, соответственно удобно когда репозитории разделены, например ветвление по новым фичам, новому дизайну и тд в Git.
2. Методы доставки и развертывания тоже разные, если backом обычно все сложно ( миграции, настройки, тестовые контуры и тд), то front достаточно доставить на сервер раздающий статику ( кстати он может быть отличен от сервера где сидит web api)
3. Ну и в принципе смешивать настройки intellisense, сборки и тестирования клиента и сервера в одном workspace как-то не очень. Как вариант: хотя бы выделить клиент в отдельную папку в коде сервера.

[@Rinz]

Заголовок хоть поправьте, а то выглядит как будто ведется переезд с Backend технологии на Frontend, меня аж завлекло в эту статью что за чудо тут, а оказывается переход с ASP-Form(Я удивлен что сие технологию еще не похоронили).
Я лично больше предпочитаю Ember для фронта, ангуляр эта вещь которая не особо поддерживает обратную зависимость, медленная, жирная, отношения Гугла к ней вполне сомнительная т.к. то заявляли что бросают, потом выпускают новую версию которая чуть более чем ломает всю совместимость, позже выпустили Полимер, короче дело ваще но для продакшена я бы лично не выбрал странные технологии которые развиваются очень странным образом(пример с языком Ruby)

[@Shwed_Berlin]

Это корпоративный продукт, тут и не такие динозавры водятся.
ASP.NET (хоть MVC, хоть Forms) — это не бэк-енд, а «два в одном» в моем представлении.

[@Rinz]

Нет, вы не правы. ASP.net это веб/бэкенд фреймворк, а использовать ли сахар типа форм это уже выбор каждого, это тоже самое говорить что JS это и бэкенд и фронтенд язык, ведь есть Nodejs а это тоже вроде JS и потому получаем что ангулар тоже два в одном, ведь можно впаять Nodejs скрипты в него, можно. Вот такая цепочка происходить если неккоректно называть продукт тем чем он не является, если ты видишь тесто, ты ведь не называешь его макаронами или хлебом?! Тут та же история, формы это сахар, а все остальное это цельный продукт, MVC это архитектура продукта т.е. некая схема по которой приготовлен… Я уже теряюсь с чего мне объяснять столь очевидные вещи.

[@Shwed_Berlin]

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

[@SergeyVoyteshonok]

Пункт «еще предстоит сделать» я бы немного поправил:

1. Убрать закомментированный код.
2. Добавить в gitignore файлы, которые генерируются.
3. Все остальное…

[@Shwed_Berlin]

1. Резонно. Тороплюсь, пробую — не всегда успеваю удалять.
2. Мало знаком с Git. Попробовал добавить /dist в gitignore уже после первых коммитов — папка коммитится вместе с остальными изменениями. Попробую позже разобраться.

Спасибо

[@zmeykas]

попробуйте
git rm -r --cached dist/


[@SoloMidPlzD]

@корп софт
@мало знаком з гит

[@Shwed_Berlin]

Как понимать ваш комментарий? Кому он предназначен?

[@DimonDU]

Я тоже пытаюсь затащить Ангулар в корп софт. Больше всего понравилась серия статей на кодпроекте https://www.codeproject.com/Articles/1139558/Single-Page-Application-SPA-for-Enterprise-App-Ang

[@Shwed_Berlin]

Спасибо, я посмотрю поподробнее.
Но уже на первый взгляд — Angular там используется весьма странно. Например зачем то городится реализация IoC, хотя в Angular она уже реализованна.

[@kosmonaFFFt]

Попробуйте @ angular/cli — тулза от ангуляра для генерации проекта, его сборки, тестирования и других вещей.

Например:
ng new mysuperproject
cd mysuperproject
ng serve

создаст проект и запустит локальный сервер с горячей пересборкой проекта при изменениях и автообновлением его в браузере. Можно настроить прокси к бекенду и сразу использовать имеющееся API для разработки.

ng generate component mysupercomponent — сгенерирует компонент (ts + html + css + unit test).
Ну и другие вещи, которые можно узнать из ng --help…

[@XeL077]

Добавил bootstrap и jQuery

Зачем вам jQuery в этом проекте? Сторонние плагины или работать с DOM? Он портит работу angular т.к. у него используется виртуальный DOM и все изменения $('.test').hide() портят работу.

Для этого есть встроенные методы angualr со всем сахаром.

[@Shwed_Berlin]

Сторонние плагины.
Как я написал планируется редизайн имеющегося приложения и т.о. пытаюсь использовать имеющиеся наработки. В частности sly.

[@XeL077]

Мне кажется, что лучше вынести angualr проект в другой репозиторий, отделив его от server.net проекта, переписывать по кусочкам.

jQuery можно подключать как зависимости angular для компонентов (компонентов обверток над существующим кодом). А webpack сам разберется, на случай, если захочется сменить компонент (уязвимость или дизайн устарел), но не захочется править 100500 мест в коде из-за сменившегося api.