Я создал репозиторий, в котором систематизировались результаты обучения за последний месяц, поэтому я подытожил результаты здесь.

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

тайчи/js-шаблон

  • Ветка master содержит минимальную среду разработки JavaScript с примером кода.
  • Ветка frontend содержит среды разработки для веб-приложений React / Redux / webpack.
  • В электронной ветке, ветка по умолчанию, помимо содержимого фронтенд-ветки содержится среда для разработки приложений Электрон.

Введение

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

ci-пряжа-апгрейд

  • Инструмент, который автоматически создает PullRequest, если в проекте с использованием Yarn есть обновление библиотеки зависимостей.

vscode-textlint

Что ж, как видите, хотя я и не слежу за последними версиями JavaScript каждый день, я знаю некоторые из них.

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

Объем контента здесь довольно большой, так как я собрал как можно больше движений за последние два-три года. Хотя я только что сказал вам, что особых изменений не произошло, трех лет вполне достаточно для технологических изменений.

Основные проблемы в JavaScript

С этого момента я собираюсь объяснять знания о JavaScript, которые я недавно изучил, и я заранее перечислил области, которые нужно обсудить.

Это список «Что я хотел сделать и что я могу сделать», упомянутый ранее.

Темы по языку

  • Введение системы типов
  • Темы по статическому анализу

Темы по тестированию

Темы расширенного пользовательского интерфейса

Темы по строительному проекту

  • Управление зависимыми модулями
  • Комплект модулей

Темы на Электроне

Целевая аудитория

Предполагается, что целевой аудиторией этого документа являются программисты, у которых есть первые языки, на которых они могут свободно их использовать. Предпочтительно использовать языки с процессом компиляции, такие как Java и C#.

А также тем, кто интересуется новым JavaScript и тем, кто хочет, чтобы документ был руководством для эффективного обучения.

Таким образом, эта статья не предназначена для тех, кто не умеет писать много кода или не интересуется JavaScript.

Продвинутые разработчики JavaScript не являются теми, кто читает, но будет приятно, если вы укажете на что-то странное или вводящее в заблуждение. Было бы более чем приятно, если бы вы могли сообщить более точную информацию через Твиттер.

Среда разработки

Я использую Windows 10, на всякий случай.

Так как в этой истории мало зависимостей от платформы, неважно, какую ОС вы используете, это не имеет значения; просто чтобы ты знал.

Рекомендую устанавливать Node через nvm-windows. Мне это нравится, потому что вызывает меньше хлопот, чем nodist. Для Mac я думаю, что хорошо использовать nvm. Что ж, я не являюсь серьезным пользователем Mac, поэтому не стесняйтесь использовать другие, если у вас есть более предпочтительные инструменты.

После установки Node также установите Yarn. Даже если вы не знаете, что это такое, не беда. Потом объясню.

Что касается редактора, я построил среду на базе VS Code. Однако, поскольку я не использовал расширения, работающие только на VS Code, воспроизвести подобную среду с другими редакторами несложно.

В .vscode/extensions.json непосредственно под проектом находится список идентификаторов расширений VS Code. Откройте каталог с VS Code, где вы делали git clone репозиторий и подтвердите диалог подтверждения, после чего все необходимые расширения будут установлены автоматически.

Я использую Chrome в качестве браузера для проверки поведения приложения.

Аппаратное обеспечение

Технические характеристики моего ноутбука следующие:

  • Модель Thinkpad X1 Carbon 2016 г.
  • ЦП i 7 6600 U @ 2,6 ГГц
  • Память 16 ГБ
  • Хранилище SAMSUNG NVMe SSD 950 PRO 512 ГБ

Это может быть немного дорого, но это обычно для разработчиков, не так ли?

Мой инженерный опыт

Я начал свою карьеру с того места, где провел около десяти лет «солдатом», который делает корпоративные системы на Java с контрактной системой с SIer. Итак, у меня много знаний о Java, и больше всего я знаю о серверных технологиях в Java.

Хотя теперь я могу писать программы на разных языках, все же эти продукты, такие как Ruby и Python, являются результатом преобразования из странного, уникального, моего собственного языка, очень похожего на Java, который существует только в моем мозгу.

С таким характером я склонен предпочитать среду, в которой я могу легко преобразовать целевой язык в язык, подобный Java, когда я изучаю новые языки, отличные от Java.

В дополнение к этому, поскольку я начал свою карьеру в SIers и до сих пор работаю на них, я очень заинтересован в том, как использовать технологии в разработке систем контрактной разработки и разработке систем пакетов.

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

Пожалуйста, поймите, что эта запись имеет такую ​​предвзятость.

Темы по самому языку

ES5 работает с большинством браузеров, хотя существуют различные среды выполнения JavaScript. Если вы сделаете все возможное на ES5 в первую очередь, вы сможете освободиться от запутанного компилятора (транспилятора), то есть Babel.

Так как JavaScript есть чему поучиться, то сначала стоит подумать о варианте не браться за Вавилон.

Я не мог выбрать этот вариант, не сталкиваясь с Вавилоном. Причина проста; Не хочу много писать function. Как насчет всех?

Я думаю, я должен повторить, что я пришел из Java, и это правда, что я не испытываю никаких негативных чувств к процессу компиляции.

Вавилон — песочница для всех

Разработка языка программирования — работа в одиночестве. До сих пор несколько разработчиков языка тщательно выпускали язык, пока не приобрели форму в какой-то степени.

Однако, по крайней мере, в случае с JavaScript мы узнали из неудачи ECMAScript 4, что он не будет работать таким образом.

Итак, вот Вавилон, где вы можете небрежно реализовать экспериментальные возможности языка в виде его плагинов. Обсудите особенности Предложений нового языка с точки зрения их агрессивного использования и решите, какие функции следует импортировать в следующую версию JavaScript.

Пользователи могут просто попробовать использовать новые интересные функции, просто написав .babelrc. Если функция не лучше, чем ожидалось, или работает нестабильно, вы можете просто прекратить ее использовать.

