HERO_APP_SECRET_CODE=abcdef npm start

Добавление переменных среды разработки через .hero-cli.json

Переменные окружения могут различаться в зависимости от среды, такой как development, test или production. Можно указать информацию о сопоставлении в файле .hero-cli.json, чтобы hero-cli загружал соответствующие переменные в переменные окружения.

Например:

Вот содержимое файла .hero-cli.json:

{
  "environments": {
    "dev": "src/environments/environment-dev.js",
    "prod": "src/environments/environment-prod.js"
  }
}

А вот содержимое файла src/environments/environment-prod.js:

var environment = {
    backendURL: 'http://www.my-website.com/api'
};

module.exports = environment;

Когда вы запускаете команду hero start -e dev или hero build -e dev, все переменные из src/environments/environment-dev.js можно получить через process.env.

Проксирование запросов API в разработке

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

/             - статический сервер возвращает index.html с React-приложением
/todos        - статический сервер возвращает index.html с React-приложением
/api/todos    - сервер обрабатывает любые запросы /api/* с помощью бэкенд-реализации

Такая настройка не требуется. Однако если у вас есть такая настройка, удобно писать запросы типа fetch('/api/v2/todos') без необходимости перенаправлять их на другой хост или порт во время разработки.

Чтобы сообщить серверу разработки проксировать любые неизвестные запросы к вашему серверу API в процессе разработки, добавьте поле proxy в ваш файл .hero-cli.json, например:

{
  "proxy": {
    "/api/v2": "https://localhost:4000",
    "/feapi": "https://localhost:4001",
  },
  "environments": {
    "dev": "src/environments/environment-dev.js",
    "prod": "src/environments/environment-prod.js"
  }
}

Таким образом, когда вы выполняете fetch('/api/v2/todos'), запрос будет проксироваться на http://localhost:4000/api/v2/todos, а когда вы fetch('/feapi/todos'), запрос будет проксироваться на https://localhost:4001.

Скрипты сборки

hero start

Запускает приложение в режиме разработки. Вы можете запустить hero start -h для получения справки.

Эта команда имеет один обязательный параметр -e. Использование: hero start -e <env>

Доступные значения <env> берутся из ключей, настроенных в атрибуте environments в файле .hero-cli.json.

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

Вы можете использовать -p, чтобы указать порт прослушивания при запуске приложения.

hero start -e dev -p 3000

После успешного запуска страница перезагрузится, если вы внесёте изменения в папку src. В консоли вы увидите ошибки сборки и предупреждения линтера.

Дополнительные параметры

• -e
  Имя среды конфигурации при запуске приложения
• -s
  Собрать пакет как автономную версию, которая должна работать в среде Native App. То есть собрать версию без библиотек, таких как полифиллы веб-компонентов или hero-js (Эти библиотеки необходимы для работы Hero App в браузере, а не в Native App).
• -i
  Встроить JavaScript-код в HTML. По умолчанию [false].
• -b
  Собирать пакет только с зависимостями, такими как hero-js или webcomponents, без кода в папке /src. По умолчанию [false]
• -m
  Сборка без исходной карты. По умолчанию [false], будет создана исходная карта.
• -f
  Создать файл AppCache, имя файла по умолчанию — «app.appcache». По умолчанию [false], файл создаваться не будет.
• -n
  Переименовать файл без хэш-кода. По умолчанию [false], вызывает имя файла с хэш-кодом. Сборка приложения (hero build)

Собирает приложение для продакшена в папку build. Опции аналогичны упомянутым выше в разделе hero start, или вы можете запустить hero build -h для получения справки.

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

Эта команда имеет один обязательный параметр -e. Использование: hero build -e <env>.

Доступные значения <env> и правила загрузки конфигураций такие же, как у hero start (см. раздел hero start).

Сборка для относительных путей

По умолчанию hero-cli создаёт сборку, предполагая, что ваше приложение размещено в корне сервера. Чтобы переопределить это, укажите значение атрибута homepage в файле конфигурации .hero-cli.json. Возможные значения см. в Webpack#publicpath.

Например:

Содержание файла .hero-cli.json:

{
  "environments": {
    "dev": "src/environments/environment-dev.js",
    "prod": "src/environments/environment-prod.js"
  },
  "homepage": "/mkt/"
}

Затем вы сможете получить доступ к start.html по URL /mkt/pages/start.html. Это позволит приложению Hero правильно определить корневой путь, который будет использоваться в сгенерированном HTML-файле.

hero init

Вы можете запустить hero build -h для получения помощи. Он создаст начальную структуру проекта приложения Hero. См. раздел «Создание приложения».

Hero — это не просто фреймворк для разработки, это целая стратегия разработки

Управление процессом разработки

Новые требования к фреймворку можно отправить в каталог hero-js/test/test/unit_test/, конкретное содержимое представляет собой файл JSON, например:

    {
        class:"MyLabel",        //имя нового элемента функции
        p1:"xxxxx",         //какие параметры принимает новый элемент и каков результат
        text:"Hello hero !",
        size:22,
        frame:{"w":"1x",h:"80"},
        alignment:"center"
    },

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

• Тестирование на основе тестов, поскольку любые новые функции могут быть запущены только после того, как будут созданы тестовые случаи, это изначально тестирование на основе тестов.
• Автоматизация тестирования на всех платформах, например:

Анализ поведения пользователей

В рамках Hero существует концепция, согласно которой на странице не должно быть никакой логики, страница (view controller\activity\page) отвечает только за отображение элементов, элементы сами по себе принимают только данные JSON, а то, как выглядит интерфейс, полностью определяется полученными данными JSON. Кроме того, сама страница имеет только функции in и out, которые соответствуют обратной связи данных от элементов и передаче данных элементам. Мы перегружаем эти две функции в JavaScript и отправляем данные на сервер журналов. Таким образом, мы можем узнать обо всех действиях пользователя и полностью воспроизвести их.

Hero — это больше, чем просто фронтенд-фреймворк

Основная идея Hero заключается в том, что каждый функциональный элемент имеет и имеет только один интерфейс для обмена данными с внешним миром. Я однажды написал инструмент для обнаружения отношений между классами в обычном проекте, метод заключается в поиске списка классов текущего проекта, если класс содержит классы из другого списка, то он увеличивается на 1, результаты таковы: для 50 классов среднее значение составляет около 200, для 100 классов среднее значение составляет около 800, и это число растёт пропорционально квадрату. Можно представить, насколько сложно новичку разобраться в большом проекте, это как огромная сеть. Традиционное объектно-ориентированное программирование, возможно, само по себе не является проблемой, но оно сталкивается с огромными трудностями в реальной практике, функциональное программирование — это один способ, а Hero — другой. На стороне сервера Hero также имеет первоначальную, но полную практику, каталог находится в hero-js/server. Здесь я не буду вдаваться в подробности.

Технический комитет Hero

Вклад кода

Отправьте код на GitHub по адресу: https://github.com/dianrong/Hero, https://github.com/dianrong/Hero-ios, https://github.com/dianrong/Hero-android.