Добрый день. Необходима консультация по выбору технологического стека для клиентской части. Расскажу что было, мы использовали extjs для разработки системы управления процессами, документами, задачами. Первую программу выпустили за +7 месяцев. Получилось +10 000 строк кода на Extjs. Начали второй проект который практический взял из себя 80% функционала первого проекта и требования к дизайну и UI выросли слишком сильно, что Extjs не подходит. Backend реализован на Java (Play Framework).
Я принял решение сменить Extjs на Backbone. За неделю подготовил технологический стек: Backbone + Marionette, Typescript, RequireJS, jQuery, Handlebars, SASS, nodejs, grunt + many externals libs. Сроки и цель доработать основные элементы интерфейса на уровень 50% от написанного (Управление справочниками - удаление, создание, обновление, верстка достаточно гибкого UI, MVC - RESTAPI).
Требования модульность, асинхронная подгрузка классов, компонентная архитектура для реиспользования виджетов, view. Начал собирать это все дело и застрял с Typescript. Слишком много с ним мороки, надо определить для всех библиотек типизацию, возращаемые значения, модульность вообще с ним строится тяжело, нельзя подгружать из internal модуля, external модуль, постоянно просто ошибки вываливаются, вроде как по ходу получается фиксить, но затормозило процесс разработки. Смотрел на CoffeScript он обратно не совместим с JS.
Вопрос: Что вы думаете о выбранном стеке? Забить ли на Typescript и писать на прототипах? Реально ли хорошо подходит Backbone + Marionette для фронтенда с набором +150-350 классов которые должны использовать все это: Statefull views, very smart history, async loading, many views, nested views, versions (documents, models), nested models?
Отдельно замечу, что мне показался Backbone более гибким чем AngularJS, Knockout, Ember. Но сама по себе библиотека очень голая, хочется подрубить к ней готовые компоненты из других либ, поверх Typescript - сейчас уже представляю себе это с трудом...
Angular + Browserify в качестве сборщика модулей не рассматривали? Еще есть вариант с ES6 + traceur и другие трансляторы ES6 в ES5.
Смотрел на CoffeScript он обратно не совместим с JS
По сути так же как и TypeScript. Сорсмэпы есть, трансляторы есть, сборщики есть... построить процесс разработки не сильно сложно. И да, забейте на grunt и вооружитесь gulp-ом. Для больших проектов неслабо ускоряет процесс сборки.
Browserify - смотрел, по синтаксису понравился больше чем requireJs. ES6 + traceur - не встречал подобное решение, спасибо рассмотрю. По поводу AngularJS - при рассмотрении фреймворка показалось, что разработка сильно упрется в атрибуты html, сложно представлял как разбить компоненты на шаблоны (например HandleBars). Как я понял создается отдельный div-wrapper, у него и контроллер и модель внутри, классы CSS для оформления, ID - для поиска. Сложно ли в данном случае делать множество вложенных в друг-друга view?
larionov_n: по поводу CSS для оформления - курить в сторону БЭМ и модульной верстки.
По поводу ID для поиска - не понял что вы имеете в виду...
По поводу вложенности директив друг в друга - проблем нет никаких. МОжно строить иерархии директив, сложные UI компоненты реюзабельные...
В вашем случае все упрется не в "html атрибуты" а в "потратить недельки 2 на изучение документации". Это тоже нужно учитывать потому что если сразу начать ваять скорее всего по выходу получится неподдерживаемый монстр.
И все же раскройте ваши апасения по поводу "html атрибутов"?
p.s. Еще можно добавить в стэк технологий jade/haml. Я последние пару недель пересилил себя и решил таки попробовать - мне нравится.
Модульная верстка хороший способ инкапсулировать логику в отдельные компоненты. В целом не стоит задачи делать миксины разных контролов внутри сборного компонента, но идея хорошая (Я про БЭМ).
По поводу поиска по ID (Как использовать идентификаторы, как у jquery $('#')) - с ангуляр JS я так понимаю это не нужно, так как директивы сами кладут все в общий скоуп.
Спасибо за раскрытие темы по поводу вложенности директив в друг-друга, я так понимаю будет удобно и для Backend разработчиков, взял кусок HTML и вставил, данные сами по REST загрузились - все работает.
Думаю что не стоит торопиться с выбором Backbone и действительно две недели потратить на AngularJS.
Опасения по поводу html атрибутов есть - могу привести аналогию с Backbone, пример рендеринг коллекции юзеров. При рендере для каждого назначается свой обработчик, например по клику открывает модальное окно (пробрасывая параметр user id). На него подписываются куча других UI элементов - какие нибудь уведомления и прочее. Не понимаю как происходит рендеринг всего этого в AngularJS. Если в Backbone логика отрисовки ложится на метод Render у View, то тут понятен процесс: Ручками вызываем рендеринг или подписываемся на изменения в модели и рендер сам происходит - шаблон превращается в стрингу (HTML с проставленными переменными). У другой VIEW вызываем переписанный метод Append, onAppend срабатывает удаление прошлой View, срабатывает метод ОнДестрой и отписывает нужные события. Вот как происходит подобное дело внутри AngularJS - к сожалению не знаю, но логика подсказывает что похожим образом.
Jade, Haml - интересное решение, использовал на прошлом проекте, когда привыкаешь смотря на код видно сразу только нужное :)
larionov_n: Ну на примере того же списка пользователей. У вас есть $scope - это эдакая ViewModel, которая связывает вьюшки и контроллеры. Что бы отрендрить список пользователей нужно всего-лишь задать этот список в $scope (начиная кажется с версии 1,2 рекомендуется использовать Controller As синтаксис, тогда контроллер будет связан со скоупом через собственный контекст, это сильно упрощает в последствии отслеживание что кто вызывает и у кого просит).
<ul>
<li ng-repeat="user in users">{{ user }}</li>
</ul>
То есть за вывод списков и коллекций отвечает директива ng-repeat, она следит за изменениями в коллекции и выводит их при следующем цикле $digest (который и реализует слежку за изменениями объектов). Это один из основных моментов с которыми стоит разобраться - дата биндинг и скоупы. Если вам не страшно - можете залесть внутрь. Так же для понимания как вообще работают директивы и т.д. стоит почитать про сервис $parse и $compile.
Нам в начале тоже было сложно представить. Опишу некоторые из проблем, общий скролл на страницу, вложенные в таблицах грид (Сложные касотмные компоненты) - найти ячейку в грид и вставить в нее что-то (целый ад), слишком сильная по дизайну и функционалу кастомизация TreeGrid, реализация сложных меню, элементов для подстветки выделения UI элементов. Ограничения по дизайну нужно учитывать компоненты Extjs либо писать свои. Я за 7 месяцев написал около 40 компонентов, мы очень сильно изменили представление дизайна в Extjs. Но в итоге в будущем предвидятся слишком сильные изменения от дизайна к дизайну, время на разработку слишком большое. Пришли к выводу что проще написать не на Extjs и время на смену дизайна и элементов функционала и UI будет меньше.
larionov_n: можно пару вопросов, просто для себя интересно
1. Общий скрол? Его же можно убрать /добавить.. не понятно в чем именно проблема.
2. Вкладывать в ячейки грида данные это действительно не легкий путь. Вы уверены, что в других платформах это делается легче? Я использую простой listview вместо грида если нужно чтото сильно кастомное. Он просьбой и очень хорошо настраивается с помощью css
Вообще, при проектировании конечно нужно учитывать платформу. Чем проще дизайн, тем легче понимать программу и ее создавать )
Может быть вам стоит попробовать внутри extjs использовать другие визуальные движки, это ведь не запрещается?
Про общий скролл я имел ввиду такой юзер кейс - Есть левая навпанель допустим меню, есть region-layout (north, west, east, south) - Внутри Header и Viewer (Главный блок который постоянно меняется). Туда обычно падает (Панель->еще внутри панелей 5-> в каждой может быть таб панель, кард лайаут и кучу всего что должно тянуть общего родителя Viewport вниз). Однако есть костыль ставим на Viewport - overflowY: 'auto', autoscroll: false. Вроде работает, но при этом не получается поставить на region-layout этот скролл, что бы допустим он был от хедера и до самого конца страницы. В общем эксперементировали много... Как только не делали, заказчик хочет поведение скролла как при верстке. Нас 3 человека фронтенда, один работал с Extjs 2 года, на мои вопросы как решить вопрос со скроллом размахивал руками. В итоге вместе с руководителем разработки ПО уволился после того как завалили дедлайн.
И получилось что нам Extjs дает интерфейс, а заказчику мы должны показывать другой интерфейс который больше похож на хорошую верстку с кучей отзывчивости вплане дизайна и юзабилити. Но при этом там просто миллион функционала. Для того что бы Extjs на этот уровень вывести мы просто сутками работали и заказчик опять все завилил :) Хотя мы понимаем что там jquery + bootstrap + тут грид от Extjs вроде должно получится, а тут неплохо AngularJs DataBinding на сверстанном куске сложного дизайнаНо руководитель наш запретил использовать сторонние библиотеки. В итоге его начальство уволило.
Причем у нас были интересные ситуации когда использовали Ext.ComponentManager.create(компонент) - нужно было место для отчетов, где данные рендерятся меньше 800мс. (Много цифр, канвас, свг). Сделали вначале вложенные компоненты с минимум в себе API от ExtComponent, что-бы эти элементы находить и проставлять значения в момент рендеринга (У брайзера занимало почти 2 секунды на 20 мини вьюх). В итоге как решили проблему, взяли написали большой XTEMPLATE и руками через document.getElementById снизили время рендеринга в 1000 раз. Ушло два для на оптимизацию, а по нашим срокам это смертельное время. И это только одно такое дырявое место в нашем приложении. Особенно запоминание состояний постоянно глючит и отрисывывается как-будто с багами. Плюс надо держать 960-1920 разрешение, а дизайнер частично при проектировании UI косячил и некоторые элементы просто не вмещаются в область видимости :) Я уже не говорю о том, что когда я пришел работать проект стилизовали с помощью овверайда LESS темы скомпиленной для Extjs. В общем 60% времени уходило на заправку дизайна. Функционал как раз с помощью Extjs писался великолепно, были проблемы с РЕСТОМ, асинхронными запросами, вложенными моделями, но в итоге костылем все зарешали.
К сожалению разработка началась раньше чем проектирование UI. Поэтому пришлось тяжко.
Я рассматривал вариант чтобы рендерить тот же бэкбон внутри Extjs и использовать Jquery в рамках бэкбона. Но наш руководитель зарубил все попытки сторонних либ. В итоге Генеральный директор его уволил :) и теперь про экст джс слышать ничего не хочет.
larionov_n: 1. Про скролл - понятно. Частенько бывают проблемы с этим, но все в конечном счете решается правильным вложением панелей. Хотя допускаю, что могут быть баги.
2. По поводу прорисовки через dom все верно, это норма. Быстрые вещи так и надо делать
3. Вобщем у вас все сложно, конечно. . Все эти организационные проблемы, никому такого не пожелаешь ) В принципе, если такие большие требования к дизайну и ваши руководители не могут правильно довести до заказчика идеологию построения ui в extjs, то надо на что-то переходить )
Dremkin: Рад, что вы солидарны со мной по поводу того что надо на что-то переходить :) Но эта идея не менее печальна, чем организационные вопросы. На проекте остался один я, теперь еще и людей приходится искать с пока что не определенными требованиями.
larionov_n: ну просто extjs именно предлагает один из вариантов gui. Если такой внешний вид и концепция не устраивает, то нужно изобретать что-то свое, иначе будут постоянные костыли.