Приятно добавлять и убирать языковые функции в зависимости от ваших требований.

Модули Вавилон

Модулей для Babel много, но на удивление мало хороших, с которыми стоит покопаться.

Первые два — это модули для настройки окружения, а два других — это модули для работы с другими инструментами.

babel-preset-env

babel-preset-env — это удобный модуль, который автоматически выбирает плагин Babel для использования в сочетании со средой, в которой выполняется исходный код JavaScript, преобразованный Babel.

В экосистеме JavaScript среда выполнения браузеров и Node.js и т. д. постоянно улучшаются, подключаемый модуль Babel, требуемый во время компиляции, соответственно меняется. Хотя даже при активации ненужных плагинов происходит лишь незначительное увеличение времени компиляции.

Тем не менее, это не очень здорово, что вы не можете идти в ногу с последним состоянием, если вы не в сознании.

Использование babel-preset-env избавит вас от такой смелой работы. Просто обновляя модуль на регулярной основе, вы получите новейшую среду, что просто потрясающе.

бабель-регистр

babel-register — это хакерский модуль, который перехватывает require Node и вставляет процесс Babel.

Он не используется для загрузки модулей с производственным кодом, а в основном для запуска тестового кода.

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

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

Чтобы избежать такой ситуации, вы можете полностью автоматизировать процесс компиляции только тех файлов, которые изменились и которые связаны с этими изменениями, перехватив require или import.

Обратите внимание, что тестовый код, который не ссылается непосредственно на тестируемый код, такой как тест типа E2E, иногда работает не очень хорошо.

бабель-эслинт

babel-eslint — это парсер для обработки кода JavaScript, расширенного Babel с помощью ESLint.

ESLint развивался должным образом, поэтому, если вы пишете код на ES и JSX как обычно, вам не нужен babel-eslint.

Причина, по которой это необходимо, заключается в том, что вы используете инструмент для объявления и проверки типа в JavaScript под названием Flow.

Что касается Flow и ESLint, я подробно объясню позже.

babel-plugin-transform-flow-strip-types

babel-plugin-transform-flow-strip-types — это, как следует из названия, модуль, автоматически удаляющий информацию о типах, объявленных для Flow.

После удаления информации для ввода он преобразует написанный код в исполняемый код JavaScript в целевой среде выполнения.

При условии фиксированной спецификации языка без использования Flow, Babel практически не требует настройки. Так что, думаю, не нужно так сильно отталкивать Вавилон.

Система набора текста

Я не буду рассказывать о такой сложной истории. Это история о добавлении недостающего вкуса JavaScript.

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

Если вы за короткое время сами напишете и вызывающую, и вызываемую стороны, вы точно будете знать, что передавать в качестве аргументов. Тогда вы считаете, что нет необходимости их объявлять.

Но я хочу, чтобы вы подумали спокойно. Вы точно такие же, как неделю назад? Могу сказать, что это другое. Хотя я приблизительно знаю, о чем думал, когда писал код на прошлой неделе, правда в том, что я не уверен в деталях.

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

Фракция объявления типа в JavaScript

Давайте немного посмотрим, как объявлять типы в JavaScript.

Компилятор закрытия Google

То, что я впервые работал над объявлением типа при использовании JavaScript, — это система типов Google Closure Compiler.

Если вы кратко напишете объявление типа в комментарии к документу, это проверит типы в коде.

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

С другой стороны, есть проблема, что объявление в комментарии легко проигнорировать. Существует также проблема, заключающаяся в том, что гибкость выражений чрезвычайно низка, а не проста для понимания.

ADVANCED_OPTIMIZATIONS в Google Closure Compiler есть риск, что код вообще не запустится, но я был очень удивлен, потому что размер кода становится значительно меньше.

"Машинопись"

TypeScript появился как одна из многих попыток разработать новый язык как продвинутый JavaScript.

Для меня я думаю, что TypeScript — это своего рода милость от Бога, с признанием того, что это последняя работа Андерса Хейлсберга, который разработал Delphi и C#.

Давайте немного посмотрим на код TypeScript.

TypeScript больше похож на мою собственную Java, о которой я упоминал ранее, чем на оригинальную Java.

TypeScript предоставляет 2 способа написания типов; во-первых, смешивать аннотации типов в коде для работы, а во-вторых, создавать специальный файл для объявления типа. Например, если вы создаете специальный файл, объявите его следующим образом.

Если у вас есть файл с расширением d.ts для объявления типа, вы можете написать код так, как будто в библиотеке есть тип, даже если в нем нет фактического объявления типа.

Крайне важной функцией является возможность иметь типы после установки библиотек без объявления типа, если это необходимо для использования существующих активов.

Проект DefinitelyTyped, который работал над сбором файлов описания типов для модулей OSS в единый репозиторий, был закрыт из-за огромного количества файлов объявлений.

Теперь организация под названием типы управляет ими простым способом, выделяя один репозиторий для одного модуля. Тем не менее, это не означает, что DefinitelyTyped вообще не упоминается.

Кстати, чтобы получить файлы объявления типов из репозитория npm, вы можете сделать npm install -D @types/lodash и т. д. Замечательно, что вы можете получить их с помощью npm, а не с помощью decicated tools.

"Поток"

Flow — это инструмент статического анализа, написанный на OCaml, он проверяет объявление типа, смешанное с JavaScript, и выполняет различные проверки.

Давайте посмотрим немного кода JavaScript, набранного в Flow.

Похоже, это похоже на аннотацию типа TypeScript. Но Flow имеет совершенно иной смысл, чем TypeScript. Flow выполняет статический анализ, например, оценивает аннотацию типа, предоставленную JavaScript, но не создает новый язык программирования.

Это более близкий подход к Google Closure Compiler. Однако, в отличие от того времени, когда создавался Google Closure Compiler, сейчас есть Babel, так что раз вы расширили синтаксис языка в первую очередь и закончили им пользоваться, то можно смело удалять только описание именно для Поток.

