Node-vibrant: Fordern Sie eine Version an, die in Reactive-native verwendet werden kann

Hmmm. Ich denke, ich bin naiv, wenn ich erwarte, dass Knotenmodule in Reaktiv-nativ arbeiten. Ich habe festgestellt, dass dieses spezielle Problem auftritt, weil der reaktive-native Paketierer das Feld browser in package.json sodass die Browserversion anstelle der Knotenversion geladen wird. Wenn Sie node-vibrant/lib/index benötigen, wird dies Requiring unknown module 'fs'

@chetstone Hast du es mit rn-nodeify versucht? Core-Node-Module funktionieren standardmäßig nicht in einer RN-App, da sie nicht wirklich auf Node (V8), sondern auf JSC ausgeführt wird. Es ist nicht kugelsicher, läuft aber meiner Erfahrung nach recht gut.

Das heißt, ich habe Probleme mit Node-Vibrant. Kannst du es auch ausprobieren und sehen, wo du herkommst? Ich habe kein Problem mit fs , aber ich denke, rn-nodeify-Hacks für stream in pngjs oder Stream-to-Module werden nicht hinzugefügt - nur eine Ahnung.

Bearbeiten: Dies könnte relevant sein, wenn es sich um pngjs handelt: https://github.com/lukeapage/pngjs/issues/64

(Als Referenz)

├─┬ [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]

