Порядок классов TypeScript в проекте Google AppScript - PullRequest
Новая
       45

Порядок классов TypeScript в проекте Google AppScript

0 голосов
/ 18 января 2020

Предположим, у нас есть 2 простых класса TypeScript в 2 отдельных файлах:

  • B.ts: 
namespace A{
 export abstract class ItemBase {
  id:number=432;
 }
}
  • C .ts 
///<reference path="B.ts"/>
namespace A{
 export class ItemType extends A.ItemBase{}
}
  • и вызов кода в Code.ts: 
///<reference path="C.ts"/>
let a:A.ItemType=new A.ItemType();

Все работает хорошо после нажатия на него с помощью cl asp

Но если я изменю имя файла C .ts на AA.ts, я получу ошибку:

TypeError: Cannot read property "prototype" from undefined. (row 14, file „AA”).

Проблема даже существует если бы я не создавал экземпляр класса ItemType в Code.ts.

Кажется, что ts2gas не учитывает ключевое слово extends во время переноса кода и устанавливает выходные файлы gs в соответствии с порядком файлов ts. Поэтому, если мы назовем файл расширенного класса перед файлом класса, из которого мы расширяем (в алфавитном порядке), мы получим ошибку.

Должен ли я позаботиться о правильном порядке имен файлов ts во время разработки? Должен ли я прикрепить какой-то механизм, который заботится о порядке загрузки файлов GS? Мне кажется, это излишне, пока файлы gs уже переданы. Процесс переноса (ts2gas) должен позаботиться о правильной стратегии расширения класса, которая использовалась в TypeScript. Если ts2gas может преобразовать класс TypeScript в JS OOP, используя прототипы, почему он не может правильно обрабатывать расширения класса?

Я полагаю, есть какой-то более простой и лучший способ.

1 Ответ

2 голосов
/ 19 января 2020

Одной из root причин вашей проблемы является движок Rhino v1.7R3 JavaScript, который запускает скрипт скрипта Apps, и множество .gs файлов, составляющих один скрипт, равны hoisted .

Кроме того, библиотека ts2gas работает, независимо передавая каждый исходный файл, имеет некоторые ограничения и может сыграть незначительную роль в вашей проблеме.

Подводя итог, можно сказать, что ваш скрипт представляет собой объединение всех ваших файлов .gs в том порядке, в каком они были в редакторе скриптов Google Apps. Этот заказ обычно является заказом каждого .gs. При использовании @google/clasp для pu sh ваших локальных файлов в вашем проекте сценария этот порядок, вероятно, изменится на алфавитный порядок ваших исходных имен файлов.

В вашем примере .gs объявляет родителя класс должен появляться перед любым объявлением дочерних классов (т. е. с проблемой подъема)

Чтобы обеспечить правильное упорядочение кода и избежать этого, у вас есть несколько вариантов:

  1. перегруппировать код с потенциалом проблема с подъемом в одном файле (неуклюже и беспорядочно в долгосрочной перспективе)
  2. используйте параметр filepushorder в вашем .clasp.json, чтобы указать, какие файлы должны быть загружены первыми. (легко настроить и поддерживать)
  3. имеет другую цепочку сборки проекта для более точного контроля компиляции Typescript и точного порядка файлов (при необходимости). Вот репозиторий шаблонов У меня есть настройки, чтобы получить запущен.

РЕДАКТИРОВАТЬ

Чтобы проиллюстрировать использование опции filePushOrder, я настроил пример репозитория с вашим примером кода .

...