Объявления типов, сделанные в комментариях, ограничены с точки зрения выразительности. Флоу справился с задачей. Тем не менее, по сравнению с Haskell и OCaml, он не обладает особой богатой выразительностью, даже по сравнению с Java.

Не так уж сложно понять, в какой степени поток выводит тип. Другими словами, Flow делает только очень простой вывод типов.

Для Flow существует репозиторий под названием flow-typed для обмена объявлениями типа, такими как TypeScript. Я не знаю, почему он будет делать ту же ошибку, что и [Definitely Typed], но он управляет ими в одном репозитории.

Тем не менее, похоже, что PR просматриваются на сервере, а содержимое файла определения хранимого типа является строгим, а их абсолютное количество невелико.

При получении файла объявления типа команда flow-typed автоматически загрузит файлы описания типа зависимого модуля в package.json из репозитория flow-typed. Для тех, у кого нет объявления типа, создается файл объявления типа, в котором все типы объявляются как any.

Почему он не позволяет вытягивать файлы объявления типов с помощью команды npm? Интересно, у него должна быть другая команда, которая создает файл объявлений разных типов.

Какую систему типов использовать

Больше нет причин выбирать Google Closure Compiler.

Поскольку TypeScript и Flow — разные цели, их нельзя просто оценить в оценочном листе. Если сравнивать в таблице Star, TypeScript — это победа.

Ну тогда какой использовать?

Было бы неплохо рассмотреть поддержку библиотек и фреймворков, которые вы хотите использовать.

По крайней мере, если вы используете Angular, TypeScript — это выбор, а если вы используете React, то определенно вы используете Flow.

Существует официальный файл определения типа TypeScript для Vue.js. Однако это не рекомендует использовать TypeScript, кажется, что вклад некоторых пользователей был объединен.

Если вы используете обычный JavaScript, хорошо использовать Flow, а TypeScript — довольно хороший выбор, если у вас есть файлы определения типов библиотеки, которую вы хотели бы использовать. Особенно VS Code, по-видимому, улучшает точность завершения ввода, если у вас есть файлы определения типа.

Кроме того, Поддержка языка Flow также имеет функцию для улучшения завершения ввода.

Нерешенные проблемы в системе типов

Дополнить показания, полученные от экспертов после первого выпуска данной записи.

Дарт

  • Язык, который делает более строгий вывод типов, чем TypeScript.
  • Dart2js умеет конвертировать код в JavaScript
  • Два больших варианта использования Angular2 в Google уже существует
  • Большой вариант использования достигается с помощью Angular2Dart

Давайте поделимся лучшими практиками статического анализа

В JavaScript есть много ловушек. Ловушка здесь заключается в спецификации языка, которую многие программисты склонны неправильно понимать, и в поведении некоторых библиотек. Поскольку JavaScript — действительно гибкий язык, большинство спецификаций нового языка можно преобразовать непосредственно в старый язык. Именно поэтому существует множество ловушек.

Код, написанный в результате ошибок программистов, код, не написанный до тех пор, пока не возникнет непонимание спецификаций, код, который можно считать ошибкой в ​​большинстве ситуаций, и код, который удовлетворяет спецификации языка, но не может дать ожидаемых результатов во время выполнения приложения… Lint — это инструмент для автоматического поиска этих кодов.

Если вы используете Lint немного более агрессивно, вы можете проверить все, что не имеет ничего общего с поведением кода, но с читабельностью кода, например, как делать отступы и как называть переменные.

История Lint в JavaScript

Если вы взглянете на экосистему Javascript, вы найдете множество инструментов Lint. Самый старый из тех, что я использовал, это JSLint. Этот парень — ворс, сделанный легендарным Дугласом Крокфордом, и очень строгий. Это хардкорный инструмент для ворса, который не допускает никаких поблажек. Это больно для неквалифицированных парней, потому что это заставляет нас чувствовать сильную волю автора к тому, что коды, которые могут вести себя странно, должны иметь странный вид, и он никогда не будет введен в заблуждение странным поведением JavaScript.

Кстати, чтение кода JSLint — отличный ресурс для изучения JavaScript. Он компактен и легко читается.

Lint, ставший евангелическим для неквалифицированных парней вроде меня, называется JSHint. Это не слишком строго. Его невероятно легко использовать, потому что он может вырезать файл настроек. Тем не менее, JSHint легко включает и отключает встроенные функции, но добавление нового правила немного проблематично.

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

Вот почему теперь рекомендуется ESLint, который легко расширяется и легко создает файлы конфигурации.

ESLint имеет отличную систему плагинов, поэтому плагинов много, и вы можете опубликовать предложенный набор правил в виде npm-модуля.

Опубликованный Airbnb eslint-config-airbnb является одним из таких рекомендуемых наборов правил.

В Airbnb есть много вещей, которые не соответствуют моей идее, поэтому я не принял ее, хотя.

Модули, связанные с ESlint

Модули, связанные с ESLint, почти все состоят из плагинов.

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

Если вы фанат ESLint и знаете полезный плагин, которого я не знаю, дайте мне знать.

eslint-плагин-ава

В своем проекте я использую тестовый фреймворк под названием AVA. AVA будет объяснено позже.

AVA относительно прост и удобен в использовании, но слишком прост, чтобы понять, как писать тестовый код, пока не привыкнешь.

Итак, использование этого плагина позволяет получать предупреждения при явно неправильном использовании AVA.

eslint-плагин-импорт

eslint-plugin-import находит ошибки вimport операторах.

В частности, если вы попытаетесь import использовать модуль, которого нет в проекте, вы получите предупреждение. Каждый может опечатать название модуля.

В другом примере, если вы передаете строки, отличные от литералов, в require, вы получаете ошибки.

eslint-import-resolver-node

Только у этого есть отличная роль от других модулей.

eslint-import-resolver-node может работать с eslint-plugin-import, чтобы настроить поиск import модулей.

