Привет всем.
Поделитесь опытом относительно Lightning Components.
Дошли у меня руки них, но что-то сразу все и обломилось.
Как вы работаете (редактируете) код относящийся к Lightning.
Сам сижу на MavensMate и слышал что поддержка появилась в новой версии которая еще Beta.
А также вижу (и сам сталкнулся) что обновление до новой версии приносит много проблем. Благо автор вернулся к старой версии в качестве дефолтной. Короче ММ обновлять не собираюсь (пока).
Попробовал поставить официальную Force.com IDE (на базе Eclipse) (Ностальгия 
) и был приятно удивлен что там тоже нет поддержки Lightning.
А собственно как все собрались с ним работать? Разрабатывать МЕГА-интерфейсы? Через браузер что-ли?
Пока я понял что можно работать (нормально) с Lightning Component в developer console. И в принципе там это организовано очень даже удобно. Особенно порадовала внутренняя организация компонента и быстрая навигация по файлам.
И вот спустя полдня изучения документации я понял что начинаю влюбляться в эту технологию!!!!!!!!!!
Это как раз те же самые одностраничные приложения что я делал с помощью Ractive/Angular+RemoteActions последние полтора года 
Только теперь это все дело стандартизированно! Да и работает вроде красиво. Будем надеяться что глюки будут минимальные.
Единственно не радует стандартная работа с ошибками. Жуть как неинформативны!
Выскакивает окно во весь экран с текстовых сообщением. Ни стека ни даже строки с ошибкой.
И сиди догадывайся что это означает. Надеюсь я просто еще не дочитал доки и все должно быть красиво.
я, пока было время, потихоньку изучил все то новое в СФ, что имеет в названии слово "Lightning" (за исключением редких вещей как Lightning коннект). В общем это четыре независимые, но связанные вещи:
(1)Lightning UX - это новый интерефейс.
(2) Lightning Design System - это бибилиотека стилей, которая используется в новом интерефейсе. Прощай Бутстреп или еще не прощай...
(3) Lightning App Builder - это некий тул для быстрого запиливания страниц\приложений для СФ1.
(4)ну и собственно Lightning Components - это как я понимаю Aura - фронт-энд фремворк заточенный под корпоративные бизнес приложения.
изучал его по банального Трейлу:
https://developer.salesforce.com/trailhead/module/lightning_components
интересны две вещи:
(1) в тех уроках объясняется как это работате, но не объясняется ЗАЧЕМ мы все это делаем, не объсняется сама суть и дух SPA (single page application) приложений. я меня до сих пор с этим пробелы, т.к. я не работал с Ангуляром.
(2) Ауровский лозунг "все есть компоненты", которые могут "сноситься" друг с другом посредством эвентов. такая слегка насильственная "компонентофикация" призвана создать "модульность" и как результат "ре-юзабилити" (многократное использование) создаваемых компонентов (в том чиле в том же Lightning App Builder). это здравая идея.
единственно что по настоящему смущает, это все хорошо, пока оно работает, но как только что-то идет не так, я не знаю что делать, где смотреть, потому что это не нативный JS, в котором многие вещи понятны или можно погуглить без проблем.
в общем, пока это интересная теория для изучения в свободное время
Скажу так, чтобы придти к одностраничным приложениям надо немного помучаться с популярными фреймворками.
Тоже ломал себя некоторое время но потом просто щелкнуло и поперло так сказать.
Самая основная идея - перенос бизнес логики на фронтенд.
Смотрим на основании MVC. В обычном понимании фронтенд это только представление (visualforce), а вся бизнес логика сосредоточена в apex.
Одностраничник - это весь MVC на фронтенде. Тут и представлени и бизнес логика и модели (объекты) - все в JS. Salesforce становится лишь удаленным хранилищем, базой данных не больше (с дополнительной логикой валидации данных).
Я понимаю почему многих SF разрабов это смущает - нафига тогда нужен SF получается. Получается что нафиг не нужен! Его в этом случае можно заменить любым REST сервером!
Вот расскажу об очень плохом примере с которым я столкнулся. Решили делать тоже приложение-одностраничник с мощной бизнес логикой. Но так как разработчиков apex много а фронтенд 1 (даже 0,5) то решили делать так - бизнес логику оставить в apex а visualfore заменить на JS фреймворк. Получилась скажу вам полная шляпа!!!!!!!!! Так как предполагалось что все должно мгновенно считаться и перерисовываться (как и положено всем одностраничникам) на каждый чих со страницы собирались ВСЕ данные и отправлялись на бэкенд для пересчета в бизнес логике, затем возвращались и все перерисовывалось. В итоге получился тот же самый rerender из VF только с кучей костылай на JS + запросами до 3 метров (ограничение Remote Action) который очень быстро кстати достигались (View State limit все-таки не просто так придумали). Теперь представь - ты вводишь в input какое-то число и ожидаешь что остальные пересчитаются синхронно, а нет - на сервер уходит запрос 3 метра и возвращается те же 3 метра в которых изменены 10 байт!!!!!!!!!!!!!!!!
Никогда так не делайте.
Либо это классика с логикой и рендерером на сервере или ВСЯ логика в JS с редкими запросами НЕОБХОДИМЫХ данных!
Не советую использовать данную технологию для серьезных вещей, так как столкнетесь с кучей проблем и поймете, что ее еще нужно дорабатывать и дорабатывать.
Поделки уровня "Hello World" пишутся прекрасно, а примеров с нормальным использованием вообще нет.
Приведу ради примера 2 факта:
- app.js грузится 1 минуту, 1 МИНУТУ, КАРЛ! Кто мне что-то может сказать о скорости работы? Правда, это уже принано известной проблемой и исправится в новом релизе.
- при любой синтаксической ошибке компонент прото не грузится, вы получаете пустую страницу и чистую консоль разработчика без единой ошибки. Это нормально?
И это только 2 примера из рельной жизни. Так что решайте сами, что вам лучше использовать.
Да кстати я согласен - грузится реально долго в начале.
Но как бы одностроничники предполагают что будут перегружаться не часто.
Таких же примеров я видел море на других сайтах - начальная загрузка с прогресс баром а потом сиди и наслаждайся. Хотя по опыту работы с другими фреймворками могу сказать что это в принципе перебор и любую сложную логику можно уместить в пару сотен килобайт и кешировать при необходимости.
Проблему с ошибками я уже упомянул Есть такая проблема. И она у меня возникла УЖЕ на этапе Hello World.
Что можно сказать! Задумка хорошая, согласно современным тенденциям, но реализация подкачала. пока подкачала.
Кстати я тут ранее баловался с Lightning Design System (css фреймворк) на стороннем проекте - хотел сделать красиво. И знаете - плюнул и вернулся к bootstrap, который путем небольшой доработки напильником стал выглядеть точно также к Lightning Design System (но работать стабильнее).
Оказывается проблема Lightning Design System в том что они выбрали за основу flexbox. И я вот не знаю, то ли у них там что-то плохо, то ли у меня руки не так заточены - простейший дизайн страницы мне дался очень сложно и в итоге глючил нещадно!
Но проблема нас как SF разработчиков в том что клиент говорит - "Хочу Lightning". Конечно проще сделать по старинке на Angular или том же React - благо информации море в нете, спецов хватает и работает все стабильно, НО это не Lightning
SF кстати не первый такой в попытке заиметь "свой" фреймворк:
Google + Angular => первая версия провалилась из-за огромной нагрузке при небольшом количестве данных. Сейчас делают Angular2 полностью с нуля.
Facebook + React => Вообще сделали чисто представлени и остальное оставили на откуп разработчикам (назвали Flux и пожелали каждому самому представлять что это такое) - короче кода стало еще больше и запутаннее по сравнению с чистым JS и одним из сотен JS шаблонизаторов.
Мало им, так они еще и JS диалекты свои придумывают (JSX, TypeScript(правда это не их Microsoft)) - программировать становится просто ужасно 
Вот сейчас и SF . Делают свое - посмотрим, получится ли у них что-то c первого раза?
Поделитесь народ, что вы используете в проектах из JS фреймворков или просто библиотек.
Отличная статья в тему для общего развития
Angular 2 против React: И будет кровь
Не ожидал что буду подводить итоги так быстро.
Gres, ты на 100% прав!
Технология абсолютно не готова к проду. Даже не знаю честно к чему она готова.
Попробовал сегодня запилить свое приложение, а не копипастить пример из доков.
Обломался сразу. Несмотря на то что изучил раздел Debug в документации на который возлагал особую надежду.
Код никак не валидируется на этапе компиляции а на этапе выполнения валится абсолютно без какой либо полезной информации. У меня нервы сдали когда в итоге я стал получать Internal Error. И это я всего лишь пытался написать компонент-форму для создания контакта (даже не поленился найти мой любимый смайл который я использую в подобных случаях 
)
С меня хватит!
Все-таки старые варианты с JS фреймворками + Remote Action НАМНОГО проще и прозрачнее в работе. А тут получается пишешь код, распределяешь его по файлам компонента и Надеешься что он заработает. Никогда не думал что "надежда" может быть инструментом разработчика .
вот эту, немного подправленную мной, фразу можно использовать в качестве девиза Lightning Components
но на такой ноте нельзя заканчивать тему. И всё-таки какие положительные стороны, или интересные моменты или перспективу, задел на будущее вы заметили в Lightning Components?
Никаких.
Почему же мне никто не верил)
Как говорится, доверяй но проверяй
Если бы я всем верил, то так бы и сидел на чистом Apex с ЗП 600$.
Как я уже отмечал выше - своим Lightning Salesforce пытается запрыгнуть в общий вагон JS фреймворков. Кроме базовой структуры файлов я не могу что-то отметить в лучшую сторону (хотя данная структура тоже спорный момент и хороша для новичков чтобы стартануть красиво). Так что остаемся пока со "старым" Salesforce.
Кстати, а вспомните Salesforce1! Как громко звучало и как давно было. А кто из вас его использует в продакшене?
Я как-то участвовал в одном проекте где взялись пилить на SF1 мобильный клиент для менеджеров. В итоге одни разочарования и один нанятый Android разработчик + нативное мобильное приложение + SF REST Services сразу решили наши проблемы (проблемы в основном связаны с постоянным доступом к мобильному интернету). Уже спустя столько времени существования SF1 я бы все равно не стал бы его использовать для серьезных решений.
к общим недостаткам переноса программирования на фронт-энд я бы еще отнес недостаток специалистов, кто может с этим работать. Нам, как частным специалистом, может бы и выгодно (видно из фразы Дмитрия выше), то что с фронт-енд разработкой могут разобраться единицы. Но если говорить в целом, то это проблема. Большинство разрабов - это те самые легендарные "штампованные" "JAVA-разработчики", которые могут "копать, а могут не копать" (писать Джаву, а могут не писать ДЖаву), т.е. это все что они могут. Я встречал просто единицы, кто чувствовал себя уверенно с фронт-енд технологиями. А ведь разработка на фронт-енде неизбежно потребует кастомизацию, стилизацию, работу с ошибками... Я не понимаю на что СФ надеется? где найдутся все эти кадры, когда их изначально в ВУЗах по фронт-енду не готовят, а учится новому не многие то любят в реальности, что бы там они не говорили.
Ты прав. Фронтенд разработчики это абсолютно новый класс разработчиков. И знаний здесь должно быть намного больше начального jQuery. Кстати Salesforce в Lightning хочет по максимуму облегчить участь разработчиков связавшихся с фронтендом. Я про их структуру файтов компонента. Там все примитивно - сам html положите в этот файл, js функции положите в этот (причем в определенном виде), стили положите сюда (тоже по особенному). Если следовать строго этим требованиям то думать вообще не надо и с этим справится любой студент. Но в этом и проблема - шаг в право шаг влево приравнивается к выстрелу себе в ногу - тут помогут только ОЧЕНЬ СЕРЬЕЗНЫЕ познания JS и вообще всей области работы кода в браузере.
Вспомню еще случай отличный - работал я долго на одну фирму и пилил отличный продукт. НО! там была одна очень интересная страница которая тянула кучу данных и строила сложную структуру вложенных уровней. Наверное года 3 (если не больше) лучшие умы 2 огромных офисов ломались чтобы оптимизировать данную страницу. Помню сам принимал активное участие - код реально можно было в музей выставлять! Сейчас же спустя пару лет как я активно работаю с JS мне эта задача кажется просто смешной в реализации!
КАК! ПОЧЕМУ за столько лет, столько крутых программистов не додумались сделать все на JS??? (Уже сейчас вроде додумались и сделали на AngularJS по слухам) Понимаю 3-5 программистов, но не 100 же???
Это все говорит о том что ты, Den, что ты хочешь сказать - 90% программистов работают на том что проходили в универе и не считают достойным развиваться. Фронтенду никто не научит!!!!!!
Вот типичный пример - в нашу команду сейчас набирают SF программистов но уже с упором на JS. Но я реально не знаю кого посоветовать. Один человек (Максим привет) который уверенно использует JS как и я уже работает у нас. Но больше реально посоветовать некого :(, даже на примете никого нет.
это не поможет программистам начального уровня. вся прелесть строго типизированных языков в том что система может проверить код на наличие ошибок стадии компиляции, и просто не даст сохранить код с явными ошибками или описками. более того даже дает подсказки в чем ошибка. это уже делает половину работы для программистов.
А вот в JS контроллер пиши что хочешь, все сохранится, а потом гадай, почему оно не работает.
В точку! JS отваливается именно на этапе выполнения и ловить ошибку приходится уже в браузере. Но честно я привык к этому и не вижу особых проблем. Но соглашусь, что порой ловить ошибку приходится убийственно долго. Кстати 
не забываем еще про асинхронную составляющую js, которая тоже может подкинуть много бессонных ночей
Я в очередной раз переписал свой пакет. Теперь все работает на микросервисах. И соответственно очень много логики на клиенте на JS.
Реально почувствовал свободу.
Такое ощущение что вернулся к Perl.
На JS все построенно на обьектах и асинхронных запросах. Пока очень доволен и интерактивностью и отзывчивостью и удобством работы. И возможностью простой работы с динамическими структурами.
Микросервисы вообще хорошая вещь)
О! Отличную тему затронули - микросервисы!
Можно немного подробнее что ты понимаешь под этим в проекции на SF.
Я тоже последнее время загоняюсь архитектурой на микросервисах, но не под SF и пока не вижу как это положить на SF.
Пробовал играться на Go - там эта тема популярна.
НО смысл какой. Есть http server который только принимает и обрабатывает запросы. бизнес логика, асинхронные очереди, работа с мылом, работа с базой данных распределяется по отдельным http серверам. Все общение между этими сервисами ведется посредством http запросов. Но это все равно как бы работает в рамках бекенда и для клиента (фронтенда) так и остается один http сервер как обычно. Просто он получается не моноличный, а как бы из кубиков.
На SF такое сделать пока я не понимаю как - тут нет сервера чтобы запустить кучу микросервисов.
По твоему описанию ты просто перенес всю логику приложения на фронтенд а SF используешь как базу данных. Это ж обычное RIA приложение, но никак не микросервисы.
ок.
микросервес это в моем понимание какой либо функционал, который упаковывается в какой-то метод. Этот метод может быть вызван как из кода так и из внешней системы. Но что самое главное что бы этот метод не влиял на работу других такаих же методов по возможности.
Как это реализовано в SF. Есть вебсервис который, принимает запросы и отдает ответы. Соответственно из арекса можно обратиться к этому вебсерсису или на прямую к методу, если это предусмотренно заранее.
VF использую только для удобства, а так можно было бы все положить в статик ресурс. Все постоенно на AJAX но без стандартного SALESFORCE. В качестве UI выбран jQueryUI по причине минимальных конфликтов в css.
Как по мне достаточно гибко и очень хорошо расширяемо без риска сломать что либо.
Я немного запутался в определениях.
Web Service ты имеешь в виду REST или SOAP или вообще?
А что по поводу API Calls limits? Как они считаются если использовать веб сервисы (особенно внутри SF)
Soap
Я прикинул что 15.000 в день труднолостижимый предел. Если все грамотно сделать.
В принципе это зависит от типа приложение.
Меня вот например эта цифра смущает. Тоже с удовольствием бы пилил бы через web сервисы (Remote Actions все-таки немного ограничены) но по опыту скажу что хорошая страница может генерить много запросов и с даже небольшим количеством работающих пользователей можно влететь в лимиты. А учитывая еще различного рода интеграции боюсь даже представить.
Ну пока что я остановился на таком решении. Если будет выжирать лимиты применю решение греса со страницей. В моей архитектуре это изменение только в одном месте. И не сильно проблемно.
Слушай точно! Вспоминаю было какое-то интересное решение от Gres. Но я совсем про него забыл. Можешь напомнить, или скинуть ссылку где мы его обсуждали?
простая ВФ страница которая возвращает JSON
Gres скинул ссылку
https://github.com/SergeyTrusov/sf-apex-rest-api
Смотрим
Все таки я вижу стоит изучить нормально js фреймворки...
Подскажите на какой обратить внимание в первую очередь.
Смотря для чего он тебе нужен
В данный момент в работе он мне не нужен. Но я думаю что скоро это изменится. Поэтому какой именно я не знаю.
НУЖНО ОБЯЗАТЕЛЬНО!!!
Обязательно нужно попробовать AngularJS от Google! Сейчас выходит 2-я версия (https://angular.io/) - уже в Бета. Тут же к AngularJS надо изучить TypeScript потому что 90% примеров на нем.
Второй в очереди ReactJS. Тоже для общего развития чтобы понимать принципы стоит пройти хелловорлд.
Есть еще куча более старых - например я по работе сталкивался с Backbone.
НО в итоге я пришел к одной малоизвестной библиотеке которая делает все эти фреймворки на раз и решает ВСЕ мои проблемы очень просто RactiveJS. Остальные фреймворки слишком перегружены и врядли получится использовать хотя бы 10-ую часть.
НО Знать надо!
Но в принципе пофиг какой фреймворк использовать - хоть чистый JS.
Кстати я там на одной задаче и делал - почти свой фреймворк - plainJS + Handlebars template engine.
Странно что про них забыли!!! Потому что не было достаточно пиара.
А в итоге например любой JS Template engine это тот же распиаренный ReactJS!!!!!!!!!!!!!!!!
Вот для информации - https://garann.github.io/template-chooser/
Берем любой и вот уже Полный ReactJS (без оверхеда) или пол AngularJS
А, не написал основную мысль!
Пофиг какой фреймворк - ГЛАВНОЕ поломать себя и принять что вся бизнес логики а дата модель может находиться в JS на фронте. А SF становится всего лишь базой данных с продвинутым интерфейсом.
Вот как раз сейчас и надо! Потому что когда придет задача, ты сможешь ее проектировать уже в проекции на JS фреймворк. Иначе придет задача, придет требование и будет тупить. И 100 придешь к неправильной архитектуре!
Для начала почувствуй что такой two-way binding (AngularJS, RactiveJS). Попробуй с этим поиграться и сразу поймешь для чего тебе нужны JS фреймворки
Кстати сегодня вспомнили про очень интересный плюс Remote Actions который может кому-то сильно помочь.
У меня есть одна интересная страница где загружаются различные компоненты (количество динамическое) и каждый компонент выполняет инициализацию через Remote Actions. Так вот получается такая ситуация что после загрузки страницы может уйти сразу 10 и даже 20 (тестировал) запросов к Remote Actions.
И что я заметил - реально в консоли браузера видны 1 или 2 реальных запроса в которых сгруппированы все вызовы RemoteActions.
Я сначала очконул, и подумал что раз один запрос, то и лимиты на этот запрос делятся между всеми remote actions. Но тут ребята из SF молодцы! Каждый запрос выполняется отдельно и затем возвращаются в одном ответе. Экономия трафика и запросов на лицо!
(Чет я подзабыл про этот приятный плюс )
Решение с отдельной VF страницей уже так не сделаешь
Либо придется собирать все запросы вручную и делать общий запрос - тогда лимиты будут делиться на всех, либо дергать N раз страницу.
Когда обращаешься к странице, это не API call, так что это совсем не страшно. Трафик да, вероятно будет больше, но учитывая что все пакуется в zip на лету, не думаю что это существенно.
Дергать страницу N раз не такая уж и проблема, тем более что все это будет происходить параллельно, я думаю даже будет выигрыш по скорости.
Главное не забывайте про возможное количество параллельных ajax запросов в браузере, да и в СФ)
А есть такое? Не слышал.
Эх, вы, спецы по SPA)))
Прикольно! Не знал! Вот откуда ноги растут у решения SF объединять RemoteAction в запросах
Спасибо за инфу.
А самое интересное, что с релизом Spring 16 стали не рабочими все компоненты, реализованные в Winter 16, а также перестал работать Community Builder.
Это нормально?
Думаю вопрос с Lightnig до сих пор актуален. Внесу своих пять копеек.
Вообще главная проблема Salesforce как платформы - это лозунг о том что software больше не нужно с извесным логотипом. Думаю это основаня причина почему инструментарий для разработчиков такой дикий. Вторая проблема вытекающая отсюда же - уровень разработчиков на этой платформе, он зачастую веьсма низкий, и многие толком не могут использовать основы CSS и JQuery, да что там, даже набор компонентов из классики Visualforce. Saleforce позиционирует себя как платформу в которой нужно минимум затрат на разработку и все "типа есть", эдакая каша из топора, которую они хорошо продают) Возвращаясь к лайтнинг компонентам, при всем выше сказанном надеятся на то что Salesforce разработают дейсвительно мощный и удобный фреймворк для разработчиков просто глупо. Когда с ним знакомишься сразу возникает мысль что это не что-то целостное, а какая то каша из всего подряд притянутая друг к другу за уши под шильдиком Lightning. Об этом даже говорят разнородные названия компонентов (aura, force, lightning, ui) скорее всего на ходу притиягивали одно к другому, salesforce1 к Lightning, у компонентов ui одни стили (не SLDS), потом пошли компоненты lightning (с SLDS).
У меня уже достаточный опыт по написанию Lightning компонентов чтобы дать более ли менее объективную оценку. К сожалению назвать этот фреймворк пригодным для быстрого написания приложений нельзя. При чем тут молния до сих пор загадка, если даже элементарное приложение написать в несколько раз дольше чем по старинке. Назвать его фреймфроком для написания одностраничных приложений тоже нельзя, потому что в нем не реализован роутинг, те кто работал с SPA поймут о чем я. Думаю основное назначение Lightnig компонентов - написание небольших форм которые можно встроить в Lightning Page в Lightning Experience (блин столько молний, почему все так тупиит при этом?)))
В общем в Salesforce все так же придерживается линии что разработка не нужна, и если и нужно что-то прикрутить то для этого не нужно делать что-то серьезное, поэтому и инструментарий соответсвующий. О чем свидетельствует даже то что казалось бы есть уже реализованные элементы интерфейа которые есть в Lightning Experience но которых почему то нет в арсенале разработчика, поигратейсь с интерфейсом и посмотрите что есть в Lightning Components Developer Guid. С другой стороны ведь можно же написать свои компоненты, и казалось бы есть большая дока по SLDS и можно на основе нее запилить свои замечательно выглядищие комоненты. Но не тут то было) тут же возникают палки в колесах с рендерингом SVG, это значит что просто взять заготовку из SLDS документации не получится, придестя плясать с бубном чтобы написать компонент для рендеринга SVG, и зменять все включения <SVG> в разметке на этот компонент, либо можно использовать компонент <lightnig:icon> но тут тоже поджидает засада, тогда пример из разметки в документации из SLDS не пригоден для использования, потому что <lightnig:icon> всталяет при своем рендеринге отличную стуктуру DOM от той что в примере, и все вглядит совсем не так, что мы имеем в итоге, в итоге мы не можем использовать SLDS который как бы написан для этого, нам придется допиливать вручную CSS для того чтобы подогнать вид к тому что есть в доке, зачем тогда нам этот SLDS сдался если я точно также глядя на картинку и без него могу CSS написать. Опять же перегруженноть того же SLDS просто дикая, сравните разметку Bootstrap c SLDS, название классов и количество вложенных элментов превращают разметку какой то примитвной штуки в огромный тяжело воспринимаемый на взгляд блок кода.
Но в Salesforce постарались и если вы решите сделать красивый интерфейс в стиле Lighning используя обычный Visualforce, сейчас это можно сделать включив тег <apex:slds> то вас поджидает еще один неприятный сюрприз, да вы можете использовать SLDS и даже SVG отображаются правильно, но если вы сделаете rerender части страницы и в этой части страницы будут элементы с SVG, то они исезнут, все SVG тэги будут удалены. Интересно какой интерфейс можно построить с таким подходом)) В общем с какой стороны не заходи везде ждет неприятный облом. А что вы хотели, софваре же не нужно уже)))
Ок вернемся к разработке самих компонентов, то что писать свои компоненты используя чудо CSS фреймворк SLDS задача кропотливая и трудоемкая я уже описал, но посмотрим что нам предлагают из готового. Думаю один из самых удобных и упрощющих жизнь компонентов из классики - это <apex:inputField>. Ха ха, вы думаете он реализован нормально в лайтниг - НЕТ)) Ну казалось бы как такое может быть, и зачем тогда этот лайтнинг вообще, вопрос вопросов, но тем не менее, попробуйе написать сложную форму с полями находящимися не внутри корневого тега компонента) Далее вторая очень полезная фича из классики - динамическое привзяваение inputField к полю объекта, например <apex:inputField value="{!account['Name']}"/> В лайтниге стандартными средствами это сделать невозможно, и элементарные задачи кода нужно на странице вывести перечень полей ввода заданных например в Fields Set превращаются в целое испытание, потому что придется парсить метаданные полей и вручную генерить то или иное поле в зависимоти от его типа.
Ок рассмотрим сам код, если в Ангуляре есть двустороннее связваение и многие вещи для нас протекают незаметно, то тут нам нужно генерить избыточный код состоящий из строк типа: var ourVar = component.get('v.ourVar'); component.set('v.ourVar', 'someNewValu'); Если атрибутов много то код на половину состоит из этой хрени, засоряя восприятие логики, плюс обращение к переменным через 'v' часто может приводить к проблемам, потому что судя по оптыту часто забываещь написать 'v.' перед именем переменной, и компилятор даже в разметке не выдает никакой ошибки.
Далее на счет структуры, рассмотрим пример: нужно написать компонент таблицы с записями, на каждой строке должна быть кнопка для удаления записи. В принципе проестенькая задача и копмонент, но не расслабляйтесь вам для ее решения придется написать еще один компонент, потому что возможноти передать в обработчик id записи в лайтниге нет и для таких случаев придется для кнопки или для все строки пиасть еще один компонент в обязательном порядке, а если на уровне таблице после удаления нужно еще делать какое то действие поле удаления, то придется еще создавать объект-сообщение, котрое будет отправлять кнопка "удалить" таблице, а в той регистрировать событие и приписывать обработчик. Гибкость и интсрументарий разработчика по сути ограничивается конструкциями сomponent.find(...); component.get(...); $A.util.addClass(...); $A.util.removeClass(...); Это практически весь арсенал!
В общем после разработки на лайтнинге я понял что им пользоваться очень некомфортно, и для сложных задач он малопригоден, по этому пришел к выводу что оптимально использовать один из современных JS фреймворков. Я остановился на Angular2 c Angulr CLI. Сейчас думаю над тем как оптимизировать процес разработки и сдлеать удобный деплоймент. Локальную разрабоку можно делать без деплоя, подключаясь по REST, для деплоймента можно заменить REST вызовы на RemoteAction вызовы. Перечислятm плюсы можно очень долго) это и удобная локальная реалтайм разработка, и обилие информации, сборка Anular CLI, защита авторского кода (после минификации код разобрать неозможно), бест практис в разработке и т.п. В качестве UI я выбрал ng-lighning - отличная библиотека для Angular2 с копмонентами которые на порядок удобнее чем в Lightning. По сути у разрабочика появляетя мощнейший интсрументарий для разработки приложений выглядящих как Lighning, разработка которых превращается в улвекательное и перспективное занятие.
А вот и нет,они уже выпустили значок перечеркивающий предыдущий.... я так понял что они собираются сделать кросс плаформенность в SF через Heroku но это еще долгая песня.
Это какой значек что перечеркивает?
А можно поподробнее? Чет пока звучит как полный бред.
плаформенность вообще подразумевает дескторные приложения, web и heroku тут вообще никаким боком.
chameleon, низкий поклон за отзыв.
Наконец-то хоть что-то аргументированное!!!
Хороший и правильный отзыв
А еще один сюрприз хотите?
Этим тегом подключится какая-то совсем старая версия SLDS, а не последняя или даже предпоследняя.
Если не хотите работать с заброшенной глючной версией, то придется грузить вручную в статик ресурс.
А теперь еще один мега облом.
если раньше можно было скачать zip архив с последней версией SLDS и сразу залить его в статик ресурс, то сейчас zip архив (SLDS 2.4.3) больше 5 метров. То есть придется садиться и вручную удалять оттуда лишнюю хрень чтобы впихнуть в 5 метров
Мля, ну как так то???????????????? Для кого тогда этот архив делали?
Ну и еще ложка дегтя - помните namespace generator чтобы пропатчить slds под свой неймспейс? В нем можно выбрать тоже не самую последнюю версию. Последняя недоступна.
Истину глаголишь.
Я сейчас с Vue проектом покончу(разочаровал он меня) и вернусь на Ангуляр2.
Как раз сейчас под Vue есть такой инструмент и он очень себя классно зарекомендовал.
Разгребусь с текущими задачами и хочу интегрировать его с Angular CLI.
O! Спасибо за ссылку.
Но я бы все-таки советовал самому под себя сделать такой набор компонентов.
Сложного там ничего нет, зато будет возможность быстро подправить или расширить логику компонентов.
Уже не раз практика показывает, сторонние решения ничего кроме головной боли в длительной перспективе не приносят. Я наверное уже раза 4 пилил такие наборы компонентов под разные сочетания css и js фреймворков.
А то вот как недавно случай был интересный по использованию готовых решений. Timepicker вроде вещь нужная, но мало где он реализовал вообще или реализован нормально. Под Vue есть такой набор готовых элементов - Element. Так там timepicker поддерживает только 24 часой формат времени (китайцы по ходу не знают что бывают другие) и плюс Datepicker не поддерживает momentjs (ну я не знаю это наверное уже стандарт де-факто который как jQuery только для работы с датами). И таких нюансов куча.
Лучше один раз написать свой набор компонентов и радоваться жизни.
!!! Я бы вообще вынес твой коммент chameleon в отдельную тему.
chameleon, спасибо за отзыв, всё верно подмечено!
По поводу удаления строк из таблицы, в name кнопки или иконки можно положить индекс строки или айди записи и получить в хендлере клика кнопки: var index = event.getSource().get('v.name')
<lightning:buttonIcon iconName="utility:event" variant="bare" name="{#index}" onclick="{! c.handleNewEventClick }"/>http://www.lightningstrike.io/ - более менее нормальная реализация SLDS компонентов на lightning component, есть свой CLI для установки на орг с зависимостями.
Вывод 1 - lightning components только для простых UI, которые нужно встроить в lightning layout, quick action
Да можно через атрибут задать, но это все методы в обход "идеологии" и они старательно заркывают доступ к DOM элементам из контроллера, и это в целом правильно, потому что по идее оперировать нужно данными, просто нужно предоставить разработчику гибкие решения а не 5 методов не все про все)
Ок, спасибо)
Да конечно можно свои написать но все же на это нужно много времени, на мой взгляд эта библиотека предотавляет необходимый минимум, остальные можно легко добавить делая по аналоги или используя готовые как основу, главное это то что они качественно написаны, с хорошей докой с работающими примерами. Даже глядя на примеры можно почувствовать разницу Лайтнинг фреймворка и Ангуляра, преимущество очевидны, в целом умение разрабатывать на Angular или React для SFDC разработчика хоть и необязательное требование но дающее колосальное преимушество, по сути разработчик становится ни чем не ограничен имея у себя мощнейший инструмент.
Вот ссылка если кому интересно:
Очень интересная штука, спасибо за ссылку!
Был я одном мероприятии суть его сводилась к тому что Salesforce одумалось и начало поддерживать девелоперов.То есть,как нам объяснили это было на закрытой части прошлогодней DreamForce.Отсюда ноги скрач оргов растут и прямые итеграции с гитом и CI. А насчет кросс платформенность как я понял там будут созданные контейнеры которые позволят запускать свои аппы на любом языке подобных руби или Java прямо в Salesforce. Презенташку жалко не смог найти.
Спасибо за пояснение. Это крайне интересные новости. Хотя с другой стороны учитывая сколько уже времени SF владеет Heroku, и ничем нам не радует что возможно ждать еще придется не один год.