Hmm. Die vorherige PL #21 scheint darauf hinzudeuten, dass node-vibrant einmal mit React Native gearbeitet hat.
React Native habe ich noch nicht ausprobiert.Wenn es jedoch lib/index.js als Eingabeskript lädt, sollte die Standardbildimplementierung die von nodejs sein. (siehe https://github.com/akfish/node-vibrant/blob/master/src/index.coffee)
Sie können versuchen, das Knoten-Image selbst zu importieren, indem Sie:

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

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

Edit: egal. Habe gerade folgende Kommentare gesehen. Wenn require('node-vibrant/lib/index') nicht funktioniert, funktioniert die obige Methode auch nicht.

Ich werde React Native einrichten und einige Tests durchführen, sobald ich Zeit habe.

@stovmascript danke für den Hinweis zu rn-nodeify. Ich habe auch React-Nativify gefunden, was ein vielversprechender Ansatz zu sein scheint, aber ich hatte keine Zeit, es auszuprobieren. Ich arbeite gerade an einem anderen Projekt, werde mir das aber nächste Woche anschauen.

@chetstone Cool, wiederum

Mit rn-nodeify wird so ziemlich alles für Sie erledigt. Sie müssen nur daran denken, das Postinstall-Skript auszuführen, nachdem Sie neue Pakete installiert haben (dh es wird nach npm install , aber nicht nach npm install some-package --save ). Was nicht so schön ist, ist, dass es eine Menge Dinge hinzufügt, die im Grunde nicht vorhanden sein müssen, wenn Sie das Postinstall-Skript hinzugefügt haben, es sei denn, Sie speichern und stellen Ihre package.json vor und nach dem Abschluss von rn-nodeify wieder her . Es geht auch in Ihre node_modules und fängt direkt an, herumzuspielen - auf der anderen Seite, wenn es nichts kaputt macht, wen kümmert es, es ist gitignored, oder? Ich benutze diese Lösung bisher und bin damit zufrieden.

Die ReactNativity-Lösung ist IMO insofern eleganter, als Sie dem RN Packager Ihre eigene Bundle-Transformer-Funktion bereitstellen können (super cool) und Sie können babel-plugin-rewrite-require verwenden, um die require() Aufrufe oder import zu ändern process oder __dirname - rn-nodeify liefert für diese einen ziemlich umfangreichen Shim, aber mit der ReactNativity-Methode müssen Sie Ihren eigenen Shim pflegen.

Mit beiden Methoden bin ich am selben Punkt angekommen, dachte...

Nach dem Importieren wie folgt:

import Vibrant from 'node-vibrant/lib';

Ich bekomme diesen Fehler:

Objektprototyp darf nur ein Objekt oder null sein: undefiniert

Ursprungsland: _node_modules/inherits/inherits_browser.js:5_ (Browserversion des inherits-Moduls).

Wenn Sie diese Funktion mit dem aktuell verwendeten Knoten aktualisieren, wird der neue benutzerdefinierte Fehler ausgelöst:

Der Superkonstruktor zum "erben" muss einen Prototyp haben

Es scheint zu passieren, weil der Superkonstruktor, der an diese Funktion übergeben werden soll, kein Konstruktor ist, sondern eine instanziierte Klasse. Wenn Sie also den SuperCtor in superCtor = superCtor.constructor ändern, funktioniert es.

Nach dem Stacktrace führt es zu dem von jimp verwendeten Anforderungspaket, aber ob es ein Problem mit der Anforderung ist oder ob jimp die Anforderung nicht korrekt verwendet, weiß ich nicht. Es funktioniert höchstwahrscheinlich gut in Node, bricht aber nur ab, wenn es für den Browser gebündelt wird oder nur für Reaktiv-Native.

Vielen Dank für den ausführlichen Bericht. Reichen Ihre Modifikationen an _inherits_ aus, um Node-Vibrant mit RN arbeiten zu lassen, oder stecken Sie immer noch fest?

Am 6. November 2016, 07:24 -0700, schrieb Martin Šťovíček [email protected] :

@chetstone (https://github.com/chetstone) Cool, wiederum vielen Dank für den Hinweis zu ReactNativity. Habe es gerade ausprobiert und es gefällt mir besser. Es gibt jedoch Kompromisse.

Mit rn-nodeify wird so ziemlich alles für Sie erledigt. Sie müssen nur daran denken, das postinstall-Skript nach der Installation neuer Pakete auszuführen (dh es wird nach npm install ausgeführt, aber nicht nach npm install some-package --save). Was nicht so schön ist, ist, dass es eine Menge Dinge hinzufügt, die im Grunde nicht vorhanden sein müssen, wenn Sie das Postinstall-Skript hinzugefügt haben, es sei denn, Sie speichern und stellen Ihre package.json vor und nach dem Abschluss von rn-nodeify wieder her . Es geht auch in Ihre node_modules und fängt direkt an, herumzuspielen - auf der anderen Seite, wenn es nichts kaputt macht, wen kümmert es, es ist gitignored, oder? Ich benutze diese Lösung bisher und bin damit zufrieden.

Die ReactNativity-Lösung ist IMO eleganter, da Sie dem RN Packager Ihre eigene Bundle-Transformer-Funktion bereitstellen können (super cool) und Sie können babel-plugin-rewrite-require verwenden, um die require()-Aufrufe oder Importe von Core-Node-Modulen zu ändern deren Browserversionen während der Kompilierung. Sie haben auch viel mehr Kontrolle über Abhängigkeiten - Sie können alle Browserversionen auf einmal installieren, entweder mit node-libs-browser oder browserify (beide liefern ein Objekt mit Zuordnungen zu den Browserversionen, die Sie zum Konfigurieren des Babel-Plugins benötigen ). Darüber hinaus können Sie Pakete wie React-native-level-fs selektiv für das fs-Modul hinzufügen. Sie müssen Ihre App mit dieser Lösung gründlich testen, da sie anfälliger für Laufzeitausnahmen ist – nicht alle Kernknotenbibliotheken haben Browser-Gegenstücke und rn-nodeify geht weiter, um dies zu beheben. Das Gleiche gilt für Node-Globals wie process oder __dirname - rn-nodeify liefert dafür ein ziemlich umfangreiches Shim, aber mit der ReactNativity-Methode müssen Sie Ihr eigenes Shim pflegen.

Mit beiden Methoden bin ich am selben Punkt angekommen, dachte...

Nach dem Importieren wie folgt:

Importieren Sie Vibrant von 'node-vibrant/lib'

Ich bekomme diesen Fehler:

Objektprototyp darf nur ein Objekt oder null sein: undefiniert

Ursprung: node_modules/inherits/inherits_browser.js:5 (Browserversion des inherits-Moduls).

Wenn Sie diese Funktion mit dem derzeit verwendeten Knoten aktualisieren (https://github.com/nodejs/node/blob/master/lib/util.js#L956-L969), wird der neue benutzerdefinierte Fehler ausgelöst:

Der Superkonstruktor zum "erben" muss einen Prototyp haben

Es scheint zu passieren, weil der Superkonstruktor, der an diese Funktion übergeben werden soll, kein Konstruktor ist, sondern tatsächlich eine instanziierte Klasse. Wenn Sie also den SuperCtor ändern (https://github.com/isaacs/inherits/blob/master /inherits_browser.js#L3) an: superCtor = superCtor.constructor, es funktioniert.

Nach dem Stacktrace führt es zu dem von jimp verwendeten Anforderungspaket, aber ob es ein Problem mit der Anforderung ist oder ob jimp die Anforderung nicht korrekt verwendet, weiß ich nicht. Es funktioniert höchstwahrscheinlich gut in Node, bricht aber nur ab, wenn es für den Browser gebündelt wird oder nur für Reaktiv-Native.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an (https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020) oder schalten Sie den Thread stumm (https://github.com/notifications/unsubscribe .). -auth/AA7l1wl7ggsGTqd7RZlpwWup6T3Ookl7ks5q7eMSgaJpZM4KeOV2).

@stovmascript Endlich habe react-nativify zu versuchen. Ich glaube, ich habe es nicht so weit geschafft wie du. Es scheint, dass die Menge an Hacking, die erforderlich ist, um dies zum Laufen zu bringen, fast endlos sein könnte.

Erstens konnte ich den Transformator nicht zum Laufen bringen. Ich habe schließlich festgestellt, dass die Möglichkeit, getTransformModulePath() in rn-cli.config.js anzugeben, durch eine Regression in meiner Version von Reactive (0.32.1) entfernt wurde. Also habe ich das umgangen, indem ich --transformer im Befehl npm start .

Dann konnte der Paketierer aus irgendeinem Grund das Modul util nicht finden, obwohl es installiert war. Noch seltsamer scheint es, dass es util finden könnte , wenn es von einigen Modulen ( png.js ) benötigt wird, aber nicht von anderen ( _stream_readable ).

Das Erfordernis von util in _stream_readable auskommentieren, um zu sehen, ob ich weiterkommen könnte, es schlug fehl, als jimp auf Variablen verwies, die nicht in process unterlegen.

Schließlich, nachdem ich diesen Artikel gelesen rn-nodify versucht, aber nach Ihrer Erfahrung denke ich, dass es mehr Zeit verschwenden würde.

Es scheint viel einfacher zu sein, einen nativen Wrapper für Android um die eigentliche Palettenbibliothek herum zu Colorgrabber- Komponente in meiner iOS-App mit gutem Erfolg verwendet. Nicht so voll ausgestattet wie die Palette, aber für meine Zwecke gut genug.

Ich habe gerade React-native-Palette veröffentlicht, die die ausgezeichnete Android-Palette-Klasse als natives Modul umschließt. Die Komponente unterstützt auch ähnliche Funktionen für iOS, jedoch mit einigen Problemen.

Es wäre schön, auch eine reine Javascript-Lösung wie node-vibrant zu haben, die unter iOS funktioniert, da dort die native Unterstützung etwas fehlt.

Entschuldigung für die lange Verzögerung. Das wahre Leben ist passiert.
Nach dem, was ich aus den obigen Kommentaren verstehe, scheint das Problem mit dem Verweis von jimp auf fs , der in einer reaktiven nativen Umgebung nicht verfügbar ist.

Ab der Quelle von jimp [1] wird das Setzen von process.env.ENVIRONMENT auf "BROWSER" das erforderliche fs Modul überspringen.

Ein möglicher Workaround:

// 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()

Könnte jemand überprüfen, ob dieser Ansatz funktioniert? Vielen Dank.

Eine Erinnerung daran, dass GitHub 👍 auf Probleme reagiert, um Unterstützung zu zeigen, ohne den Thread zu verstopfen

Ihre neueste Version "3.2.0-alpha" stürzt in React Native mit dem Fehler "Can't find variable: self" ab
und nach dem Löschen von nur 1 String:
import * as Vibrant from 'node-vibrant';
app funktioniert, daher gibt es nicht einmal die Möglichkeit, sie in React Native zu testen.

Ihre neueste Version "3.2.0-alpha" stürzt in React Native mit dem Fehler _"Kann Variable nicht finden: self"_
und nach dem Löschen von nur 1 String:
import * as Vibrant from 'node-vibrant';
app funktioniert, daher gibt es nicht einmal die Möglichkeit, sie in React Native zu testen.

Es tut mir leid, dass ich es nicht wirklich verstehe, funktioniert die Node-Vibrant Lib mit RN oder nicht?

@Psiiirus es sollte im Nicht-Alpha-Build funktionieren working

Ich bekomme Can't find variable: document in Reactive-Native.