Я имею в виду, что в моем проекте я храню код приложения и тестовый код в отдельных каталогах, src и test соответственно.

В этом случае на стороне тестового кода, когда вы делаете import кода приложения, мне приходится писать import world from '../../src/hello/world";, и это болезненно. Чтобы избежать этого, установив NODE_PATH=src при выполнении тестового кода, нам не нужно писать этот ../../src/part.

Я использую eslint-import-resolver-node, чтобы сообщить об этом упущению eslint-plugin-import.

eslint-плагин-обещание

JavaScript Promise — это тип библиотеки, к которой нужно привыкнуть. Кроме того, трудно понять правильное использование. Говоря о Promise, JavaScript Promise's book — очень замечательный документ, поэтому я рекомендую перечитывать его много раз.

Весьма вероятно, что вы используете Promise неправильно, пока не привыкнете к Promise. Если вокруг вас есть эксперты по JavaScript и вы можете получить от них код-ревью, это очень здорово. Но я пишу немного JavaScript в качестве хобби, я не могу спросить такого эксперта вскользь.

Таким образом, используя этот плагин, вы получите ошибки в явно неправильном коде Promise. Вы можете понять, как использовать Promise, просто прочитав подробности правил этого плагина, поэтому, пожалуйста, постарайтесь внимательно настроить правила.

Кстати, если async/await будут введены в ES, не будете ли вы использовать Promise напрямую?

Я думаю, что async/await и Promise могут сосуществовать согласно моему опыту использования async/await C#, но я точно не знаю, как они в JavsScript. По крайней мере, по моему мнению, использование async/await в AVA делает тестовый код более понятным.

eslint-плагин-безопасность

Вы заботитесь о безопасности при написании кода? Я провожу обзоры безопасности с помощью инструментов статического анализа в качестве работы, поэтому в какой-то степени уделяю этому внимание. Тем не менее, я не всегда, когда есть соображения безопасности в голове.

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

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

eslint-плагин-flowtype

Хотя хорошо набирать декларацию с помощью Flow, иногда вы можете совершить огромную ошибку.

Кроме того, поскольку объявление типа Flow не является обычным JavaScript, стандартные правила в ESLint вообще не применяются. Другими словами, вам нужно переопределить правила для Flow, такие как отступы, проставление точки с запятой в конце строки, удаление замыкающей запятой и т. д.

В самом Flow есть свои ловушки, и если вы объявляете непротиворечивое объявление типа, то лучше их не линтинговать.

Такую же историю я рассказывал на Promise, но eslint-plugin-flowtype хорошо использовать как тренировочную гипсовую повязку, так как Flow — новая технология. Если вы привыкнете к нему должным образом, то никакой ошибки не вылезет вообще.

eslint-плагин-реагировать

В моем проекте React используется как фреймворк для построения пользовательского интерфейса.

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

Все, что определено правилом, не всегда желательно для нашего проекта, но спорить о том, что правилом, гораздо проще, чем создавать это знание.

На самом деле, чтобы получить знания о правилах, определенных в этом плагине, недостаточно просто использовать его в небольшом проекте.

В этом заключается достоинство использования де-факто стандартной структуры.

eslint-плагин-jsx-a11y

Насколько тщательно вы используете Accessibility системы, которую мы делаем?

Я чувствую, что Accessibility имеет более низкий приоритет, чем Security, которым можно пренебречь.

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

Однако прочитать WAI-ARIA 1.1 и страницу ARIA MDN от начала до конца чрезвычайно сложно, если вы собираетесь это делать.

Я надеюсь предоставить максимальную ценность с минимальными усилиями, например, со ссылкой на Доступность HTML5.

Поэтому я рекомендую сначала убедиться, что JSX в проекте использует рекомендуемое правило eslint-plugin-jsx-a11y для работы с поддержкой Accessibility.

Тестирование

Есть разные тесты. Здесь мы говорим о тестировании разработчиков.

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

Для обеспечения качества существуют огромные систематизированные знания, и было бы здорово, если бы разработчики могли приобретать знания как для создания приложений, так и для обеспечения качества, но время ограничено. У них прекрасные семьи или модные игры, в которые можно играть по ночам. Я хочу спать по десять часов в сутки, чтобы жить долго; Я хочу есть вкусные блюда медленно. Опять же, время ограничено.

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

Вот почему мы должны выбрать среду тестирования с максимально простыми API.

То есть это АВА.

Рекомендация АВА

Код теста, написанный на AVA, такой.

  • API маленький
  • power-assert встроен в стандартную комплектацию
  • Более высокая скорость выполнения
  • Идеальная поддержка оператора =>, Promise,async/await, наблюдаемый

API AVA маленький

После импорта с помощью import test from 'ava'; вы можете делать все, что хотите, вызывая функцию, определенную в переменной test.

И есть только 11 функций, включая эту test функцию по умолчанию. Перечислим тех.

  • тест([название], реализация)
  • test.serial([название], реализация)
  • test.cb([название], реализация)
  • test.only([название], реализация)
  • test.skip([название], реализация)
  • test.todo(название)
  • test.failing([название], реализация)
  • test.before([название], реализация)
  • test.after([название], реализация)
  • test.beforeEach([название], реализация)
  • test.afterEach([название], реализация)

Единственное, что нужно иметь в виду, это четыре выделенных API. Кроме того, вы можете обратиться к руководству, когда это необходимо.

Также важно, что AVA не работает с глобальным пространством или функциями, размещенными в неявном this.

power-assert входит в стандартную комплектацию

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

Этот тест генерирует:

Такая ошибка:

Это просто потрясающе!

power-assert переписывает код для выдачи этой ошибки утверждения, но настройка для этого немного хлопотна. Сделать это несложно, и мануалов к нему полно, но хлопотно все равно.

Но, если вы используете AVA, это не требует таких хлопот.

Более высокая скорость выполнения

Когда скорость выполнения теста становится проблемой после выпуска реального приложения и перехода на этап обслуживания.

