React: Узнайте, как поощрять пользователей не отправлять режим DEV в рабочую среду

Для справки: https://github.com/facebook/react/pull/8782

Для контекста мы уже предупреждаем, если обнаружим, что вы минимизировали версию React для разработчиков: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98.

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

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

Я также хотел бы предложить один console.warn, если renderToString вызывается в режиме разработки. Очевидно, что в большинстве ситуаций renderToString вызывается в узле, где мы не можем предупредить или вызвать диалоговое окно DOM.

К сожалению, мне бы очень хотелось иметь возможность определять не только то, установлено ли для NODE_ENV значение production , но и то, было ли process.env.NODE_ENV скомпилировано. Кто-нибудь знает способ сделать это?

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

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

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

Альтернативой является то, что мы находим способ исправить это на уровне инструмента сборки/ENV, как упоминалось в исходном посте. Это позволит избежать необходимости внедрения DOM.

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

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

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

Анекдотично: в прошлом предупреждения в консоли оставались незамеченными (или игнорировались). У меня нет точных цифр, но я думаю, что консольных предупреждений недостаточно. Я согласен с @addyosmani в том, что предупреждение на основе DOM будет иметь большое значение.

@surma , возможно, им следует использовать console.warn или console.error для лучшей видимости 😉

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

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

Мы могли бы вызвать такую ​​ошибку для этого предупреждения.

Честно говоря, я не думаю, что console.{error,warn} за console.log что-то изменило бы. Как я уже сказал, эта история анекдотична.

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

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

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

Что касается сообщения, введенного в DOM, его можно отключить с помощью глобального или чего-то еще. Ничего страшного, ИМО. Если вы отключите его, вы как бы признаете, что знаете, что делаете.

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

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

Честно говоря, я не думаю, что console.{error,warn} поверх console.log что-то изменило бы.

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

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

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

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

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

Что касается сообщения, введенного в DOM, его можно отключить с помощью глобального или чего-то еще. Ничего страшного, ИМО. Если вы отключите его, вы как бы признаете, что знаете, что делаете.

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

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

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

Логично, я понимаю мотивацию.

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

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

Однако, если мы заставим его показывать сообщение по умолчанию в продакшне как критическое изменение (в 16 или 17), то его будет сложно пропустить. Я имею в виду, что это произойдет при первой попытке развернуть его (для новых пользователей), а существующие пользователи должны читать примечания к выпуску при обновлении до новой основной версии. Так что я думаю, что это выполнимо, если мы очень четко об этом говорим, и невозможно пропустить сообщение.

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

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

Однако, если мы заставим его показывать сообщение по умолчанию в продакшне как критическое изменение (в 16 или 17), то его будет сложно пропустить. Я имею в виду, что это произойдет при первой попытке развернуть его (для новых пользователей), а существующие пользователи должны читать примечания к выпуску при обновлении до новой основной версии. Так что я думаю, что это выполнимо, если мы очень четко об этом говорим, и невозможно пропустить сообщение.

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

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

Предупреждение, видимое на странице, может:

• Сообщите разработчику, что сайт находится в режиме разработки
• Ссылка на документы о преимуществах и о том, как отправлять без нее
• Ссылка для отключения сообщения на… не знаю 2 часа?

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

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

Если бы я впервые увидел это предупреждение (вставка в DOM) в продакшене, я бы сильно расстроился. Предупреждения должны быть сделаны заранее.

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

@jakearchibald извините за путаницу, мой ответ не был адресован вам. Я просто хочу указать в ветке, что если мы будем использовать решение «вставить в дом», мы должны быть очень осторожны и убедиться, что пользователи знают, прежде чем они что-то нажимают (как-то так, у меня нет хорошей идеи здесь) .

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

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

Вещь, которая просто поразила меня, если бы можно было иметь какой-то флаг в браузере, который вы должны включить, чтобы активировать devtools (может быть, большой оверлей в них с «Вы разработчик? [Да/Нет]» ), которые страница может обнаружить и показать предупреждение только разработчикам. В правильной формулировке это может помочь и при атаках self-XXS.

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

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

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

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

@рторр

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

Почему? (я не говорю, что вы не правы, просто хотелось бы услышать ваши доводы)

Возможно, добавление настройки для определения домена prod. Если prod Domain не установлен, мы всегда получаем предупреждение о режиме DEV (с запросом на установку URL-адреса домена), если он установлен, мы получаем предупреждение только тогда, когда URL-адрес совпадает с prod-доменом. Мы могли бы даже привязать любой сервис, о котором хотим уведомить разработчиков.

Я рад, что здесь есть конструктивная дискуссия. Здесь есть два решения, которые я вижу для решения проблемы. Webpack может принудительно указать NODE_ENV, который React затем может использовать, чтобы избежать отправки DEV в PROD, но это было бы критическим изменением для Webpack. Сейчас я говорю с Шоном о том, насколько осуществимым может быть что-то подобное для Webpack 3. Сохранение стека React + Webpack для новичков и производительности — это то, о чем, как я знаю, заботятся оба лагеря.

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

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

@jakearchibald

Почему? (я не говорю, что вы не правы, просто хотелось бы услышать ваши доводы)

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

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

@rtorr https://twitter.com/sebmarkbage/status/820054247496503296

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

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

@jakearchibald

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

Когда сайт запустили, кто-то принял решение, что он "готов", так что пока плохо, это не катастрофа. Однако, имея (возможно, я не знаю точных цифр) сотни тысяч разработчиков, вынужденных отклонить разрушающий сайт (предупреждение DOM следует рассматривать как предупреждение, поскольку вы понятия не имеете, как оно взаимодействует с остальной частью сайта). а если сайт юзабелен с видимым предупреждением) предупреждение пять или даже раз в день - это катастрофа. У большинства разработчиков правильно настроена цепочка сборки (пользовательская, create-react-app или другая), и им вообще не нужно это предупреждение, им нужно иметь возможность избавиться от него.

