Comments 43
Спецификации и браузеры (источник — Microsoft API Catalogue)
Specifications = Microsoft Edge?
At a practical level, there is a lot of magic that occurs to provide run-time behavior that is not part of the core framework-provided technologies. This diminishes the value of TypeScript to the end-developer.… Т.е. вывести ts-девелоперов (и беря в общем специализирваннх angular-UI-девелоперов) не получится, надо лезть под капот. Можно предположить что есть какой-то миф что angular это все что надо знать для того чтобы делать UI в вебе, с которым автор таким образом и спорит.
Я сейчас страшилку на ночь вам расскажу: пишу на TS, при этом юзаю Backbone(Exoskeleton). Для обычных сайтов с обычной загрузкой контента я все еще не нашел ничего более удобного.
Хотя, понятное дело, для собственных проектов буду использовать любой фреймворк из большой тройки.
Ангуляр2 же для нас оказался лучший выбор. Я переписал 30 тыс строк кода до-jquery системы на ангуляр постепенно внедряя ангуляр (и это оказалось супер успешно). У нас до сих пор часть (небольшая когда) осталась на старой джаве и все отлично работает обернутое в тайпскрипт с aot. В будущее же я смотрю на Polymer/WebComponents, и stencil от ionic-team. Осталось подождать и увидеть что из последнего получится.
Недели эдак 3 пытался подружить angular 4 с sharepoint 2010 так как для новой задачи требовались некоторые реактивные вещи без страшных педалей на jquery. Коллеги предложили попробовать vue и я подсел как на наркотик…
Задача которая выглядела трудно решаемой стандартным для меня подходом (лапша на jquery или адаптация решения предыдущей команды на angular 1.4) улетучилась созданием маленького приложения на vue из 3 компонентов, хотя конечно некоторые вопросы остались))
Сделать так что бы автоматом в веб — часть транслировались ссылки не самая простая задача. У вуе большой плюс в том что затащив всего одну ссылку мы спокойно пишем код не думая больше ни о чем
Во-вторых, если уж вы ввели в веб-проект стадию сборки из исходников, то ничего уже не мешает настроить запуск webpack, rollup или хотя бы browserify после tsc.
Да там вся разница в том, что у tsc есть поддержка со стороны системы сборки, а для чего-то еще надо самому цели для msbuild писать.
Если посмотреть файл Microsoft.TypeScript.targets, будет видно что он встраивается в зависимости целей Compile и BuiltProjectOutputGroup, а также врезается в свойство PublishPipelineCollectFilesCore (это середина списка зависимостей цели PipelineCollectFilesPhase).
Для webpack или чего-то подобного можно сделать так же.
Или же можно просто встроиться на AfterTargets="CompileTypeScript;CompileTypeScriptWithTSConfig" если лень разбираться.
Страшное слово sharepoint видимо обошло стороной Вас стороной.
Проблема не совсем в том что бы положить нужные файлы (это я прекрасно умею — например успешно сейчас делаю хсору после успешной сборки ;-)), а в том что бы в проект внутри проекта (ascx контрол) забросить пути к скомпилированным файлам, о которых он даже не имеет представления. Можно конечно и ручками или через внедрение из файла или бд… Однако это не самый хороший вариант. Плюс вопрос времени, сколько будет занимать компиляция большого ангуляр проекта в сингл файл? Особенность sharepoint в том что для того что бы увидеть результат изменений нужно развернуть решение на ферму.
У вью большой плюс, на мой взгляд, что мы заранее положили один файл, указали к нему путь и спокойно с ним работаем в разметке контрола. Это и быстро и удобно. Хотя и не хватает всей мощи ts
Э… и в чем же проблема прописать путь вида /_layouts/15/Foo/allscriptsbundled.js?
Плюс вопрос времени, сколько будет занимать компиляция большого ангуляр проекта в сингл файл?
Она происходит намного быстрее чем развертывание решения на ферме. Когда вы работаете с шариком, скорость компиляции — последнее что должно беспокоить :-)
Это может привести к сложности поддержки проектов, если базовые принципы, на которых они основаны, не были чётко сформулированы в самом начале их разработки. На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка.
Хоть один пример бы, а то чувствую себя слепым и ущербным теперь.
Мы полагаем, так вы полагаете или вы хотя бы hello world написали?
Свежий пример от соседей, где используется ngrx (это redux из мира angular): запилили грид для одного экрана со стором, экшенами, редьюсерами и вот этим всем. И всё бы хорошо, да потребовался такой же грид на другом экране, а весь код гвоздями прибит к конкретным экшенам и путям в сторе. Выхода два: копипастить кучу логики с тривиальными правками, либо рефакторить весь код добавляя инъектирование путей в сторе через параметры компонент и пробрасывать их через экшены в редьюсеры.
А, не проснулся ещё, вы же про Ангуляр, а не про Реакт… впрочем, я тоже про Ангуляр :-)
Нет, на самом деле, я верю в потенциал ngrx и реакт модели и не важно где это, в ангуляре или у черта лысого применено, важно лишь то, что человек, который это использует должен отдавать себе отчет в том что он делает. Ведь не сам код прибился гвоздями и не ангуляр его прибил, правильно же?) Ведь все зависит от того, как код писался, насколько гибко, сколько раз программист подумал прежде чем его написать.
Плохой, не поддерживаемый и не переносимый код можно написать на любом языке/фреймворке. Я как человек достаточное время работающий в аутсорс разработке не понаслышке знаю о внезапно меняющихся требованиях, иногда, будь они прокляты, координально меняющихся, но я не помню чтобы я в это время при возникновении трудностей винил инструмент. Я винил только себя за то, что поленился и не продумал момент. И уж тем более я не помню нерешаемых проблем, хотя нужно отметить, что я сталкивался с подобным кодом, который писали индусы, там впринципе проще сделать
rm -rf ./project_dir
mkdir project_dir
start coding
Потому что индусы ребята конечно очень способные в этом плане)
На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка.
Эту цитату можно применить к любому фреймворку на мой взгляд, рано или поздно разработчик сталкивается с таким, но это «рано или поздно» может наступить совсем не скоро, либо не наступить вовсе. Ведь как известно, наши заказчики люди с оооочень богатой фантазией…
Это проблема плохо спроектированного стора, а не редакса (ngrx), и уж тем более не ангуляра.
Ну так расскажите же как правильно проектировать стор, чтобы компоненты (а не только их шаблоны) получались переиспользуемыми.
Конкретный пример можно рассмотреть, но надо знать о нем несколько больше, чем «где-то был грид и где-то какие-то редьюсеры, и это было плохо», давайте какие-то базовые подробности, и обсудим. Каков функционал грида, какое апи к нему, что конкретно делают экшоны в сторе.
Хотите сказать, что они специально постарались сделать грид не преиспользуемым?
Стандартный функционал: запрос данных из видимой области, редактирование, сохранение, ресайз колонок, изменение состава колонок, изменение фильтров, загрузка данных для вариантов фильтров по требованию. Вот это всё.
Скорее всего это было побочным эффектом. Например — было ограничение во времени.
> Стандартный функционал: запрос данных из видимой области, редактирование, сохранение, ресайз колонок, изменение состава колонок, изменение фильтров, загрузка данных для вариантов фильтров по требованию.
Так тут два вопроса:
1. Что тут именно не переиспользуется и почему? Знает ли сам компонент о редаксе (очевидно, не должен)? Нормальный компонент просто принимает данные, рендерит их, дергает колбеки при смене фильтров и т.п., а уже загрузкой/сохранением и т.д. заведует сервисный слой. В рассматриваемом случае было не так? Почему?
2. Зачем вообще здесь редакс? Локальные данные компонента в нем хранить не надо, только разделяемые.
было ограничение во времени
А как же:
получаются переиспользуемыми по умолчанию
?
Нормальный компонент просто принимает данные, рендерит их, дергает колбеки при смене фильтров и т.п., а уже загрузкой/сохранением и т.д. заведует сервисный слой.
Тут вы описали "шаблон". Только в реакте шалоны называют компонентами. Во всём остальном мире компонент — самодостаточный кусок приложения инкапсулирующий в себе данные и поведение, а не выпячивающий кишки наружу.
а уже загрузкой/сохранением и т.д. заведует сервисный слой.
Это похоже на заметание мусора под ковёр. Ребята сделали всё по канонам — кидаются экшены, дёргаются редьюсеры, меняется глобальное состояние. А когда пришла пора воспользоваться компонентом на другом экране вдруг произошёл когнитивный диссонанс от необходимости копипастить весь этот "сервисный слой", гвоздями прибитый к конкретным экшенам и конкретным полям стора.
Зачем вообще здесь редакс?
Зачем вообще редакс? :-)
Переиспользуемыми по умолчанию компоненты получаются на обычном Ангуляре, без ngrx.
Нет, я описал компонент. И компонент таблицы, очевидно, не должен заниматься, например, загрузкой данных. Если у вас занимается — то, конечно, он будет прибит к способу этой загрузки, но при чем тут фреймворк? Это ваше архитектурное решение — прибить логику работы с данными к компоненту грида.
> Зачем вообще редакс? :-)
Для работы с глобальным стейтом. Если у вас нету глобального стейта (или он минимален и прост), то редакс не нужен.
> Это похоже на заметание мусора под ковёр.
Это не заметание мусора под ковер, а классическое разделение на service layer и presentation layer. Если вы вполне себе намеренно прибили одно к другому гвоздями, то прибили. Но при чем тут фреймворк?
> сделали всё по канонам — кидаются экшены, дёргаются редьюсеры, меняется глобальное состояние.
Очевидно, они ничего не сделали как надо, потому что рекомендованный способ работы с редаксом («как надо») — генерировать редьюсеры и экшены, а не писать их руками. В вашем случае они писались руками => копипаста. Если бы, согласно рекомендациям, экшены/редьюсеры генерировались, то вы бы для другого грида просто дернули ту самую ф-ю генерации, но с другими аргументами. В итоге дублирование логики было бы исключено.
Мне вот непонятно почему практически все фреймворки имеют архитектуру начинающуюся на M, но при этом никто эту M нормально реализовать не считает необходимым. Разве что ember-data можно считать нормальной такой M
Большинство же говорят (либо умалчивают) — мы вообще про интерфейс, а не про данные и бизнес логику. А модель ты дорогой разработчик реализуй сам. Последствия этого весьма печальны, в большинстве приложений модель вмазывается прямо в компоненты.
«В мире только две вещи бесконечны: статьи-сравнения веб-фреймворков и вселенная. Хотя насчет вселенной я не уверен.»
Тогда его спросили — значит получается абсолютная истина существует?
Альберт, вздыхая, промолвил: «На нашей планете есть как минимум одна неизменная мудрость, константа if you will, заключается она в следующем: сколько бы времени не прошло и сколько бы людей не трудились на Vue, все равно найдется тот, кто скажет Vue неплох, но держится-то он на хрупких плечах одного китайца»
Анализ шести веб-фреймворков: плюсы, минусы и особенности выбора