Во время выполнения какое-то время не имеет значения, составляет ли скорость выполнения 5 секунд или 1 секунду. Но что, если количество тестовых случаев равно 1000 или 10000?

Больше невозможно запускать все тесты на вашем локальном компьютере каждый раз, когда вы меняете код.

Просто запустите тестовый код, который, кажется, напрямую связан с той частью, которую вы изменили, а затем просто закиньте его на CI-сервер, такой как Jenkins или CircleCI, и молитесь с надеждой, что где-то, чего я не ожидаю, не произойдет сбой… Впрочем, как вы ожидаемо, это терпит неудачу.

Поскольку тест всегда регулярно дает сбои, лучше сократить цикл изменения → тест → отладка → изменение ……

AVA спроектирован так, чтобы не рисковать писать тестовый код очень сложной структуры, чтобы обеспечить скорость выполнения теста. Для человека, написавшего тест сложной структуры с помощью фреймворка для тестирования типа Mocha, это может показаться странным, но это дело привычки.

Накопленные переменные области видимости тестового кода — это хорошо при написании, но в конце концов это будет головная боль.

Идеальная поддержка

Просто сказано, что API AVA может быть совершенным, поскольку оно простое.

Так как this не плохо переписан, оператор => работает комфортно.

Поскольку за возвращаемое значение тестового метода определено, что за него отвечает AVA, даже если оно Promise или наблюдаемое или любое другое, AVA сделает это за вас.

Вызовы функций, перечисленные в файлах тестового кода, не будут вложенными.

Кстати, вот как сослаться на переменную, созданную test.beforeEach из test:

context не распределяется между несколькими test, так что вы можете касаться его столько раз, сколько хотите. Однако порядок выполнения нескольких test не гарантируется, если не используется test.serial, поэтому не изменяйте context в test. Во-первых, test.serial не следует использовать, если нет особых причин.

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

Нерешенные проблемы в тестировании

Следующее - это то, что я должен изучить, но я надеюсь, что кто-то дополнит задачи, которые я еще не исследовал.

Тест E2E или системный тест

Мутационный тест

Стресс тест

  • В частности, должна быть богатая методология нагрузочного тестирования пользовательского интерфейса и инструмент, сделанный для него на JS, но я пока не смог его найти.

Как сделать интерфейс

Отсюда я объясню, как создать пользовательский интерфейс с помощью JavaScript.

История библиотек пользовательского интерфейса

Когда я впервые использовал Gmail и Google Maps около десяти лет назад, я был удивлен, как такое высокопроизводительное и богатое экранное выражение может быть реализовано только с помощью JavaScript.

Хотя была группа людей, которые пытались создавать динамические веб-сайты с помощью DHTML, где JavaScript используется для перемещения вещей с помощью JavaScript, в целом они вызывали отвращение.

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

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

Хотя такие библиотеки, как YUI Library, Ext.js, Closure Library появлялись одна за другой, сделать UI, подобный тому, что был сделан с VB и Delphi, было невероятно сложно.

Например, было нереально отобразить управление сеткой так, чтобы каждая ячейка выполняла сложную операцию с отображением около 1000 данных.

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

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

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

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

На самом деле не так-то просто их так легко различить.

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

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

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

Инструменты должны правильно использоваться в соответствующих местах.

Прорыв под названием Virtual DOM

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

Особенно трудно решить проблему производительности. Поскольку он работает в браузере, все элементы пользовательского интерфейса в той или иной форме помещаются в DOM.

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

Чтобы браузер отрисовывал DOM на экране, необходимо каким-то образом сканировать все узлы, поэтому такая низкая эффективность становится большой проблемой.

Кроме того, механизм компоновки элементов рисования, полностью игнорирующий структуру DOM, называемый CSS, снижает производительность.

В мире браузеров это естественно, например, необходимость перерисовывать весь экран с одним атрибутом класса, который появляется в терминальном узле. Другими словами, необходимо заблокировать весь экран только для appendChild только что созданного узла для уже нарисованного DOM.

Однако, если влияние нового узла на весь экран достаточно мало, времени на сохранение блокировок будет достаточно мало.

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

Виртуальный DOM — это технология, решающая эту проблему.

Сначала рассмотрим данные (модель), необходимые для рендеринга экрана и шаблон (представление), в который заливаются данные. Если вы добавите к этому контроллер, который выполняет роль обновления модели с пользовательского ввода, он станет классической моделью MVC.

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

Попробуйте поместить переменную user в первой половине в HTML-подобный шаблон во второй половине.

Обновление модели означает изменение содержимого name и age, которые являются членами переменной user. Примитивным способом программист должен написать код для поиска соответствующего элемента DOM в зависимости от того, какую переменную-член вы изменили. Действительно, в этом простом примере вы можете найти соответствующий элемент, написав $(".name") в jQuery.

Представьте, если на экране тысячи штук изменяемых элементов? Что делать, если какие-то элементы меняются, а есть элемент, который нужно временно менять в зависимости от него? Что, если мой компонент должен быть изменен под воздействием элементов, которых не было, когда я включил компонент в экран?

Это кошмар.

Грубо говоря, виртуальный DOM берет разницу между текущим DOM и следующим выводом DOM и передает только эту разницу механизму рендеринга браузера. Это механизм, который автоматически достигает того, что было сделано кодами, написанными людьми с огромными усилиями. Конечно, это может быть медленнее, чем реализация, в которой высококвалифицированные инженеры выбирают элементы для обновления один за другим.

На самом деле таких редких художников всего несколько, поэтому те, кто автоматически выбирает различия, в целом будут работать быстрее.

Подобный аргумент был примерно во времена языка Си и ассемблера. Если вы собрали вручную все приложения, сможете ли вы сделать двоичные файлы быстрее, чем двоичные файлы, выпущенные обычными компиляторами, или нет? Это в той же логике. Этого нельзя достичь, если объект, который нужно собрать вручную, не ограничен небольшим размером или приложение не достаточно маленькое.