@dan-gamble Я считаю, что разработчики, не использующие React Dev Tools, являются самой срочной целью для этого предупреждения.

@Pajn Потенциально, я не думаю, что только потому, что вы загружаете расширение Chrome, оно автоматически заставляет вас осознавать переключатель prod / dev.

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

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

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

Даже делать это каждые 2 часа ? Нет, спасибо. Такое постоянное нытье, безусловно, отпугнет пользователей от разработки в React, и я искренне думаю, что это оттолкнет людей от перехода на другие фреймворки. Может быть, этого хотят разработчики Chrome?

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

Что мне больше всего нравится в React, так это то, что он ничего не делает, пока вы не вызовете ReactDOM.render(...) , и когда вы это сделаете, он только поместит материал в DOM, куда вы ему сказали. Вот почему это такая хорошая, изолированная, функциональная библиотека.

Нужно ли нам также определять, отправляют ли люди неминифицированный пакет? Что, если они не кэшируют, когда должны? Что делать, если они не настроили nginx оптимальным образом? Или не использовать shouldComponentUpdate , когда нужно? Или без необходимости визуализируют все, когда им это не нужно?

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

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

Что касается веб-пакета, заставляющего настройку NODE_ENV (возможно, в их репо уже есть проблема с этим), не затруднит ли это использование библиотек, которые не зависят от настроек env?

Или идея в том, что он обнаружит использование NODE_ENV и заставит его использовать только в том случае, если код использует его?

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

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

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

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

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

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

@jakearchibald Спасибо за рациональный ответ на мой эмоциональный ответ. Я действительно думаю, что есть много причин, по которым сайт может работать медленно с React. Я хотел бы увидеть, как мы можем предложить улучшения производительности, которые лучше, чем грубая проверка режима разработки и предупреждение в браузере. Если бы у нас были инструменты для анализа приложения React и предоставления серьезных предложений по производительности, от всего, например, режима разработки до слишком большого количества повторных рендерингов, это было бы намного полезнее. Подобный общий инструмент можно подключить к любому конвейеру, будь то веб-пакет, браузер и т. д.

Это главное, что я хотел сказать: несколько дней я буду использовать режим разработки React в 5-10 разных местах, таких как jsbin, туториалы и даже создам небольшой тестовый сайт и открою его с помощью протокола file://. Принудительное предупреждение в браузере враждебно к такой гибкой разработке, в которой Интернет так преуспевает. Я буду видеть эти предупреждения повсюду, потому что я изучаю React в разных доменах в Интернете.

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

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

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

Вы не можете полагаться на localStorage для дедупликации этого. Нет никакой гарантии, что localStorage (или любые другие локальные постоянные данные) не будут очищены через какой-либо интервал.

редактировать : Кроме того, отображая ошибку только один раз каждые {INTERVAL} , вы теперь значительно усложнили ее воспроизведение и отладку, поскольку она не воспроизводима детерминистически.

Необходимо решить 2 случая:

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

Аргументы против прикосновения к DOM убедительны.

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

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

Я сомневался насчет https://github.com/facebook/react/pull/8782 , потому что людям обычно не нравятся предупреждения, от которых они не могут избавиться (см. https://github.com/facebook/react/issues/ 3877), но с учетом альтернатив это может быть приемлемым решением.

Любопытный. Будет ли использование localStorage вызывать закон о файлах cookie ЕС на сайте, на который он не распространяется?

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

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

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

Заставляет меня думать, что расширение react devtools может быть использовано для отображения уведомления или чего-то очевидного при открытии страницы с использованием реакции в режиме разработки, может быть?

@sebmarkbage

Если информативные предупреждения во время разработки — это хорошая идея, то почему другие библиотеки этого не делают?

Думаю, кто-то должен быть первым. У Angular похожая проблема, когда такие вещи, как http://code.gov , запускаются в режиме разработки. Если React начнет ловить эти вещи там, где другие фреймворки этого не делают, я буду настаивать на том, чтобы они внесли аналогичные изменения.

Я буду настаивать на том, чтобы они внесли аналогичные изменения.

@jakearchibald вы предлагаете, чтобы каждый фреймворк выдавал собственное предупреждение? Я не думаю, что установка стандарта для фреймворков/библиотек, предоставляющих свои собственные предупреждения о разработке в производственной среде, — отличная идея. Разве мы не должны пытаться стандартизировать платформу? Как упоминалось @sebmarkbage

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

Я думаю, что это отличная идея. Прецедент: Safari имеет отдельный режим, который необходимо включить для доступа к DevTools. Если бы Chrome сделал то же самое, он также мог бы безопасно добавить индикатор для режима DEV и API для его запуска. Этот индикатор будет виден только разработчикам, чтобы не нарушать работу пользователей.

Не потребуется ли время, чтобы разработчики браузеров реализовали такие вещи?

@jide да, но правильно решить эту проблему важнее, чем быстро. Кроме того, его можно реализовать в одном браузере до принятия мер по стандартизации (при необходимости).

@aweary

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

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

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

@gaearon Что касается Chrome DevTools, мы провели мозговой штурм живого «API нарушений», который авторы веб-платформ и фреймворков могли бы использовать для подачи важных предупреждений. Они будут представлены где-то вроде предстоящего обновления панели «Аудит». Это звучит похоже на ваш запрос и может использоваться для срабатывания предупреждения об обнаружении режима DEV.

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

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

Предупреждение DOM кажется не только проще, но и эффективнее.

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

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

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

Браузеры пошли на многое, чтобы не показывать инструменты разработки на странице.

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

Предупреждение DOM кажется не только проще, но и эффективнее.

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

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

