Node-vibrant: Запросить версию, пригодную для использования в react-native

Хм. Я предполагаю, что я наивен, ожидая, что модули узлов будут работать в режиме react-native. Я обнаружил, что эта конкретная проблема возникает из-за того, что собственный упаковщик реагирует на поле browser в package.json поэтому версия браузера загружается вместо версии узла. Требование node-vibrant/lib/index помогает обойти это, но следующая ошибка - Requiring unknown module 'fs'

@chetstone Вы пробовали rn-nodeify ? Модули основного узла не будут работать по умолчанию в приложении RN, потому что на самом деле оно работает не на узле (V8), а на JSC. Он не пуленепробиваемый, но, по моему опыту, работает достаточно хорошо.

Тем не менее, у меня проблемы с node-vibrant. Вы тоже можете попробовать и посмотреть, что у вас получится? У меня нет проблем с fs , но я думаю, что хаки rn-nodeify для stream в pngjs или модулях stream-to не добавляются - хотя это просто догадка.

Изменить: это может быть актуально, если это связано с pngjs: https://github.com/lukeapage/pngjs/issues/64

(Для справки)

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ ├── [email protected]
│ │ │ ├── [email protected]
│ │ │ ├── [email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├── [email protected]
│ │ │ │ └─┬ [email protected]
│ │ │ │   └── [email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├── [email protected]
│ │ │ │ ├─┬ [email protected]
│ │ │ │ │ ├── [email protected]
│ │ │ │ │ └── [email protected]
│ │ │ │ └── [email protected]
│ │ │ └── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected]
│ │ ├── [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ ├── [email protected]
│ └─┬ [email protected]
│   ├── [email protected]
│   └── [email protected]

Хм. Предыдущий PL # 21, похоже, указывает на то, что когда-то работал с React Native, node-vibrant.
Я еще не пробовал React Native.Но если он загружает lib/index.js как сценарий входа, реализация изображения по умолчанию должна быть nodejs. (см. https://github.com/akfish/node-vibrant/blob/master/src/index.coffee)
Вы можете попробовать импортировать образ узла самостоятельно:

// var Vibrant = require('node-vibrant')
// var NodeImage = require('node-vibrant/lib/image/node')

// var v = new Vibrant(uri, {Image: NodeImage})

Изменить: неважно. Только что увидел последовавшие комментарии. Если require('node-vibrant/lib/index') не сработает, вышеуказанный метод тоже не сработает.

Я настрою React Native и проведу небольшое тестирование, как только у меня будет время.

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

@chetstone Круто, в свою очередь, спасибо за информацию о ReactNativity. Просто попробовал, и он мне больше нравится. Однако есть компромиссы.

С помощью rn-nodeify практически обо всем позаботятся. Вам нужно только не забыть запустить сценарий postinstall после установки новых пакетов (т.е. он будет запускаться после npm install , но не после npm install some-package --save ). Что не так красиво, так это то, что если вы не сохраните и не восстановите свой package.json до и после завершения rn-nodeify, он добавит к нему кучу вещей, которых в принципе не должно быть, если вы добавили сценарий postinstall . Также он входит в ваш node_modules и напрямую начинает возиться - с другой стороны, если он ничего не сломает, кого это волнует, это gitignored, верно? Я до сих пор использую это решение и доволен им.

Решение ReactNativity является ИМО более элегантным в том смысле, что вы можете предоставить свою собственную функцию преобразования пакетов в RN Packager (супер круто), и вы можете использовать babel-plugin-rewrite-require для изменения вызовов require() или import s модулей ядра узла в их версии браузера во время компиляции. У вас также есть гораздо больший контроль над зависимостями - вы можете установить все версии браузера за один раз с помощью node-libs-browser или browserify (оба предоставляют объект с сопоставлениями с версиями браузера, которые вам понадобятся для настройки плагина babel ). Вдобавок к этому вы можете выборочно добавлять пакеты, такие как react-native-level-fs для модуля fs. Вам нужно будет тщательно протестировать свое приложение с помощью этого решения, потому что оно более подвержено исключениям во время выполнения - не все библиотеки основных узлов имеют аналоги в браузере, и rn-nodeify пытается решить эту проблему. То же самое касается глобальных узлов, таких как process или __dirname - rn-nodeify предоставляет для них довольно обширную прокладку, но с помощью способа ReactNativity вам придется поддерживать свою собственную прокладку.

С обоими методами я пришел к одной и той же мысли ...

После импорта вот так:

import Vibrant from 'node-vibrant/lib';

Я получаю такую ​​ошибку:

Прототип объекта может быть только Object или null: undefined

происходит из: _node_modules / inherits / inherits_browser.js: 5_ (версия модуля наследника в браузере).

Если вы обновите эту функцию, указав, какой узел в настоящее время используется , это вызовет новую настраиваемую ошибку:

Суперконструктор для «наследования» должен иметь прототип.

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

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

Большое спасибо за подробный отчет. Достаточно ли ваших модификаций в _inherits_, чтобы работа с RN была яркой, или вы все еще застряли?

6 ноября 2016 г., 07:24 -0700, Мартин Шловичек [email protected] написал:

@chetstone (https://github.com/chetstone) Круто, в свою очередь, спасибо за информацию о ReactNativity. Просто попробовал, и он мне больше нравится. Однако есть компромиссы.

С помощью rn-nodeify практически обо всем позаботятся. Вам нужно только не забыть запустить сценарий postinstall после установки новых пакетов (т.е. он будет запускаться после установки npm, но не после npm install some-package --save). Что не так красиво, так это то, что если вы не сохраните и не восстановите свой package.json до и после завершения rn-nodeify, он добавит к нему кучу вещей, которых в принципе не должно быть, если вы добавили сценарий postinstall . Также он входит в ваш node_modules и напрямую начинает возиться - с другой стороны, если он ничего не сломает, кого это волнует, это gitignored, верно? Я до сих пор использую это решение и доволен им.

Решение ReactNativity является более элегантным IMO в том смысле, что вы можете предоставить свою собственную функцию преобразования пакетов в RN Packager (супер круто), и вы можете использовать babel-plugin-rewrite-require для изменения вызовов require () или импорта модулей ядра узла на их версии браузера во время компиляции. У вас также есть гораздо больший контроль над зависимостями - вы можете установить все версии браузера за один раз с помощью node-libs-browser или browserify (оба предоставляют объект с сопоставлениями с версиями браузера, которые вам понадобятся для настройки плагина babel ). Вдобавок к этому вы можете выборочно добавлять пакеты, такие как react-native-level-fs для модуля fs. Вам нужно будет тщательно протестировать свое приложение с помощью этого решения, потому что оно более подвержено исключениям во время выполнения - не все библиотеки основных узлов имеют аналоги в браузере, и rn-nodeify пытается решить эту проблему. То же самое и с глобальными узлами, такими как process или __dirname - rn-nodeify предоставляет для них довольно обширную прокладку, но с помощью способа ReactNativity вам придется поддерживать свою собственную прокладку.

С обоими методами я пришел к одной и той же мысли ...

После импорта вот так:

импортировать Vibrant из 'node-vibrant / lib'

Я получаю такую ​​ошибку:

Прототип объекта может быть только Object или null: undefined

происходит по адресу: node_modules / inherits / inherits_browser.js: 5 (версия модуля наследника в браузере).

Если вы обновите эту функцию, указав, какой узел в настоящее время используется (https://github.com/nodejs/node/blob/master/lib/util.js#L956-L969), это вызовет новую настраиваемую ошибку:

Суперконструктор для «наследования» должен иметь прототип.

Похоже, это происходит потому, что суперконструктор, который должен быть передан этой функции, не является конструктором, а на самом деле является экземпляром класса, поэтому при изменении superCtor (https://github.com/isaacs/inherits/blob/master /inherits_browser.js#L3) в: superCtor = superCtor.constructor, он работает.

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

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub (https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020) или отключите поток (https://github.com/notifications/unsubscribe -auth / AA7l1wl7ggsGTqd7RZlpwWup6T3Ookl7ks5q7eMSgaJpZM4KeOV2).

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

Во-первых, я не мог заставить работать трансформатор. Наконец я обнаружил, что возможность указывать getTransformModulePath() в rn-cli.config.js была удалена из-за регрессии в моей версии react-native (0.32.1). Поэтому я решил это исправить, используя --transformer в команде npm start .

Затем упаковщик по какой-то причине не смог найти модуль util даже если он был установлен. Что еще более странно, кажется, что он может находить util когда требуется из одних модулей ( png.js ), но не из других ( _stream_readable ).

Комментируя требование util в _stream_readable чтобы посмотреть, могу ли я пойти дальше, он потерпел неудачу, когда jimp ссылался на переменные, которые не были определены в process прокладка.

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

Кажется, намного проще создать собственную оболочку для Android на основе реальной библиотеки pallete . Я не знаю java, но, может, пора учиться. И это не будет работать на iOS, но я успешно использую компонент colorgrabber в своем приложении для iOS. Не так полно, как палитра, но для моих целей вполне годится.

Я только что опубликовал react-native-palette, которое обертывает отличный класс Android Palette как собственный модуль. Компонент также поддерживает аналогичные функции для iOS, но с некоторыми проблемами.

Было бы неплохо также иметь решение только для javascript, такое как node-vibrant, которое будет работать на iOS, поскольку нативная поддержка там несколько отсутствует.

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

Из источника jimp [1] установка process.env.ENVIRONMENT на "BROWSER" пропустит необходимость модуля fs .

Возможный обходной путь:

// Prevent jimp from requiring `fs`
process.env.ENVIRONMENT = 'BROWSER'
// Require node.js version vibrant explicitly
const Vibrant = require('node-vibrant/lib/index')
// Load image file into a Buffer in some react-native compatible way
let buf = react_native_read_file('path/to/image')
// Pass buffer to node-vibrant
Vibrant.from(buf).getPalette()

Может ли кто-нибудь проверить, будет ли этот подход работать? Спасибо.

Напоминание о том, что GitHub 👍 реагирует на проблемы, чтобы показать поддержку, не засоряя поток

Ваша последняя версия «3.2.0-alpha» вылетает в React Native с ошибкой «Can't find variable: self»
и после удаления всего 1 строки:
import * as Vibrant from 'node-vibrant';
приложение работает, поэтому нет возможности даже протестировать его в React Native.

Ваша последняя версия "3.2.0-alpha" вылетает в React Native с ошибкой _ "Не удается найти переменную: self" _
и после удаления всего 1 строки:
import * as Vibrant from 'node-vibrant';
приложение работает, поэтому нет возможности даже протестировать его в React Native.

Извините, я действительно не понимаю, работает ли библиотека с поддержкой узлов с RN или нет?

@Psiiirus он должен работать в не-альфа-сборке

Я получаю Can't find variable: document в react-native.