Какой фреймворк использовать

Я составил список фреймворков-кандидатов для использования. В любом случае они используют Virtual DOM внутри.

Реагировать

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

Поэтому я выбрал React в своем проекте.

Существуют также фреймворки, совместимые с React, такие как Inferno и Rax. Если в том, что они делают, есть правдоподобие, это также будет включено в React.

Угловой

TypeScript выбран в качестве основного языка в Angular, поэтому для меня это увлекательный выбор. Однако, насколько я могу наблюдать, сообщество недостаточно велико по сравнению с React. Это связано с тем, что с момента выпуска стабильной версии прошло относительно мало времени.

Текущий Angular — 2.4, но Angular 1.x — мой любимый тип фреймворка. Так или иначе, в Angular 1.x есть 2-сторонняя привязка; есть Директива, где любое действие черной магии разрешено как хранилище мусора, есть контейнер DI. Цикл дайджеста был очень сложной концепцией, но я думал, что сложность должна быть принята, чтобы упростить создание пользовательского интерфейса.

Angular 1.x был фреймворком, который, кажется, существует только для SIer и, кажется, предназначен только для создания бизнес-приложений.

Я думаю, что еще не поздно отказаться от больших затрат на обучение системе Angular 2 даже после того, как будет запущен полномасштабный кейс внедрения внутри Google.

Vue.js

Vue.js — актуальный сейчас фреймворк. Кто, как и я, кто предпочел Angular 1.x, должен выбрать Vue.js.

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

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

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

Это только моя теория о плохом впечатлении, но Angular 2 и Vue.js имеют красоту кодовой базы, которая, похоже, не используется в серьезной производственной среде.

Кстати, кодовая база Angular 1.x вроде бы использовалась в продакшене.

Мифрил

Достоинства Мифрила невелики. Это инструмент для людей, которые могут заметить, чего не хватает, и добавить это самостоятельно после полного понимания внутренних деталей фреймворка.

Поскольку он маленький, вы можете это сделать.

Может подойти для использования в небольшой команде, состоящей только из инженеров с достаточным опытом разработки приложений с графическим интерфейсом.

Заметив, чего не хватает при создании приложения, действительно сложно правильно определить их спецификации и реализовать их. Особенно, когда давление затрат во время продвижения проекта велико, мне интересно, смогу ли я сделать это хорошо. По крайней мере, у меня не получится.

О том, как использовать React

Так как сам React играет роль только для части представления, в создании приложения есть различные недочеты.

Я выбрал react-router в качестве маршрутизатора без особых проблем. Можно сказать, что и у меня нет стандартов по выбору роутеров.

В качестве утилиты для тестирования нельзя не отметить enzyme. Это величайшая заслуга использования стандартной библиотеки де-факто с высококачественными модулями, созданными пользователями, которые в значительной степени внедрили фреймворки.

О Модулях CSS

Другими словами, CSS подобен языку программирования только с глобальными переменными, что представляет собой невероятную среду для программиста, живущего в мире, где областью действия по умолчанию является локальная переменная. Я думаю, что невозможно сделать идеально согласованную работу в среде, где сложность возрастает пропорционально количеству кода.

Что мы имели дело с этой проблемой до сих пор, так это разделить пространство имен, явно определяя соглашения об именах людьми. Например, OOCSS, BEM и SMACSS являются основными соглашениями об именах.

Кроме того, были предприняты усилия для более безопасного написания CSS с использованием метаязыка, такого как Sass (SCSS) или less. Важнейшей особенностью этих метаязыков является ограничение сферы влияния путем вложения определений стилей.

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

Таким образом, желательно, чтобы дизайн компонента React и дизайн CSS были согласованы. Не имеет смысла обращаться с ними как с полностью независимыми вещами.

Чтобы обеспечить согласованность между дизайном компонента React и дизайном CSS, нет другого способа, предшествующего способу любого из них. В таком случае желательно вынести локальные переменные в CSS и сделать их поведением по умолчанию.

Концепции и усилия, разработанные для реализации этого, называются Модули CSS.

Модули CSS — это концепция, полученная от сообщества React, и подобные функции также встречаются в Vue.js. Кажется, в Angular 2 есть аналогичная функция.

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

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

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

React в Модулях CSS

Чтобы адаптировать модули CSS к React, используйте css-loader Webpack для обработки CSS, а затем напишите специальное описание на стороне компонента React. Webpack будет объяснен позже.

Внедрение Модулей CSS

Самый простой способ использования Модулей CSS следующий:

Он будет отображаться примерно так же, как этот HTML. Странное имя класса установлено на атрибут класса, который автоматически генерирует css-loader, чтобы не дублировать.

Проблема здесь в том, что CSS импортируется так, как будто это объект JavaScript.

В этом случае CSS также должен применяться к компоненту во время модульных тестов, которым вообще не нужно оценивать состояние стиля. Если импорт обрабатывается наивным образом, это становится ошибкой, потому что он не может анализировать импортированный CSS как JavaScript.

Трудно писать код с большим количеством фигурных скобок как код, поэтому я также хочу избежать этого, если это возможно. Фигурные скобки набирать сложно, потому что для этого нужно нажать клавишу Shift.

Улучшение с помощью react-css-modules

Существует react-css-modules в качестве модуля для решения проблемы, возникающей при использовании CSS-модулей самым простым способом, упомянутым выше.

Использование этого делает его таким кодом:

Вместо того, чтобы фигурные скобки исчезли, теперь мы импортируем react-css-modules.

Было введено специальное свойство styleName, которое добавляется к атрибуту класса при рендеринге.

Хотя простота кода была улучшена, сложность кода не сильно увеличилась.

В частности, как видно из последней строки, проблема обработки импортированного CSS как объекта JavaScript решена.

Улучшение с помощью babel-plugin-react-css-modules

Есть babel-plugin-react-css-modules как плагин Babel для решения проблемы react-css-modules.

