Какова история модуляции для TypeScript в браузере?

Я новичок в развитии браузера, поэтому у меня нет предыдущего опыта работы с AMD, CommonJS, UMD, Browserify, RequireJS и т. Д. Я много читал о них, и я считаю, что обычно понимаю историю JavaScript, но я все еще очень смущенно, как заставить все работать вместе.Какова история модуляции для TypeScript в браузере?

У меня есть библиотека, написанная на языке TypeScript. Это чистая библиотека TypeScript, она не взаимодействует с браузером или какой-либо структурой браузера, а также с любыми объектами или NPM.

У меня также есть клиентское приложение TypeScript, которое использует эту библиотеку. Клиентское приложение также может использовать веб-фреймворк (например, jQuery).

Теперь, когда я скомпилирую два файла TypeScript (которые мы будем предполагать, находятся в отдельных проектах, изолированы друг от друга и построены отдельно), каждый из них будет генерировать .js-файл. В Visual Studio мне нужно выбрать AMD или Common в качестве моего загрузчика модуля.

Здесь разваливаются вещи. Мои исследования говорят мне, что если я хочу работать в Интернете, мне нужно либо использовать Browserify, либо RequireJS. Для просмотра браузера требуется сначала установить узел на моем компьютере, а затем использовать инструмент командной строки в качестве этапа после сборки для создания файла, и, насколько я могу судить, это недоступно в виде пакета NuGet. В качестве альтернативы, я могу использовать RequireJS, но затем все примеры перестают работать. Что-то не в том, чтобы делать что-то на загрузке окна, а вместо этого делать что-то в другом месте, но ничего, что я нашел, действительно хорошо объясняет это.

Итак, что это за история? Я хочу использовать TypeScript, но на данный момент кажется, что это всего лишь язык, для меня не существует каких-либо убедительных историй использования в качестве разработчика, как я привык в экосистеме Microsoft.

источник

2015-03-22 Micah Zoltu

Охват здесь также: https://www.youtube.com/watch?v=KDrWLMUY0R0 – basarat

TypeScript - это надмножество JavaScript, поэтому его история - это история JS, а не .NET или любого другого продукта Microsoft.

Если вы компилируете машинопись модули в AMD, то загружать их через модуль загрузчика AMD как RequireJS (или Dojo или curl) в вашем Entrypoint HTML-файл, который может быть столь же просто, как это (с использованием RequireJS):

<!DOCTYPE html> 
<title>Application name</title> 
<script src="scripts/require.js" data-main="scripts/client"></script>

(при условии, что ваш встроенный модуль Машинописи является scripts/client.js.)

Start page for RequireJS или Dojo Introduction to AMD modules являются ресурсами, которые могут рассказать вам больше о том, как загрузить AMD отформатированных модулей в браузере.

источник

2015-03-22 05:54:39

Если я следую этим шагам, мое событие window.onload не будет удалено. Это событие подключается приложением примера TypeScript, и многие онлайн-примеры подключают это событие. Я считаю, что это связано с тем, что window.onload запускается до того, как RequireJS загрузил мой модуль. Googling предполагает, что мне нужно потребовать domReady (сторонний скрипт). К сожалению, я снова потерялся, потому что я не знаю, как сказать TypeScript, чтобы требовать зависимость от типа TypeScript. Я попытался импортировать 'domReady = require (" Scripts/domReady ")' после загрузки, но это не сработало. –

Если тег '

У вас действительно хороший технический ответ от C Snover, но ответ, который вы на самом деле ищете, «не использует внешние модули». По внешним модулям я имею в виду модули «AMD» или «CommonJS».

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

Просто потому, что внешние модули более сложны, это не значит, что они лучше; сам компилятор TypeScript написан с использованием внутренних модулей.

Вы можете преобразовать внешний модуль обратно во внутренний модуль, опустив любые экспортные инструкции самого модуля (и не имея в конце файла инструкции export =).Например, это внутренний модуль:

module MyLibrary { 
    export class MyClass { 
    public Foo = 1;  
    } 
}

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

<script src="MyLibrary.js"></script> 
<script src="MyUICode.js"></script>

источник

2015-03-23 05:46:46 NYCdotNet

Ваше мнение о том, что «не использовать внешние модули» является полезной рекомендацией, не очень полезно как с точки зрения обслуживания, так и в основном из [PageSpeed - «Сделать веб-быстрее» - разработчиков Google] (https://developers.google.com/speed/pagespeed /). Среди правил большого пальца - минимизация трафика клиентского сервера путем объединения нескольких сценариев и минимизации ресурсов. То, что вы рекомендуете, явно противоречит лучшей практике – xmojmr

Я бы сказал, что при использовании TypeScript вы должны подумать дважды, если вам действительно нужны модули AMD/CommonJS. Компилятор TypeScript обеспечивает действительно хороший способ модуляции кода с помощью внутренних модулей. С внутренними модулями вы получаете файл с одним файлом JavaScript, который можно минимизировать и загружать очень быстро. Чтобы добиться этого с помощью AMD/requireJS, вам в конечном итоге придется втянуть r.js, который скомпилируется в один .js-файл - так же, как это делает TypeScript. Я не говорю, что TypeScript делает AMD/CommonJS устаревшим, но у вас должны быть веские причины выбирать их по внутренним модулям. – Dyna

@xmojmr С уважением, речь шла о модуляции кода TypeScript для потребления в браузере, а не о минимизации или связывании. Мой ответ был правильным на основе заданного вопроса, хотя Дина предложила лучшее описание того, почему.Что касается «явно против лучших практик», два внутренних модуля, объединенных и объединенных в один JS-файл, приведут к меньшему количеству запрошенных байтов и одному меньшему HTTP-запросу по сравнению с библиотекой загрузчика модулей * плюс * тот же пакетный/миниатюрный JS. – NYCdotNet

ТипScript поддерживает AMD и CommonJS так же, как JavaScript. Но дополнительно он также поддерживает internal modules. При использовании внутренних модулей в сочетании с достойной системой сборки, например gulp-typescript, вы обнаружите, что внутренние модули могут охватывать множество вариантов использования, в которых вы бы выбрали AMD/CommonJS в традиционных проектах JavaScript.

TypeScript дает вам свободу самостоятельно решать. Если вам нужна загрузка асинхронного модуля, вы можете использовать AMD через внешние модули. Вы также можете использовать CommonJS и/или использовать browserify, чтобы связать код в одном файле.

Я обнаружил, что, когда вы являетесь разработчиком библиотеки, вы отправляете скомпилированный JS-код, написанный с помощью TypeScript, другим разработчикам - внутренние модули являются хорошим компромиссом. Вы не заставляете вашу целевую аудиторию (разработчиков) использовать какую-либо специальную модульную систему, такую как AMD/CommonJS, но вместо этого отправляете изоморфную JS, которая работает как в браузере, так и в узле. Тем не менее у вас все еще есть способ модуляции кода внутри, так же, как AMD/CommonJS позволит вам.

TL; DR: Когда вы используете TypeScript, вы получаете бесплатные внутренние модули, и они предоставляют вам гибкость, которая может быть достигнута только AMD/CommonJS. Однако внешние модули по-прежнему имеют свои преимущества. В конце концов, вы должны решить, что лучше всего подходит для вашего проекта.

источник

2015-03-23 13:37:16 Dyna

Какова история модуляции для TypeScript в браузере?

ответ

Смежные вопросы