С чего же начать?

Error: Assert Violation: [object:vm Greeting (1)] cannot be recycled.

Именно такую ошибку увидел я решив взять их хеллоу ворлд пример и сделать следующее:

1. Зарегистрировал компонент Greeting как web-компонент
2. Попытался его использовать в другом компоненте, который тоже хочу экспортировать как web-компонент

Эти действия делались с помощью следующего кода:

// ... code defining element
customElements.define('my-greeting', Greeting.CustomElementConstructor);
// ... code defining other element
customElements.define('my-app', App.CustomElementConstructor);

Идем в google, ищем и находим: https://github.com/salesforce/lwc/issues/1975

Ну да, с июля 2020 по апрель 2021 ничего…

Пространства имен для импорта…

Кто видел провалившуюся задумку майкрософт внедрить пространства имен в TypeScript уже наверняка понимает о чем речь.

1. Пространства имен в целом как идея хороши. Они очень хорошо показали себя в JVM(Java, Kotlin, Scala)/.Net(C#, F#, VB)
2. Пространства имен никогда не были частью экосистемы ECMAScript. Изначально импорты, динамические импорты ориентировались на файлы. Нечто вроде #include <stdio.h> в C. Вспомните все эти разновидности загрузчиков модулей.
3. Это может быть неудобно, многие разработчики это наверняка ненавидят. Но вокруг этого выстроилась целая экосистема со своим пониманием как что-то импортировать. А теперь давайте посмотрим на LWC.

   import 'my/app';
   

WAT?😨

Эта строка подразумевает, что нам в бандл должны попасть следующие файлы:

• modules/my/app/app.ts
• modules/my/app/app.html
• modules/my/app/app.css

Ну да… Я долго был в легком недоумении от декораторов Angular 2+ с их наборами SCSS+HTML файлов вместо импортов рядом лежащего, но там мы оперируем с файлами привычным путем. Здесь же давайте сделаем все несовместимым.

TypeScript и его поддержка

Пожалуй повествование можно было бы закончить словами о том, что в SalesForce будущее видят в Web стандартах вместо массы фреймворков и верят в ECMAScript как единую цель.

Очередной корпоративный фанатизм… Как пример LWC в SalesForce работают строго с ECMAScript. Вот только декораторы еще на момент написания частью стандарта не стали (апрель 2021). Но вот в LWC все на них:

import { api } from 'lwc';

// some code ..
    @api // Standard ?
    set speed(value) {
        if (SPEED_CLASS_MAP[value]) {
            this.animationSpeed = value;
        } else {
            this.animationSpeed = DEFAULT_SPEED;
        }
        this.isAnimating = true;
    }
// some code ...

Это лишь 1 из декораторов. Вышепривиденные неймспейсы к стандартам отношения не имеют.

Ну и как вы понимаете теперь, когда мы увидели, что все заявления о движении в сторону стандартов не более чем очередной bullshit (кто бы сомневался). Давайте наконец поговорим о TypeScript. В open source версии его таки решили поддерживать. Их CLI при создании проекта спросит на чем хотите писать и сгенерирует проект в TypeScript. Молодцы ведь, решили поддерживать как ECMAScript так и эту мерзость не стандартизированную от Microsoft (namespace + decorators мы игнорируем, они “более стандартные”).

Так что, победа open-source версии?

А фиг вам!

У нас включается плагин для бабеля под капотом очередного CLI для сборки от SalesForce, который в очередной раз как и многие другие просто оборачивает Webpack чтоб сделать жизнь “проще”. И этот плагин просто при компиляции удаляет все определения типов.

ЭЭЭ… А как же проверка типов. Я думал, что TypeScript люди используют чтоб баги на этапе компиляции ловить. А это не по стандарту. Нету в веб стандартах ничего про поимку багов на этапе компиляции. Хотели TypeScript? Получите!

Стоп, так не пойдет. Вы же говорите, что там под низом webpack. Давайте сейчас подправим конфиг вебпака и добавим:

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  plugins: [new ForkTsCheckerWebpackPlugin()]
};

Все автор, съел? Все работает. Есть поддержка, просто немного усилий надо. Ок… А вы попробуйте теперь добавить в .ts файл ранее обсуждаемые импорты с пространствами имен внутри строки… Черт, неужели все так плохо?

Да, все ужасно. Этот проект показывает, что из себя внутри представляет большая часть ентерпрайз с их громкими заявлениями и инновационными технологиями. И здесь еще все хорошо. У большинства компаний внутренние разработки это полный мусор от которого пользы нет вообще.

Выводы

Они грустные на самом деле.

1. Если вам необходимо работать с SalesForce, то скорее всего придется разобраться с этим зверьком.
2. В SalesForce все еще есть старый Visualforce фреймворк, который в теории позволяет встраивать любые скрипты написанные на реакте, ангуляре или что еще вам нравится. По ошибкам с веб компонентами я думаю вам должно стать ясно, что в LWC не так уж тривиально подключить внешне разработанный web компонент если хочется писать избегая этот фреймворк.
3. Будущее Visualforce туманно. Так как SalesForce вложили массу денег в lightning и трансформируют свои продукты. С большой вероятностью вас таки заставят перейти на lightning или они породят замену ему, которая будет лучше (не верю) до того как похоронят Visualforce.
4. Если вы не работаете с SalesForce - обходите десятой дорогой и не связывайтесь.