Кстати, разработчики react-css-modules и babel-plugin-react-css-modules одни и те же.

Использование этого делает его таким кодом:

Теперь вы можете не обрабатывать CSS как объект JavaScript. Мы используем операторы импорта только для того, чтобы показать взаимосвязь между CSS и компонентами.

babel-plugin-react-css-modules выполняет необходимые процессы как модули CSS во время компиляции. Благодаря этому код компонента не увеличивается только для Модулей CSS.

Приятно, когда код обновляется таким образом.

Поскольку импорт CSS не влияет на компоненты в коде, удаление такой части с помощью модуля типа ignore-styles не имеет негативных последствий.

Поэтому в своем проекте я решил использовать комбинацию css-loader и babel-plugin-react-css-modules для реализации модулей CSS.

О внедрении Flux

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

Что касается использования Redux, то, сколько ролей и обязанностей дается Actions и ActionCreators, зависит от размера приложения и изменения оптимального решения.

Использование redux-thunk или redux-promise делает его очень простым для понимания, но код ActionCreator имеет тенденцию становиться большим. Поскольку код, связанный с асинхронной обработкой, появляется в Action, необходимо принять меры по установке некоторых критериев и отделению кодов от Action в процессе наращивания кодовой базы.

В очень упрощенном виде redux-thunk реализует действие в модели обратного вызова. redux-promise реализует действие в модели promise.

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

redux-saga и redux-observable — это модули, модель поведения которых достаточно сложна для понимания. Вместо этого код ActionCreator будет проще, а Action будет довольно простым объектом для хранения содержимого произошедшего события.

redux-saga и redux-observable добавляют новый слой с другим именем, но с той же ролью, что и Redux.

Опять же, для простоты redux-saga реализует дополнительные уровни с помощью GeneratorFunction, а redux-observable использует RxJS для реализации дополнительных слоев.

И в redux-saga, и в redux-observable есть способ отмены задач.

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

Что бы я ни пытался оправдать, мне не нравится синтаксис try/catch, который является только допустимым goto. Хотя я пишу это в случае неизбежности, я не хочу писать на опережение.

Вот краткое изложение обсуждения.

Вот почему я выбрал в своем проекте redux-observable.

Нерешенные проблемы в пользовательском интерфейсе

Следующее - это то, что я должен изучить, но я надеюсь, что кто-то дополнит задачи, которые я еще не исследовал.

Темы об удобстве использования в приложении JavaScript с графическим интерфейсом

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

ПостCSS

  • В моем проекте я использую его, поскольку babel-plugin-react-css-modules запрашивает его
  • Это что-то вроде Babel в области CSS, вы можете устанавливать и удалять функции с помощью плагина… это я только понял.

Модуль гибкого макета CSS, уровень 1

  • Насколько я понял, Flexible Box — это сам механизм компоновки приложения с графическим интерфейсом.
  • Материал CSS Flexible Box Layout в MDN прост.
  • Поскольку он находится в стадии разработки спецификаций, он работает только в последнем браузере.

Модуль компоновки сетки CSS, уровень 1

Темы по сборке

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

Непрерывная интеграция (CI) необходима в современном процессе разработки. То есть вам нужно автоматизировать процесс сборки с помощью CLI. Он не изменится, даже если вы разработаете его в среде Windows.

SaaS CI, который я использую, это CircleCI и AppVeyor.

CircleCI используется для сборки в среде Linux. Особенно, когда сборка не удалась, вы можете отлаживать и собирать логи с помощью входа по SSH.

Часто бывает, что результаты сборки не совпадают на CI-сервере, где среда каждый раз очищается, и на локальной среде, где сложены разные вещи.

В частности, в моем случае я разрабатываю в среде Windows, поэтому среда легко отличается от среды Linux на CircleCI. Таким образом, вход по SSH является очень важной функцией.

AppVeyor используется для сборки в чистой среде Windows. Просто немного доработав конфигурационный файл, можно отлаживать и собирать логи по подключению к RDP.

Хотя версия ОС — Windows Server 2012 R2 (x64), я ее не использую, так что разница между ОС сервера и ОС клиента становится проблемой.

Об управлении зависимыми модулями

В Node, основанном на package.json, в котором хранится метаинформация о проекте, он поставляется с инструментом под названием npm, который может выполнять различные задачи.

Особенно самая важная задача, выполняемая из npm, — автоматическая загрузка зависимых библиотек.

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

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

После исправления зависимой версии библиотеки с помощью Yarn, используйте мой ci-yarn-upgrade. Он периодически отслеживает состояние зависимых библиотек и автоматически генерирует запрос на включение для обновления package.json и yarn.lock при необходимости.

О бегунке задач

Написание скрипта сборки, работающего на нескольких платформах, накладывает ограничение, заключающееся в том, что нельзя использовать скрипты оболочки.

Поскольку я пользователь Windows, мне интересно, смогу ли я управлять всеми платформами с помощью PowerShell. Ну, как правило, никто.

Поскольку в проекте используется язык JavaScript, а Node корректно работает на нескольких платформах, предпочтительнее писать скрипт сборки на JavaScript.

Есть много модулей для написания сценариев сборки на JavaScript, но мой план прост.

Использовать глоток или нет?

Действительно, есть таскраннеры вроде Grunt и broccoli.

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

Тем не менее, причиной, по которой gulp можно считать, является его производительность. gulp — это средство запуска задач, которое ставит Node Stream API в центр построения задач и работает на высокой скорости.

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

Кстати, моя любимая пословица, связанная со спектаклем, — Не угадай, измерь!. В этом случае, если причина принятия gulp связана только с производительностью, внедрение не будет поздним, пока кодовая база не станет достаточно большой, а время сборки не станет достаточно долгим.

Итак, в своем проекте я решил максимально постараться со скриптом npm.

Полезный модуль для скрипта npm

Существует несколько полезных модулей для написания сценариев сборки, которые запускаются на нескольких платформах с использованием сценария npm.

кросс-окружение

Это модуль для простой настройки переменных окружения.

