VueJS ???

[url=https://www.youtube.com/watch?v=KMX1mFEmM3E]Angular vs React.js vs Vue.js - My Thoughts![/url]

Пока не использовал, но это мне нравится [url=https://vuejs.org/v2/guide/single-file-components.html]https://vuejs.org/v2/guide/single-file-components.html[/url]

Вот точно такой же подход я использовал для Ангуляр1 Components (они появляются в 1.5 версии хотя с виду те же директивы). Брал шаблон, сам код компонента, немного шаманства с инициализацией и все это дело запихивал в 1 VF Component.

Использовать элементарно.
Делается страница с самим приложением ангуляр и все нужные компоненты просто подгружаются 1-й строкой

<c:MySuperDuperComponent />

Все! Больше ничего. В шаблоне приложения сразу можно использовать компонент как тег.

И никаких тебе статик ресурсов, никакого гемора со сборщиками.

Как нибудь опишу детально этот подход. Как будет время.

[url=https://github.com/vuejs/awesome-vue]https://github.com/vuejs/awesome-vue[/url]

[quote="Dmitry Shnyrev"]Что за VueJS?[/quote]

А как же Angular? Ты уже закончил делать свой покает?:)

Смотря какой :D
Вообще как бы я продолжаю погружаться в Ангуляр2. 
Но я так понимаю что ты имеешь в виду мой проект NG2SFDC (https://salesforce-developer.ru/forum/topic-ng2-sfdc-solutions-beta-1) - увы проект пришлось забросить за ненадобностью. Месяц я его пилил, но кушать хочется и пришлось обратно возвращаться к трудовым будням. Вернулся обратно в мир VF и первого ангуляра. Очень конечно жаль, но наработки покрылись мхом. Данный проекту необходим испытательный полигон - новый проект, где можно начать его применять и усовершенствовать, но пока такого на горизонте нет.

А чтобы продолжить с темой ангуляра2 я в свободное время потиху продвигаю свою старую любимую НЕ SFDC тему - решил запилить движек для сайтов на NodeJS/ExpressJS/Angular2 (https://github.com/dmnBrest/eCMS). Как бы у данного проекта перспектив больше - хочу этот сайт перевести на новый движет - есть цель, и поэтому есть стимул. У NG2SFDC цель потерялась :( (возможно временно, я надеюсь)

[quote="Dmitry Shnyrev"]У NG2SFDC цель потерялась :([/quote]

Очень жалко :(

У меня сейчас на ночу проект с 0 и клиенту Salesforce впаривает свои Lightning Components.
У меня есть опыт работы с ними, даже сейчас иногда сапорчу свои компоненты. Но framework настолько тугой что ужас...
C другой стороны я провел пол года на проекте AngularJS + Webpack + SLDS и хочу сказать охоты работать на LC у меня не сильно много :D
Так вот, я думаю продвигать тему с Angular на новом проекте, будет видно как клиент отреагирует...

Продвигать Ангуляр однозначно стоит.
Я вообще не понимаю как можно с Lightning Components работать - по мне штука крайне неюзабильная и глючная. 
С другой стороны Ангуляр 2 брать вот так без подготовки тоже не стоит. Хоть он уже много раз релизился все равно изменения прут как из рога изобилия. И то что я скажем делал еще в феврале сегодня уже устарело и обратно несовместимо. Руку постоянно держать надо на пульсе. А для долгоиграющих больших проектов надо минимум 100% поддержка клиента и его отвественность за выбранный стек технологий. Очень будет непрятно объяснять почему через полгода наработки уже морально устарели. 

В этом плане ангуляр 1 (1.6.х вроде последний) сильно выигрывает в стабильности. Он уж точно никуда не будет развиваться, тупо поддерживаться. Увы за стабильность придется платить использованием уже "устаревающей" технологии. 

Вот почему на арену выходит VueJS. По сравнению с первым ангуляром он развивается. По сравнению со вторым ангуляром он как УАЗ по сравнению с космическим шатлом - подключил VueJS из CDN на страницу и пользуйся. Завести приложение на Ангуляр 2 надо блин еще постараться. И не стоит обманчиво верить в Hello World из туториала - шаг вправо шаг влево - приплыли. Плюс тот же TS. Не все его знают и не все его хотят знать. 

Я бы на твоем месте, Руслан, попробовал бы на досуге c VueJS поиграться. Там реально пород входа ниже плинтуса. А теперь и звездочки на github сильно добавляют значимость. Клиенту можно указать на эту особенность. Думаю его это заинтересует. Во всяком случае любыми путями надо спрыгивать с Lightning Components.

А вообще, если мне представится возможность попилить проект с нуля, то я обязательно вернусь к своему тулу. :)  

[quote="Dmitry Shnyrev"]c VueJS поиграться[/quote]
Поиграться можно, но садиться писать проект не стал бы, наверное)
Я пол года AngularJS 1.5 + ES6 компонентах отлично себя чувствовал, думаю если не Angular 2/4 то уже лучше по накатаной, где я уверен в себе...


https://www.npmjs.com/package/slush-angular-sfdc-webpack
https://www.npmjs.com/package/webpack-sfdc-deploy-plugin

Может кому полезно будет

Все больше и больше начинаю поглядывать в сторону Vue.
Долго держался, но по ходу нервы заканчиваются.
Да и все большее количество хейтерских статей про Ангуляр 2/4 не проходят мимо.
Я думал что это я какой-то неправильный и продолжал жрать кактус, но выходит что я не одинок.

Вот очередная полезная статья
[url=https://habrahabr.ru/post/337578/]Как я перестал любить Angular[/url]

Многое разложено по полочкам. 

Но самое приятное в конце - интересная подборка для Vue.
Особенно приглянулся [url=http://element.eleme.io/#/en-US]Element[/url]

Надо пробовать потихоньку переходить.


Как раз про переход.
Опять же с волной неудовлетворения от Ангуляр 2/4 пришло и неудовлетворение от NodeJS. Мое желание использовать  для fullstack разработки Javascript опять подвело. Да, очень многое получается, и очень много я всего запилил  на NodeJS+Angular2/4 но какого-то удовольствия это не принесло. Половину процесс разработки так и осталось магией. Проект вырос в полугигабайтного монстра. Бэкенд хоть и работает быстро (как и ожидается от NodeJS) но жрет памяти просто жуть. Работа с ошибками и дебагом просто ужас - работать приходится практически на интуиции и чисто с помощью console.log . ВЫВОД один - NodeJS не подходит для серьезной Enterprise разработки. Дело еще можно спасти с помощью Typescript, но это уже танцы с бубном.

Решил опять вернуться на Go, но теперь попробовать его в связке в VueJS + Elements.

Ну как тебе Vue, я начал писать на нем проект.

Я тоже начал :) Сильно нравится!

Даже успел свой тул который пилил под Анлуляр2 переделать под VueJS :)

Что сильно впечатлило. Доку прошел и склепал скелет проекта за 2 вечера (причем не просто стандартный шаблонный проекта, а уже боевое под SF c интеграцией). Это просто супер. Хотя надо отдать должное опыт потраченный на Ангуляр2 сильно помог. Особенно понравились их Router и Vuex (это в особенности). На Ангуляре2 я такую сборку заставлял работать наверное пару недель.
Ну и конечно итоговый размер бандла порадовал. По сравнению с 3 метрами от Ангуляра совсем другая история.

НО вот что я хочу отметить! Вижу что последнее время разработчики Ангуляр 2/4+ сильно активировались. Поняли что начинают просерать аудиторию которая валом повалила на Vue и решили повернуться лицем к людям. В общем наблюдаю много улучшений в angular-cli. Добавили много фич которые я пытался полгода назад собрать своими велосипедами. Слышал что в 5-й версии уберут много лишних абстракций и тем самым уменьшат объемы кода. К примеру сделали поддержку файлов компонентов которые сразу включают в себя template + css. (ничего не напоминает? .vue?).

Ну и еще небольшой анонс. В ходе перепиливания своего десктопного NG2Solutions под Vue (который напомню работает как MM из под Electron) понял что в целом Electron то мне и не нужен. Появилось видение как запилить чисто под webpack + кастом дев сервер. Таким образом хоть мои достояния и станут общественными, но хотя бы начнут приносить какую-то пользу другим разрабам. Пока с Электрон версией все сильно печально - до стабильной версии еще далеко, и времени пилить нет.

Поэтому так как выпал шанс поработать с VueJS попробую реализовать чисто консольный вариант на базе webpack.

Но еще раз отвечая на вопрос - я впечатлен VueJS и пока планирую развивать это направления.  

Через что ты данные тянешь в JS из SF?

Через свой кастомный прокси сервер на Express.
Шлю на него все запросы для SF. А но уже форвардит на SF.

Пошла движуха с Vue.
Перепилил свой дев прокси сервер на cli версию на выходных. Вроде получилось отлично! 
Сейчас буду тестить и причесывать. Все-таки без Electron как-то проще получилось.
Но вот что я понял. Как отказался от ангуляр2, решил пересесть обратно на чистый JS.
Мля, ну это и болото :( Я реально провел почти день в борьбе и муках пытаясь работать с Javascript. Проблема в том что нет четких границ как надо писать - все во что горазд пилят модули. Одни модули подключаются так, другие по другому. В одних примерах в нете используют ES6/ES7 в других на ES5 еще сидят. Пытаясь все это объединить в одном файле получается реальная каша. Плюс не получилось толком завести автодополнение и валидацию кода в VSCode (хотя перепробовал кучу плагинов). Может так и должно было быть, просто я не догнал, но то что я получал ни в какое сравнение не шло с тем как работает редактор под TS. В JS 60% ошибок получал уже в runtime. В итоге плюнул на свою затею, подключил TS компилятор и почувствовал себя человеком :) Все-таки эти товарищи из Microsoft(те кто разрабатывают) и разработчики Ангуляр2(которые продвигают в массы) не просто свой хлеб едят. 
В общем возвращаюсь к TS сердцем и продолжаю развивать его, потому что тратить время (когда его и так нет) на JS со всему его вариациями то еще удовольствие. Вскоре попробую прикрутить его к Vue (тем более они обечают какую-то поддержку для Typescript).

Продолжаю пилить проект на Vue.
Разросся он уже до приличных размеров и уже исходя и некоторого опыта могу сделать некоторые заключения.

Соглашусь что пород входа в Vue на порядок ниже по сравнению с Ангуляр2, но это заметно только на небольших проектах. Сейчас у меня проект дорос до размера "средний" и Vue начинает сдавать. Слишком часто появляются "неявные" ошибки, которые приходится ловить методом исключения кусков кода. Пару раз из-за ошибок в структуре .vue файла проект начинал вести себя "неадекватно". Как бы такие проблемы должны были отлавливаться на этапе компиляции (.vue в plain js) но увы этого не происходило.

Так же странно ведет себя реактивная модель Vue. Все переменные со всеми атрибутами должны быть явно указаны в описании компонента иначе Vue их просто не будет видеть. Есть возможность динамически добавлять атрибуты, но все это опять же надо описывать ручками. После Ангуляра это непривычно, но Vue позиционирует это как преимущество. 

Опять же много проблем отлавливается только в runtime (привет Typescript :D )

Возвращаясь к реактивной модели - в нем как-то сильно много магии, и иногда она не хочет работать. В этом плане второй ангуляр мне больше понравился. Там все намного прозрачнее благодаря RXJS (и не надо говорить что бери и используй его вместе с Vue, я пока про коробочное решение говорю).

[b]Очередной вывод.[/b]
Vue хорош на небольших проектах. Если проект серьезный, то придется прикручивать обвес, чтобы все работало хорошо. Ангуляр2 уже из коробки поддерживает работу с крупными проектами.

Продолжаю изучение Vue :) посмотрим как пойдет дальше.

[quote="Dmitry Shnyrev"]Через свой кастомный прокси сервер на Express.
Шлю на него все запросы для SF. А но уже форвардит на SF.[/quote]

Где хостишь сервис? Heroku?

Локально. Поднимается вместе с webpack

[quote="Dmitry Shnyrev"]Локально. Поднимается вместе с webpack[/quote]

То-бишь это у тебя что-то вроде pat project? Морда у тебя на SF не живет вообще?

Не уверен что понимаю что ты написал.
Сам проект при разработке живет и запускается локально.
Когда готово деплоишь на SF.

[quote="Dmitry Shnyrev"]Не уверен что понимаю что ты написал.
Сам проект при разработке живет и запускается локально.
Когда готово деплоишь на SF.[/quote]

Потом запросы идут на прямую в SF через REST API? Когда готово и задеплоено?

Когда проект оказывается уже залитым в SF и там запускается он работает через RemoteAction. Когда локально, то типа через REST. Самому проекту фиолетово - он вызывает абстрактный RemoteAction, который сам определяет как ему слать запрос в зависимости от окружения.

[quote="Dmitry Shnyrev"]Когда проект оказывается уже залитым в SF и там запускается он работает через RemoteAction. Когда локально, то типа через REST. Самому проекту фиолетово - он вызывает абстрактный RemoteAction, который сам определяет как ему слать запрос в зависимости от окружения.[/quote]

Понял, звучит не плохо :)

Есть ряд недостатков которые надо как-то разрулить на будущее. 

Проект фактически состоит из 2-х проектов: обычный SF проект для бэкенда (в том же MM) и фронтенд проект (я пилю его под VSCode). Порог вхождения уже увеличивается в разы. Раньше при работе с Ангуляр 1 когда было достаточно подключить ангуляр из CDN/статик ресурса на SF страницу и начать пилить, каждый SF разраб мог с этим справиться. Сейчас уже чтобы развернуть проект уже надо быть более технически грамотным и минимум дружить с NodeJS. Так же SF уже перестает быть "источником правды" для исходников. Уже не получится просто так слить проект из SF и начать работать. Сейчас в SF заливаются ТОЛЬКО собранные JS бандлы, а сами исходники хранятся где-то в git репозитории в лучшем случае.
Попробовали на днях с коллегой поработать параллельно над одним проектом в таком ключе. Всплыло куча нюансов по управлению зависимостями, по деплою в SF.

В общем такая разработка сильно усложняется для неподготовленных разработчиков. Просто так посадить студента, показать как слить проект с SF, внести изменения и сохранить уже не получится.

[quote="Dmitry Shnyrev"]
В общем такая разработка сильно усложняется для неподготовленных разработчиков. Просто так посадить студента, показать как слить проект с SF, внести изменения и сохранить уже не получится.[/quote]

Это как бы изначально ужасная идея так работать... Индевидуальные Sandboxes/Scratch Org - это хорошо, но Source of True все-равно должен быть VCS. Если ты студен и не знаешь что такое VCS и не знаешь базовых комманд того же Git - иди учи, рано еще работать.

Я был на проекте где мы на AngularJS все собирали и деплоили с помощью Webpack Plugin при каждой сборке, а сборка была на watch (то бишь при изменении файла). Процесс был суперский, все было отлажено, комманда расприделенная из 4 стран и нам не надо было друг друга дергать - все изменения были видны в Github. По сути больше и не надо, только если надо что-то конкретное узнать.

Мое мнение - если SF разраб до сих пол сидит на VF + jQuery, грош цена ему. Даже тe же Lightning Components стоят внимания. Как бы кто не плакал, Salesforce не откажется от них. А если кто не понимает почему был выбран именно Aura, читайте доку именно по Aura + Java, как работает эта машинка внутри...

Я тоже работал в проектах где использовали git + ant + CI и 100% за такой подход. 
Но данный подход оправдывает себя на 1 большом проекте где трудятся N разработчиков.
Я сейчас работаю в компании в которой по 10 проектов на 1 разработчика и эти проекты часто параллельно пилят на стороне клиентов. Тут ни о каком Git как источнике правды и речи быть не может. 
Любой таск решается так - ты узнаешь какой сандбокс надо использовать, сливаешь исходники, производишь изменения и заливаешь - Profit. Если еще за каждым проектом поднимать CI+git flow, то работа станет точно.
(git в этом случае используется сугубо на чистой инициативе разработчиков чтобы трекать изменения). Я конечно против такого подхода, но по другому никак. Это я к тому что подход СЛИЛ ПРОЕКТ->ВНЕС ИЗМЕНЕНИЯ->СОХРАНИЛ еще долго будет жить в SF и разработчиков которые VF + jQuery еще долго будут востребованы.

[quote="Руслан Курченко"]Я был на проекте где мы на AngularJS все собирали и деплоили с помощью Webpack Plugin при каждой сборке, а сборка была на watch (то бишь при изменении файла)[/quote]
А можно поподробнее?
Это я правильно понял, что на каждый CTRL+S собирался бандл, заливался на Git а из Git CI заливал ВСЕ на Сандбокс?

[quote="Dmitry Shnyrev"][quote="Руслан Курченко"]Я был на проекте где мы на AngularJS все собирали и деплоили с помощью Webpack Plugin при каждой сборке, а сборка была на watch (то бишь при изменении файла)[/quote]
А можно поподробнее?
Это я правильно понял, что на каждый CTRL+S собирался бандл, заливался на Git а из Git CI заливал ВСЕ на Сандбокс?[/quote]

У каждого был свой Dev Org. 
1. Ты делаешь clone с GitHub. 
2. Вносишь локально креды в специальный файла для Webpack config. Этот файл Webpack Plugin будет использовать для деплоя.
3. Запускаешь одной командой Webpack с параметром --watch
4. При каждом изменении (Ctrl+S) собирается bundle (app.bundle.js/vendor.bundle.js). Если сборка успешна (eslint/es6/es7/less) отрабатывает плагин который берет собраный app (app.bundle.js/vendor.bundle.js), создает архив StaticResource, заменяет ресурс в staticresources папке и деплоит через Metadata API на оргу. И ты сразу можешь проверять.

Работает довольно быстро. Если разделить сборку на application/vendor bundles она отрабатывает в разы быстрее, ну а деплой проходит в зависимости от размера приложения. Так же можно включить .js.map файлы для удобного дебага es6/es7 кода. 

Если надо плагин, могу расшарить ссылку.

Ну это собственно стандартный подход к работе с webpack + SF. 
Все примеры (живые и учебные) что я видел так и работают. 
Запускается webpack (вручную или автоматом при сейве) собирается бандл и деплоится в статик ресурс. Ты в это время идешь в SF и перезагружаешь страницу чтобы посмотреть результат.

У меня сборка package + деплой тоже есть (но она запускается только один раз по готовности). 

Минус такого подхода - нельзя работать на одном орге двоим сразу, даже если будут меняться разные части фронтенд логики (чей бандл последний зальется, тот и папа) (не всегда есть возможность создавать отдельные дев сервера под каждый минипроект). Плюс без танцев с бубном весь собранный бандл в один файл может достигать нескольких метров (если не заниматься выносом зависимостей как External) и каждый раз его лить в статик ресурсы то еще удовольствие (пусть и работает это визуально быстро).

[quote="Dmitry Shnyrev"]каждый раз его лить в статик ресурсы то еще удовольствие (пусть и работает это визуально быстро).[/quote]

согласен, вариант не идеальный... у меня была идея использовать ngrok что бы тянуть файлы с локальной машины, при запуске Webpack он запускае ngrok, берет http url полученый с ngrok и обновляет VF страницу. Таким образом ты не деплоишь StaticResource - работаешь локально. Потом по готовности запускаешь комману которая деплоит bundle и обновляет VF, что бы та тянула с SF файлы.

[quote="Dmitry Shnyrev"][/quote]
ngrok - на ходу создает proxy через который можно открыть доступ миру к твоему локальному серверу, в нашем случае это сервер с Webpack 

[quote="Руслан Курченко"]ngrok - на ходу создает proxy через который можно открыть доступ миру к твоему локальному серверу, в нашем случае это сервер с Webpack[/quote]
О! тоже была такая идея, но немного в другом исполнении.
Не помню точно какие решения я рассматривал, но принцип действия аналогичный - запускать страницу из SF как обычно но через прокси. При запросе статик ресурсов они должны были подменяться локальными файлами.
Не знаю ngrok работает по такому принципу или нет. 
Но мне этот вариант не понравился тем что надо сам браузер пускать через этот прокси, а это лишний оверхед, плюс не помню, но были еще какие-то проблемы с решениями что я нашел.

[quote="Dmitry Shnyrev"]
Но мне этот вариант не понравился тем что надо сам браузер пускать через этот прокси, а это лишний оверхед, плюс не помню, но были еще какие-то проблемы с решениями что я нашел.[/quote]

Идея тоже не идеальная, но все же имплементируемая и думаю довольно удобная)
Все можно автоматизировать и будет как часы отрабатывать при запуске одной, двух комманд.
У меня сейчас проект на LCs, так что мне нет когда на такие плюшки время тратить...