React предоставляет как разрабатываемую, так и производственную версию ссылок на react.js:

Разработка:

<script crossorigin src = "https://unpkg.com/react@16/umd/react.development.js"></script>
<script crossorigin src = "https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>

Производство:

<script crossorigin src = "https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src = "https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

источник

И чтобы узнать, находится ли он в режиме разработки или в рабочем режиме без переменной окружения, вам нужно прямо заявить некоторой переменной, назначив ее режим: (включите следующий сценарий вместе со сценарием реакции)

<script>
var devMode = 'development';
</script>

и при необходимости проверяйте devMode.

В качестве альтернативы вы можете проверить его режим, например: (вы должны добавить идентификатор в тег скрипта)

var script_id = document.getElementById('script-attached-id');
console.info(script_id.getAttribute('src').includes('development'));

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

И последний вариант, я могу подумать о чтении самого файла и обнаружении его режима, поскольку в своем комментарии response упомянул, например:

Разработка:

/** @license React v16.5.2
 * react.development.js

Производство:

/** @license React v16.5.2
 * react.production.min.js

Итак, после прочтения файла просто проверьте его режим во второй строке. Или вы можете протестировать react.development.js без построчной проверки.

Обнаружение сборки dev / production на клиенте с использованием сборки umd кажется долгим. Если такое требование существует, почему бы не создать свое приложение с create-react-app?

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

Плагин react-dev-tools, предоставляемый facebook, определяет тип сборки.

Вот соответствующая часть вышеупомянутого плагина:

https://github.com/facebook/react-devtools/blob/faa4b630a8c055d5ab4ff51536f1e92604d5c09c/backend/installGlobalHook.js#L23

Надеюсь, ты сможешь сделать это полезным.

Есть небольшой «прием», с помощью которого можно проверить, какая версия React была загружена.

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

Чтобы проверить, вы можете сравнить имя функции с именем свойства некоторого метода объекта React, например:

let func = 'Component'
if (React[func].name === func) {
  // non-minified -> development build
}

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

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

Обновлено: Похоже, что невозможно определить версию prod / dev из класса React.

Две идеи:

1. Я не уверен, как создано приложение, но PropTypes должен быть хорошим идентификатором ENV.
2. Если ваше производственное приложение React минимизировано, вы можете просто определить, минимизирован ли код реакции. (это будет взломано, но должно работать, сосредоточьтесь на количестве пробелов или длине строки, ...)

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

Ваш вопрос ясен, но вы не уточняете свою систему сборки, вы используете webpack или parcel? у тебя есть Server Side Rendering или нет? вы запускаете созданное вами приложение с помощью node или pm2? или вы просто создаете свое приложение, а затем помещаете на свою страницу встроенный связанный файл, созданный с помощью других технологий, таких как PHP или C#?

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

Если бы я был на вашем месте, я бы, несомненно, использовал webpack, два файла конфигурации webpack, один для разработки и один для производственного режима. затем я создаю папку, содержащую два файла с config.dev.js и config.prod.js. В веб-пакете разработки:

~~~
module.exports = {
        ~~~
        resolve: {
            extensions: ['.js', '.jsx'],
            alias: {
                ~~~
                Config: `${srcDir}/config/config.dev.js`,
                // srcDir is a defined variable for source directory
            }
        },
        ~~~

В производственном веб-паке:

~~~
module.exports = {
        ~~~
        resolve: {
            extensions: ['.js', '.jsx'],
            alias: {
                ~~~
                Config: `${srcDir}/config/config.prod.js`,
                // srcDir is a defined variable for source directory
            }
        },
        ~~~

И теперь вы можете поместить данные каждого dev и prod для ваших типов сборки. например в вашем config.dev.js можно написать:

module.exports = {
    buildType: "dev"
};

Наверняка в вашем config.prod.js можно написать:

module.exports = {
    buildType: "prod"
};

Абсолютно вы можете получить доступ к данным конфигурации с помощью кода ниже внутри ваших файлов react:

import config from 'Config';

И с помощью этого решения вы можете понять тип вашей сборки при выполнении вашего приложения в реальном времени.

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

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

<script src = "https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.js"></script>

<script>
const reactInfo = {
    version: React.version,
    development: (String((new React.Children.map()).constructor).length > 100)
};
console.info(reactInfo);
</script>

<div id = "content"></div>

Я тестировал это примерно на дюжине версий реакции от v14 до v16. Из здесь вы можете видеть, что этот код не был затронут с тех пор, как он был впервые написан, за исключением одного небольшого изменения, сделанного год назад (что не повлияет на этот ответ, потому что в нем слишком мало символов, хотя я тестировал версии до 11 мес. в любом случае назад и есть приличный разрыв).

Примечание

Dev - это 200 символов, а Prod - 70, поэтому соотношение символов Dev: Prod составляет 3: 1. Я выбрал 100, потому что добавление 90 символов кода добавит 30 строк к продукту, поэтому 100 - лучшее место с предоставленной информацией (технически ~ 105 или что-то в этом роде). Добавление 90 символов или удаление 100 символов крайне маловероятно для такой простой функции (функция, которая затрагивалась только один раз в 5 лет при редактировании 20 символов), поэтому я думаю, что это должно быть стабильно.

Для большей стабильности или, по крайней мере, знания, если он сломается, вы можете проверить, находится ли он в пределах 25 символов от 70 до 200, и выдать ошибку, если это не так. Это должно уловить любые большие изменения (я бы дал этому параметру почти 100% уверенность, что он никогда не скроет ошибку), но вы можете получить ложные срабатывания. Какой из них вам нужен, зависит от вашего варианта использования.

Обновлено:

Что касается минимизации, это регулярное выражение, которое определяет, была ли функция минимизирована, поэтому вы можете безопасно использовать его. Он также выйдет из строя, если React.Children.map не является функцией (почти наверняка никогда не произойдет), что вы можете либо поймать, либо не уловить в зависимости от того, насколько строго вы хотите обработать маловероятное событие ошибки (или просто проигнорируйте его, например, зачем им вообще это менять). Сигнатура функции остается, даже если она минифицирована в [native code], так что это скорее ориентировано на будущее, imo. Хотя для простоты я бы выбрал первый.

const reactInfo = {
    version: React.version,
    development: !/function\s?\w?\(\w(,\w)*\)/.test(String((new React.Children.map()).constructor).split("{")[0])
};

Есть разница. В режиме разработки для элементов React определено свойство _self, тогда как в производственном режиме это свойство не определено.

Итак, решение состоит в том, чтобы проверить это свойство с помощью такого кода:

function ReactIsInDevelomentMode(){ 
    return '_self' in React.createElement('div');
}