Способы определения переменных среды немного различаются между Linux и Windows. Это используется для поглощения разницы. При этом кроме NODE_ENV и NODE_PATH ничего устанавливать не нужно.

npm-run-all

Это модуль, который может вызывать другие npm-скрипты коллективно в npm-скрипте и может запускать несколько npm-скриптов параллельно как отдельные процессы.

Я могу сказать, что танки к этому модулю, вы можете сделать все возможное со скриптом npm.

Например, вы можете использовать его так:

Когда это запускается с yarn compile, поскольку задача compile имеет run-p compile:*, поэтому compile: main и compile: renderer выполняются одновременно.

римраф

Это модуль, который может удалить все файлы и каталоги в указанном каталоге.

Это также используется, чтобы поглотить разницу между Linux и Windows.

О сборщике модулей

Я не использую средство запуска задач, но использую сборщик модулей. Сборщик модулей в JavaScript — это компоновщик компилятора C.

Разделенный на куски по ролям и зонам ответственности JavaScript компилируется в Babel и конвертируется для работы на ES5. На этом этапе размер каждого файла немного увеличивается, но количество файлов не меняется. Вы можете подумать, что просто склеив получившиеся файлы он запускается, но на самом деле это не так.

Мета-языки CSS не работают, если они не скомпилированы. Мы также компилируем метаязыки, такие как Sass и Less, в CSS. Файлы метаязыка CSS часто объединяются в один во время компиляции.

Если вы используете CSS-модули, вам также необходимо последовательно скомпилировать CSS и JavaScript.

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

Как выбрать сборщика модулей

Есть несколько сборщиков модулей-кандидатов, таких как Browserify, Webpack, Rollup, Backpack. Но Webpack — единственный выбор.

Потому что я использую Модули CSS в своем проекте.

Кроме того, потому что я использую React Hot Loader, который сильно зависит от webpack-dev-server.

Хотя Webpack 2.2 был официально выпущен, я еще не использовал его, потому что extract-text-webpack-plugin все еще находится в стадии бета-тестирования.

Поскольку предоставляется довольно вежливый документ миграции, вы можете перенести его, если вам нужно.

Модули, связанные с Webpack

Webpack достаточно большое приложение и его нужно внимательно изучить. Так что думаю много не добавлять.

webpack-dev-сервер

Это сервер для упрощенного запуска продуктов сборки Webpack.

Поскольку он работает на основе конфигурационного файла для Webpack, вы можете запускать приложения проще, чем простой сервер, такой как Express.

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

Кстати, поскольку веб-браузер обрабатывает file:// и localhost специально, при написании приложения, использующего множество новых функций браузера, назначайте правильное имя хоста при его запуске.

веб-пакет-слияние

Файл конфигурации Webpack будет создавать объекты каждые NODE_ENV. Если вы различаете описания, общие для нескольких сред и разные для каждой среды, вам необходимо синтезировать объекты конфигурации.

Этот модуль можно использовать в это время. Вам не нужно использовать его, так как он не особенно продвинут.

вебпак-валидатор

Этот модуль может проверить, правильно ли написан конфигурационный файл Webpack.

В Webpack2 реализованы аналогичные функции, поэтому эти модули не нужны.

Темы на Электроне

Электрон — это фреймворк для создания приложений с графическим интерфейсом, которые работают в нескольких операционных системах. Внутри работают Node.js и Chromium.

Электрон работает на богатой модели, полученной от Chrome. То есть, если у вас нет потоков, запустите процесс Node.js. Процессы запускаются для каждого окна.

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

Существуют различные инструменты такого рода из прошлого. JavaFX, Qt — что-то в этом роде.

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

Зачем использовать Электрон

Для меня это отличная причина, по которой VS Code реализован с Электроном.

Последней работой Эриха Гаммы является VS Code, разработавший фреймворк плагинов Eclipse, которому я посвятил свои 20 лет. Более десяти лет я считал его всемогущим богом, но, прочитав плохой код vscode-tslint, я почувствовал себя немного ближе к нему.

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

Я думаю, что в эпоху GitHub это замечательно, что мы можем небрежно наблюдать за такими вещами.

Возвращаясь к истории, другими приложениями для повседневного использования, в которые включен Электрон, являются GitKraken и Curse, Insomnia, Marp. Клиент Slack для Windows также основан на Электроне, но я им не пользуюсь, потому что он не особенно удобен для пользователя. К вашему сведению, Windows-клиент Kindle — Qt.

Когда-то приложения, пользовательский интерфейс которых далек от нативного интерфейса ОС, вызывали ненависть. В последнее время нативный пользовательский интерфейс ОС и пользовательский интерфейс веб-приложения постепенно сближаются, поэтому дискомфорт приложения на базе Электрона становится меньше.

Последняя причина, по которой стоит заняться Электроном, заключается в том, что в процессе сборки легко создавать исполняемые двоичные файлы, которые запускаются на каждой ОС.

С помощью electron-builder вы немного пишете в package.json и собираете его на CI-сервере, тогда сразу выскочит исполняемый бинарник с установщиком.

Резюме

Наконец, я собираюсь разработать приложение, которое хотел сделать.

Я должен был закончить первый прототип в новогодние праздники, но, возможно, я не оценил свое мастерство, сейчас просто среда разработки на месте.

Я узнал так много вещей, некоторые из них разобраны по причинам.

При подаче заявки возникает что-то вроде родовых мук, и сознание обращается к не принятому на первое место варианту избавления от мук. Я забываю о том, что я урезал и почему, и мне хочется тратить свое время впустую.

Когда я стану собой в таком состоянии ума, я смогу пересмотреть свое мнение, просто немного погуглив и прочитав эту свою запись. Для этого я и написал эту запись.

При обсуждении с экспертами по разработке приложений с помощью JavaScript эта запись будет черновиком, чтобы соответствовать нашему признанию.

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

переведено @ymotongpoo, мой оригинальный пост здесь (японский)