@addyosmani , если это лучшее решение, я не понимаю, как это может быть проблемой. Любые изменения в React будут в основном выпуске, который, я думаю, подлежит уточнению, поскольку сроки выпуска в любом случае идут.

Принятое решение потенциально повлияет на все дальнейшее развитие. Вопрос недель против месяцев в этом контексте является приемлемым ИМО.

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

@aweary : Если сайт, ориентированный на безопасность, когда-либо запустится в DevMode, ему нельзя доверять, пока он не исправит проблему. «DevMode» может включать в себя все виды ярлыков, связанных с безопасностью, таких как отключенные проверки CORS или открытый исходный код шаблона и т. д. Если сайт ориентирован на безопасность, это _не должно_ происходить.

(Я понимаю, что «DevMode» имеет очень специфическое значение в React, но я пытаюсь принять здесь точку зрения не разработчика)

@aweary

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

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

Скорость — не единственное, что может негативно повлиять на пользователей.

Я не вижу, чтобы кто-то утверждал обратное? Мне очень грустно от такой реакции 😞

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

@jakearchibald это довольно странный вывод, я не думаю, что проводил бы здесь свое свободное время, разговаривая с вами, если бы я не хотел, чтобы это было исправлено? То, что я не согласен с вашим решением, не означает, что я смирился с тем, что оставлю его нерешенным. Это действительно несправедливо.

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

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

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

Режим @surma dev по своей сути не является небезопасным, но, тем не менее, он переступает черту, предполагая, что вы можете сообщить об этом пользователям.

Я не думаю, что решения, требующего открытия или включения инструментов разработки, достаточно. Чтобы его заметили, он должен быть виден QA, руководству и, возможно, конечным пользователям. Разработчики слишком привыкли к этому. Подобно тому, как выделяются проблемные конфигурации ssl. Это не должно быть много, но достаточно, чтобы было заметно, что кто-то спросит об этом, а затем исправит.

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

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

Нам нужно выяснить, как по умолчанию обрабатывать ошибки в React, что может не позволить сохранить DOM на месте. Текущая реализация по умолчанию в мастере удаляет содержимое React из дерева, если возникает ошибка. Это тоже инвазивно.

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

Подобно тому, как выделяются проблемные конфигурации ssl.

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

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

Как насчет включения режима DEV?
Мы ошибаемся в сторону «хорошего UX», потому что плохой DX легче заметить (и, ИМХО, в таких вопросах пользователи должны «выиграть», потому что они не могут выбирать, а разработчики могут).
Я уверен, что некоторые фреймворки уже делают это (например, Relay, если я правильно помню).

Предложения по реализации:

• включить режим разработки, только если для NODE_ENV явно задано значение development
• включить режим разработки, если глобальный __DEV__ равен === true
• экспортировать модуль инструментов отладки для включения в пользовательской среде

Первый кажется лучшим, потому что два других могут быть жестко запрограммированы без защиты (например, оператора if(NODE_ENV === 'development') ) и, таким образом, в любом случае будут отправлены в производство.

@mattecapu Смотрите мой второй комментарий относительно. https://twitter.com/sebmarkbage/status/820047144677584896

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

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

Я не большой поклонник кнопки, которая отключает предупреждение DOM на определенное время в одном конкретном браузере. Как отмечает @jlongster , разработчикам очень тяжело, если это происходит часто. Но что еще более важно для меня, это вводит изменчивость поведения браузера, что может легко привести к невоспроизводимости ошибок «но на моей машине это работает нормально».

Я бы предпочел параметр, отправленный для рендеринга, в котором перечислены домены, которые считаются блоками разработки, со значением по умолчанию ["localhost", "127.0.0.1"] . Это будет выглядеть примерно так:

React.render(<App/>, 
  myDiv,
  () => { console.log('finished render!'), 
  { devDomains: ["localhost", "devbox.mycorp.com"] }
);

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

• Использование dev build на локальном компьютере с использованием localhost или 127.0.0.1 : никаких предупреждений разработчика и никаких действий разработчика не требуется.
• Использование dev build на машине dev с другим именем хоста : вы получаете предупреждение DOM до тех пор, пока не добавите доменное имя в список, переданный в render . После этого вы никогда не получите предупреждение DOM.
• Использование сборки dev на рабочей машине : вы получаете предупреждение DOM, пока не переключите React на рабочую версию.

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

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

Редактировать : неважно, я вижу, предупреждение DOM все еще находится в разработке.

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

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

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

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

Большинство пользователей не любят веб-приложения, если они знают, что это веб-приложение, почему? Потому что ранее распространенный менталитет веба заключался в том, что когда он появляется на экране, он готов, независимо от того, насколько плохо он себя ведет и пользователи узнают, что веб плохой. Однако вполне возможно создать отличный UX в Интернете, но для этого я должен владеть DOM. Если кто-то вставляет случайные баннеры в произвольные места, неправильный элемент может начать прокручиваться, или это может привести к перерисовке всего экрана при прокрутке, или это может помешать, например, жестам перетаскивания или чему-то еще. Дело в том, что пока этот баннер висит, я не могу развиваться, потому что я не могу знать, что опыт будет таким же, когда этот баннер исчезнет.

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

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

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

Я думаю, что @ropilz коснулся этого ранее в ветке со своим комментарием «_.. мы могли бы даже связать любую службу, о которой мы хотим уведомить разработчиков .._», но это могло остаться незамеченным (или не подтверждено).

Насколько я понимаю, основная проблема, решаемая здесь,

• каким-то образом предупреждать _разработчиков_, когда рабочие _конечные пользователи_ сталкиваются с сайтом, работающим в режиме разработки
• мы не можем полагаться на то, что разработчики увидят сообщения console.log (или даже предупреждения DOM, если на то пошло) в рабочей среде, _если_ эти разработчики сами активно не используют рабочий сайт (или мы полагаемся на конечных пользователей, QA/ группы поддержки и т. д., чтобы сообщить об этих предупреждениях разработчику)
• существуют (действительные) аргументы UX _против_, показывающие конечным пользователям видимое предупреждение DOM, предназначенное для аудитории разработчиков.

Что, если бы было что-то похожее на CSP report-uri , чтобы фреймворки могли отправлять предупреждения режима разработки, а не отображать предупреждения на месте на сайте, где они были бы видны конечным пользователям?

Очевидно, что есть ряд вещей, которые следует учитывать, например:

1. Такая отчетность в идеале должна быть включена по умолчанию, но какой будет report-uri по умолчанию? (будем ли мы ожидать, что каждый фреймворк будет размещать свой собственный бесплатный сервис, аналогичный https://report-uri.io? (это _возможно_ возможно для крупных фреймворков, спонсируемых компаниями, таких как React и Angular; но, безусловно, нецелесообразно для небольших фреймворков с открытым исходным кодом). как Preact, Vue и т. д.)
2. Как уведомляется владелец/разработчик сайта после получения предупреждения? (возможно, это хороший способ для тех, кто не является разработчиком, принять участие в проекте, вызвавшись добровольно отслеживать эти отчеты и помогать отслеживать/уведомлять сопровождающего?)

Я полностью признаю, что это предложение является всего лишь мысленным пузырем, и я не рассматривал, насколько это практично или как это будет работать на самом деле; но я хотел поднять его, так как мне кажется, что проблема «отчетности о производственных проблемах» уже частично решена для отчетов CSP/HPKP, и, возможно, мы могли бы изучить что-то подобное здесь?

Важно сделать шаг назад и понять, что React — это фреймворк. Вы не должны :

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

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

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

В обязанности React не входит присматривать за разработчиками. Я предлагаю либо:

1. Включите режим разработки. Когда разработчики поймут, что они не могут что-то отладить, они будут искать, как это включить (что должно быть везде задокументировано). Нет, это не работа React, чтобы сказать им, чтобы они отключили его. Их проблема.

2. Оставьте это простому сообщению console.log (и это должно быть отключено). Пусть разработчики найдут и разберутся. Если они этого не сделают, да ладно. Вы не можете проникнуть в каждую организацию и заставить их действовать правильно. Это просто не масштабируется.

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

Разработчики используют так много библиотек, которые, вероятно, имеют собственный режим разработки. Я думаю, что установка process.env.NODE_ENV на production уже стала общепринятым стандартом при связывании модулей для браузера. Это то, что нам нужно улучшить осознание.

Я согласен с тем, что документы React явно не показывают, что существует разница между сборкой для разработчиков и производственной сборкой. Когда вы открываете документы, вам нужно просмотреть расширенные руководства , чтобы прочитать разницу между сборкой для разработчиков и рабочей сборкой. Заголовок Optimizing Performance — то, что новички точно не заметят, потому что они используют React, потому что слышали, что это быстро. Я думаю, что документацию можно было бы улучшить, чтобы в разделе « Быстрый старт » была другая документация под названием «Использование React в производстве» или аналогичная.

Новички обычно не читают Расширенные руководства, но они откроют некоторые ссылки в разделе «Быстрый старт», если заголовок достаточно ясен и выглядит важным. Я знаю, что делал, потому что именно так я и поступаю, когда начинаю изучать React. Я не читал руководство по началу работы, но прочитал несколько страниц в разделе «Быстрый старт».

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

http://code.gov запущен, несмотря на предупреждения консоли. Это именно то, что мы должны стремиться предотвратить. (Этот сайт Angular, но то же самое относится и к React)

Вот проблема для code.gov, если кто-то хочет связаться с ними (или отправить PR): https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

Я никогда раньше не использовал Angular 2 (что делает меня новичком в данном случае). Моя первая реакция после того, как я увидел предупреждение, — я просто пытаюсь вызвать enableProdMode() . Это не работает. Я думаю, что консольное сообщение для случая Angular можно было бы улучшить. Вместо того, чтобы полагаться на магию, они должны указывать на документы.

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

Я не против показа предупреждения пользователя, когда разработчики делают «ошибки», но вставка случайного элемента DOM просто навязчива. Мне нравится, как браузеры справляются с проблемой HTTPS, когда браузер имеет специальный пользовательский интерфейс, чтобы показать, что сайт небезопасен. У нас нет статуса, связанного с производительностью. Учитывая растущие опасения по поводу производительности веб-сайтов в целом, я не понимаю, почему производитель браузера не придумал способы сообщить пользователю, что сайт, который он посещает, отстой.

Это следует решать на уровне инструментов, поэтому, возможно, webpack и Babel могут уведомить разработчиков о преимуществах установки NODE_ENV.

@pveyes Согласен, я сказал то же самое команде Angular.

@matthewp есть гораздо более старая проблема с этим https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 , и команда Angular связалась напрямую и дала им исправление - кажется, есть мало желания применять. Вопрос в том, сделает ли предупреждение DOM это исправление более срочным или предотвратит его запуск в режиме разработки с самого начала?

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

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

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

Я не уверен, как работает процесс развертывания на code.gov, но если это что-то похожее на то, что я испытал в качестве государственного подрядчика, то случайное развертывание в режиме разработки в рабочей среде:

1. Принудительный полный откат всего развертывания (некоторым из них требуется 6 месяцев, чтобы получить одобрение и объединить все, от изменений пользовательского интерфейса до обновлений серверного программного обеспечения), вероятно, на следующий день, затем вы проводите встречи и последующие документы относительно того, что произошло и планирование нового окна развертывания (вас снова и снова будут спрашивать, были ли сценарии или службы БД или что-то еще в режиме разработки из-за одного предупреждения в пользовательском интерфейсе). Я видел, как это происходило с очень незначительными вещами. Иногда вы можете получить исключения, но YMMV.

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

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

Предупреждающие сообщения будут более заметны, когда #7360 (желтое поле) будет объединено. Мы также можем добавить сообщение в желтое поле (назовем его «Предупреждения режима разработки React»?).

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

Это прямо на странице установки:

https://facebook.github.io/react/docs/installation.html#development-and-production-версии

И об оптимизации производительности:

https://facebook.github.io/react/docs/optimizing-performance.html#use-производственная-сборка

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

Когда вы открываете документы, вам нужно просмотреть расширенные руководства, чтобы прочитать разницу между сборкой для разработчиков и рабочей сборкой. Название — «Оптимизация производительности», на что новички точно не обратят внимания, потому что они используют React, потому что слышали, что это быстро. Я думаю, что документы можно было бы улучшить, чтобы в разделе «Быстрый старт» был еще один документ под названием «Использование React в производстве» или аналогичный.

Вот тут, на самой первой странице (Установка):

https://facebook.github.io/react/docs/installation.html#development-and-production-версии

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

На самом деле я не новичок в React, поэтому, когда я открываю документы, чтобы проверить свое предположение — что документы React не являются откровенными о prod vs dev — я не открывал документы по установке 🙇

Не беспокойся. Если это недостаточно заметно, я открыт для предложений по лучшему размещению. Например, мы могли бы создать для него специальную страницу ( Deploying to Production ).

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

Единственный реальный способ решить эту проблему — обнаружить и уведомить.

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

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

Я бы сказал, что правильное место для хуков — это не Chrome или Firefox, а скорее webpack, Browserify или Rollup.

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

@taion Согласен. Я думаю, что это определенно относится к инструменту сборки, а не к DOM.

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

Если npm run build запускается в терминале, а среда не настроена на производство, вы должны получить красное предупреждение в терминале вместе с выводом по умолчанию: env is not set to production, some scripts may be in development mode

В настоящее время я не получаю такого предупреждения от webpack.

Изменить: добавлено уточнение

Или просто установите для себя NODE_ENV.

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

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

@jakearchibald Я уверен, что некоторые все еще будут игнорировать его, но, по крайней мере, предупреждение будет показано им, когда они его создадут, а не невидимо, потому что предупреждение скрыто в консоли браузера, которую они могут никогда не открыть в процессе производства. . Самое главное, это дает тем, у кого меньше опыта, представление о том, что они должны делать, чтобы подготовить код.

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

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

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

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

@taion Как человек, поддерживающий решение только для сборки, считаете ли вы, что это важный вариант использования?

Что думают другие люди?

Я думаю, что в документации довольно ясно, что вы должны использовать пакеты .min.js для производства. Может быть, он мог бы использовать жирный шрифт, больший размер шрифта, что-то в этом роде. Но если кто-то использует неминифицированный пакет React в производстве для своего веб-сайта, у него все равно есть другие проблемы.

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

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

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

Я думаю, что конфигурация CDN+dev явно неверна, поскольку требует от пользователя использования неминифицированной сборки React. Таким образом, сложнее потерпеть неудачу, потому что бремя знаний, необходимых для _просто использования мини-сборки_, ниже.

Конфигурация, в которой вы _думаете_, что все готово к производству, потому что вы запустили минификацию в webpack или Browserify, но на самом деле это не так, потому что вы не установили NODE_ENV — вы не можете получить это через пакеты CDN.

Я думаю, что вкладки React на Chrome Developer Tools достаточно, чтобы сказать, находимся ли мы в DEV Mode .

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

http://symfony.com/blog/new-in-symfony-2-8-redesigned-web-debug-toolbar

Хотя, насколько я могу судить, я не думаю, что это включено по умолчанию.

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

Чтобы попытаться немного переформулировать проблему:

• Ненулевое количество сайтов React попадает в рабочую среду без отключения режима разработки.
• Мы хотели бы уменьшить это число
• Мы не хотим раздражать разработчиков React
• Мы не хотим отталкивать новичков от React
• Мы не хотим, чтобы конечные пользователи сайтов, созданных на React, видели предупреждения разработчиков.
• Мы не хотим ломать сайты из-за наличия посторонних DOM-элементов

Учитывая это, я думаю, что достойным первым шагом для React в режиме разработки было бы объявить, что он находится в режиме разработки, через console.warn или console.info с инструкциями, чтобы убедиться, что это отключено для производства. развертывание.

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

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

Это не неправильно , если он находится в режиме разработки, хотя, когда вы... разрабатываете. Какие еще эвристики мы могли бы использовать?

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

Это не неправильно, если он находится в режиме разработки, хотя, когда вы... разрабатываете. Какие еще эвристики мы могли бы использовать?

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

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

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

Извините, что звучит как застрявшая запись, но предупреждения консоли, похоже, не работают. Например https://code.gov.

Извините, что звучит как застрявшая запись, но предупреждения консоли, похоже, не работают. Например https://code.gov.

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

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

@jakearchibald

Да, но если бы инструмент сборки code.gov был настроен с хуками здесь, то это _предотвратило бы проблему, которую вы наблюдаете, по крайней мере, в контексте React, который использует для этого хуки во время сборки. В конце концов, они используют веб-пакет.

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

Хотел быстро ответить на более раннее замечание от @addyosmani о «нарушениях» DevTools. Мы создаем прототипы , показывающие более сильные признаки определенных ошибок в Chrome DevTools, но эта работа еще довольно ранняя, и я склонен согласиться с @jakearchibald в том, что отображение предупреждения (даже если оно страшнее, чем console.warn ) не является достаточно хорошее решение.

Как насчет установки React по умолчанию в производственный режим и включения режима разработки тогда и только тогда, когда NODE_ENV == 'development' или имя хоста равно localhost / 127.0.0.1 ? Большинство разработчиков получат правильное поведение «из коробки», и всегда будет способ вручную принудительно включить режим разработки, если вам это действительно нужно.

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

Кстати, -p (режим «производство», который также включает минимизацию с настройками по умолчанию) в webpack 2 устанавливает NODE_ENV для пользователей: https://webpack.js.org/guides/production-build /#узел -переменная-среды.

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

Кстати, -p ("производственный" режим, который также включает минимизацию с настройками по умолчанию) в webpack 2 устанавливает NODE_ENV для пользователей: https://webpack.js.org/guides/production-build/#node -environment-variable.

Ага. Мы знаем об этом. @TheLarkInn из ядра Webpack может точно подтвердить, но я понимаю, что -p не широко используется в банкомате сообщества Webpack. Основная проблема здесь также заключается в том, что если какое-либо решение будет добровольным, как и текущий статус-кво с предупреждениями console.log, мы вряд ли увидим реальные изменения для пользователей React. Мы хотим дать людям больше возможностей для доставки «быстрых» вещей.

Попутно стоит упомянуть, что отсутствие возможности легко обнаруживать среды DEV и PROD в Webpack (недостаточный -p) также вызвало у нас некоторую боль в https://github.com/webpack/webpack/issues/3216.

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

Я за то, чтобы мы занимались этим, но, насколько я могу судить, это было бы серьезным изменением для Webpack. Я лично считаю, что решение во время выполнения, которое включает в себя четкое оверлейное сообщение, отображаемое _только_ с использованием нескольких интеллектуальных эвристик (localhost, открытие DevTools и т. д.), будет адекватно охватывать нас.

Тем не менее, поскольку мы продолжаем возвращаться к элементу Webpack process.NODE_ENV, мне было бы любопытно, есть ли у @sokra или @TheLarkInn какие-либо мнения по этому поводу.

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

Даже известные пакеты используют -p для создания производственных сборок:
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

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

Я лично считаю, что решение во время выполнения, которое включает в себя четкое сообщение о наложении, отображаемое только с использованием нескольких интеллектуальных эвристик (localhost, открытие DevTools и т. д.), будет адекватно охватывать нас.

Я чувствую, что это было сбито несколько раз («Для фреймворка неприемлемо внедрять вещи в DOM»), на самом деле не оценивая _only_ сценарий, в котором это могло бы произойти.

Я полностью согласен с вами в том, что необходимость иметь дело с постоянным сообщением и неожиданными вещами в DOM постоянно во время разработки неприемлема. Однако здесь мы предлагаем сообщение, которое отображается, если и _только_ если DevMode развертывается в рабочей среде (введите эвристику!). Произвольное количество проверок и консольных сообщений может быть встроено в инструменты, CI и расширения браузера, чтобы предотвратить это.

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

отображается тогда и только тогда, когда DevMode развертывается в рабочей среде (введите эвристику!)

Таким образом, разработчик никогда не увидит это сообщение, развернет (возможно, случайно) режим разработки в рабочей среде и вдруг увидит, что этот новый HTML отображается в их приложении для всех их пользователей?

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

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

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

Да, если кто-то выполняет развертывание в режиме разработки в рабочей среде, он должен иметь возможность это увидеть и быстро изменить. К сожалению, особенно за пределами технологической отрасли, это просто невозможно или непросто . Большинство людей, комментирующих здесь? Скорее всего, в их компаниях есть процессы развертывания, которые прекрасно справятся с этим сценарием. Google, Facebook, PlayStation и т. д.; все эти технологические компании могут справиться с этим, но это не репрезентативно для большинства пользователей, использующих React, верно? (на самом деле, есть ли у нас статистика использования React? Было бы удобно!)

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

Давайте возьмем два сценария, в которых я лично испытал.

Во- первых , во время работы в правительстве, в зависимости от филиала и отдела, вы, вероятно, выполняете одно развертывание каждые 3-6 месяцев. Эти развертывания объединяют как можно больше вещей, и если какая-либо часть всего развертывания дает сбой, все может быть отброшено. Итак, мы использовали это программное обеспечение под названием OWF, которое, если вы не знакомы, похоже на iSocial в том смысле, что оно отображает несколько веб-приложений в одном веб-приложении с использованием iframe (грубо, я знаю, но оставайтесь со мной здесь). При развертывании нескольких наших приложений произошел сбой ручной настройки, что привело к отображению ошибок 404 и 500 в некоторых фреймах вместо предполагаемого приложения.

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

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

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

@КрисСигель

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

Мне было любопытно, если бы ваши мысли о подходе отличались, если бы сообщение отображалось только тогда, когда был открыт DevTools (то есть что-то, что имело бы низкую вероятность того, что его увидят рабочие пользователи, которые не являются разработчиками). По сути, это расширение текущей стратегии console.log, которую React уже использует сегодня.

Мне было любопытно, если бы ваши мысли о подходе отличались, если бы сообщение отображалось только тогда, когда был открыт DevTools (т.е. что-то, что имело бы низкую вероятность того, что его увидят рабочие пользователи, которые не являются разработчиками). По сути, это расширение текущей стратегии console.log, которую React уже использует сегодня.

Если у вас открыты инструменты разработчика, вы, вероятно, видите сообщения console.log, поэтому изменения DOM кажутся ненужной сложностью для управления и избыточностью. Вы всегда можете сделать сообщения консоли React больше/причудливее. Может быть, логотип ASCII React. Что-то, чтобы привлечь чье-то внимание, если они туда зайдут.

В конце концов, хотя я думаю, что кто-то столкнется с этим, спросите в Stackoverflow, как отключить предупреждение, кто-то опубликует код, показывающий, как это сделать, а затем люди просто отключат его, если столкнутся с ним. Инструментов сборки много, и многие люди, с которыми я разговаривал в прошлом, сочли их запутанными или сложными (выпуск Babel 6 был «веселым» временем). Вы столкнетесь со многими людьми, которые просто никогда не используют их правильно.

По крайней мере, таков мой опыт ¯\_(ツ)_/¯

Уф, наконец-то добрался до конца ветки. Хорошо. Я немного обдумал это.

Webpack может принудительно указать NODE_ENV, который React затем может использовать, чтобы избежать отправки DEV в PROD, но это было бы критическим изменением для Webpack. Сейчас я говорю с Шоном о том, насколько осуществимым может быть что-то подобное для Webpack 3. Сохранение стека React + Webpack для новичков и производительности — это то, о чем, как я знаю, заботятся оба лагеря.

До сих пор это казалось моим фаворитом, но я еще не продан на 100%.

1. Таким образом, можно было бы обеспечить передачу ENV всякий раз, когда кто-либо запускает webpack. В полезном сообщении об ошибке говорится, что вы должны указать переменную env для запуска webpack.

Однако это обеспечивает значительную точку отскока для пользователей. Не все пишут для prod или dev env или даже знают, что такое env. Я подниму вопрос о webpack/webpack, чтобы получить отзывы об этом, потому что я чувствую, что не все захотят этого, и независимо от того, согласен я или нет, мы должны рассмотреть возражение.

1. <something in-between 1 and 3 I haven't figured out yet>

2. Решение webpacky состояло бы в том, чтобы создать отдельный плагин, который мог бы подключаться к жизненному циклу компилятора, проверять, удаляется ли код или не предоставляется ли ENV, и выдавать понятное предупреждение или ошибку по вашему выбору.

Однако я могу себе представить ответ: «Но пользователи никогда не узнают, как это сделать и т. д.». Таким образом, CRA, таким образом, этот вопрос прямо сейчас.

Мы могли бы создать новый шаблон распознавателя, который будет проверять пакет React (или любое программное обеспечение, которое в нем нуждается) для чего-то вроде следующего:

"webpack": {
  "plugin": "ReactEnviornmentPlugin"
}

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

Опять просто мозговой штурм.

@TheLarkInn Я думаю, что текущего поведения -p в webpack 2 достаточно, не так ли? Единственный случай сбоя — это если кто-то сам настроит UglifyJsPlugin и забудет сделать DefinePlugin , но это кажется гораздо менее вероятным случаем.

@taion Да/Нет

-p применяет только производственные "лечения" к вашему коду, однако мы не делаем никаких предположений и/или не знаем, что установлено NODE_ENV . Это то, что заставляет людей использовать DefinePlugin() .

Но я действительно думаю, что это самая близкая "_разумная_" область к _предположению_ или _подразумеваемому_ тому, что пользователь запускает свой код в рабочей среде ENV. Это была бы единственная область, в которой мы хотели бы убедиться, что сообщество и команда в порядке.

@TheLarkInn Я считаю, что это изменилось в v2: https://webpack.js.org/guides/production-build/#node -environment-variable

Ах, извините, это правильно, я ошибаюсь. Однако он не используется часто, потому что люди хотят более точного контроля над тем, что они оптимизируют. (Как упомянул @addyosmani )

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

Мы могли бы создать новый шаблон распознавателя, который будет проверять пакет React (или любое программное обеспечение, которое в нем нуждается) для чего-то вроде следующего:

"веб-пакет": {
"плагин": "ReactEnviornmentPlugin"
}
это автоматически применялось бы к пользовательской конфигурации компилятора без необходимости знать или заботиться о них.

@TheLarkInn , если я правильно это понимаю, для запуска шаблона преобразователя в package.json приложения необходимо вручную указать ReactEnvironmentPlugin , верно? Или я неправильно понял предложение? :)

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

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

Я не думаю, что это действительно дает вам какие-либо гарантии, если в веб-пакете нет концепции «производственного» режима, чтобы выяснить, как настроить React — и это кажется излишним, учитывая, что, как обсуждалось выше, -p уже делает правильно вещь, и это то, к чему обычно стремятся пользователи при создании мини-сборки с помощью webpack.

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

Мы давно рассматривали возможность включения «окна предупреждений» для предупреждений React в процессе разработки. Вы можете увидеть демо здесь (PR: https://github.com/facebook/react/pull/7360). Он появляется только тогда, когда у вас есть предупреждения, но они очень распространены во время разработки (и всегда должны быть исправлены), поэтому, по-видимому, любой, кто потратил более пяти минут на разработку приложения, увидит диалог и узнает, что он существует.

После этого изменения будет сложнее не знать о режиме разработки. Скорее всего, вы будете искать «как удалить диалоговое окно с предупреждением» и узнаете о сборке для производства. Если вы этого не сделаете, вы, вероятно, в какой-то момент получите несколько предупреждений, и ваши пользователи увидят их. Я думаю, что в этом случае люди не будут обвинять React как таковой, потому что мы не просто показываем коробку как неприятную — мы просто делаем то, что должен делать режим разработки.

(Кстати, мы уже давно используем подобное окно предупреждения в разработке в Facebook, поэтому оно соответствует тому, как мы предполагаем использовать React.)

Я очень рад видеть это предложение, @gaearon! Это все, о чем я мечтал ;)

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

Да, хороший момент. Мы кое-что добавим.

@gaearon Я нахожу это решение крайне неприятным; Я бы никогда не хотел, чтобы предупреждения вторгались в DOM даже во время разработки. Это бесполезно для обычного разработчика и, вероятно, будет полностью отключено большинством. Инструменты разработчика отображают предупреждения не просто так, их не нужно изобретать.

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

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

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

Для сравнения, вот как диалог выглядит в кодовой базе Facebook:

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

Если у вас есть предложения по настройке стиля, не стесняйтесь комментировать https://github.com/facebook/react/pull/7360.

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

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

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

@gaearon

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

Это должны быть ошибки или исключения IMO. Почему это не так? Исключения вынуждают что-то исправлять, а предупреждающие предупреждения – нет.

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

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

Это просто похоже на то, что React пытается сделать слишком много IMO.

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

Мы давно рассматривали возможность включения «окна предупреждений» для предупреждений React в процессе разработки. Вы можете посмотреть демо здесь (PR: #7360). Он появляется только тогда, когда у вас есть предупреждения, но они очень распространены во время разработки (и всегда должны быть исправлены), поэтому, по-видимому, любой, кто потратил более пяти минут на разработку приложения, увидит диалог и узнает, что он существует.

Мне очень нравится #7360, @gaearon. Приятно слышать поддержку выделения необходимости перехода на PROD для развертываний в новом окне предупреждения. Это красиво и наглядно.

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

@bvaughn С нетерпением жду новых ваших итераций :)

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

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

После этого изменения будет сложнее не знать о режиме разработки. Скорее всего, вы будете искать «как удалить диалоговое окно с предупреждением» и узнаете о сборке для производства. Если вы этого не сделаете, вы, вероятно, в какой-то момент получите несколько предупреждений, и ваши пользователи увидят их. Я думаю, что в этом случае люди не будут обвинять React как таковой, потому что мы не просто показываем коробку как неприятную — мы просто делаем то, что должен делать режим разработки.

Это должны быть ошибки или исключения IMO. Почему это не так? Исключения вынуждают что-то исправлять, а предупреждающие предупреждения – нет.

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

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

снимок экрана 2017-01-24 в 10 57 11 утра

Вы уверены, что это из самого Vue? Это очень похоже на ошибки сборки веб-пакета, отображаемые с наложением ошибок из webpack-hot-middleware . Если это так, то это немного отличается, потому что это инструмент сборки во время разработки, добавляющий оверлей, а не универсальную среду внешнего интерфейса.

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

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

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

Я не знаю, было ли это очень четко сообщено ранее, но идея в отношении предупреждений желтого ящика (# 7360) заключалась в том, чтобы не показывать _все_ предупреждения (устаревшие или другие). Скорее, таким образом будут выделены определенные предупреждения, которые команда считает _особенно важным_. Остальное, предположительно, останется в консоли.

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

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

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

Во-первых, еще одна благодарность команде React ( @sebmarkbage , @gaearon , @tomocchino и другим) за обсуждение этой проблемы с нами и готовность обсуждать с нами производительность и мобильные устройства на BlinkOn и других синхронизациях в этом квартале.

Проверка статуса

Согласно @aweary в https://github.com/facebook/react/pull/7360 , решение желтой корзины для этой конкретной проблемы было отложено до тех пор, пока высокоприоритетная работа React V16 не будет завершена, но все еще должна происходить. https://github.com/facebook/fbjs/pull/165 необходимо разместить и внедрить в Fiber. Также необходимо создать хороший публичный API для раскрытия хуков. Буду держать пальцы 🤞

Эта проблема, кажется, все еще распространена

Довольно много рабочих приложений, которые попадались мне на стол, все еще отправляют режим DEV в рабочую среду. Мы можем увидеть строку отладки When deploying React apps to production в их сборках здесь:

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js (thread.com)
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

Я по-прежнему придерживаюсь мнения, что переход до «Желтой корзины» к регистрации предупреждения режима DEV на консоли для вышеуказанного может иметь некоторое влияние. Предложение Себастьяна выдать ошибку консоли, чтобы отчеты о сбоях могли их выявить, также было тем, что, по моему мнению, заслуживало внимания.

Что еще мы можем сделать, чтобы сдвинуть иглу сюда?

Лучшая защита? Я рад продолжать выступать за людей, которые не отправляют режим DEV в производство, но хочу посмотреть, сможем ли мы выпустить официальное решение после версии V16 :)

В краткосрочной перспективе похоже, что create-react-app поможет новым проектам избежать этой проблемы.

Улучшения в документации по установке

Для всех остальных будет ли поддержка https://facebook.github.io/react/docs/installation.html , включая четкую видимую выноску под заголовком Installing React , напоминающую людям о необходимости помнить о режиме DEV в производство?

Как пользователь, я не чувствую большого стимула для меня читать https://facebook.github.io/react/docs/installation.html#development -and-production-versions с первого взгляда.

Мысли?

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

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

Для всех остальных будет ли поддержка https://facebook.github.io/react/docs/installation.html , включая четкую видимую выноску под заголовком «Установка React», напоминающую людям о необходимости помнить о режиме DEV в рабочей среде?

Конечно. Хотите отправить PR?

Конечно. Хотите отправить PR?

Более чем счастлив.

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

Заставляет меня думать, что расширение react devtools может быть использовано для отображения уведомления или чего-то очевидного при открытии страницы с использованием реакции в режиме разработки, может быть?

Мне нравится эта идея! Я собрал набор предложенных иконок для devtools (см. facebook/react-devtools/pull/652).

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

Мы предприняли разумные шаги для решения этой проблемы:

• React DevTools (около 700 000 пользователей) теперь отображает характерный красный значок для сборок для разработки. Это помогает людям узнать о различиях между версиями на ранней стадии. Это также создает некоторое давление со стороны сверстников, поскольку разработчики замечают это на посещаемых ими сайтах и ​​сообщают об этом людям, работающим над ними. Мы видели, как несколько крупных сайтов исправили проблему в течение нескольких дней после ее развертывания.

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

• Приложение Create React продолжало набирать популярность. Он рано учит этому различию с помощью отдельных команд. Он также отображает постоянное уведомление о режиме разработки в терминале.

• React 16 Beta 1 (и последующие выпуски) поставляется с именами файлов react.development.js и react.production.min.js , чтобы было ясно, что неминифицированная сборка не должна использоваться в рабочей среде.

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