Node-vibrant: Demander une version utilisable en react-native

Hmmm. Je suppose que je suis naïf en m'attendant à ce que les modules de nœud fonctionnent en natif réactif. J'ai constaté que ce problème particulier survient parce que le packager natif de réaction honore le champ browser dans package.json afin que la version du navigateur soit chargée au lieu de la version du nœud. exiger node-vibrant/lib/index fonctionne autour de cela, mais la prochaine erreur est Requiring unknown module 'fs'

@chetstone Avez-vous essayé rn-nodeify ? Les modules de nœud de base ne fonctionneront pas par défaut dans une application RN car ils ne s'exécutent pas réellement sur le nœud (V8), mais sur JSC. Ce n'est pas à l'épreuve des balles, mais fonctionne assez bien d'après mon expérience.

Cela dit, j'ai des problèmes avec node-vibrant. Pouvez-vous l'essayer aussi et voir où vous obtenez? Je n'ai pas de problème avec fs , mais je pense que les hacks rn-nodeify pour stream dans les modules pngjs ou stream-to ne sont pas ajoutés - juste une intuition cependant.

Edit : Cela peut être pertinent s'il s'agit de pngjs : https://github.com/lukeapage/pngjs/issues/64

(Pour référence)

├─┬ [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. La précédente PL #21 semble indiquer que le nœud-vibrant a déjà travaillé avec React Native.
Je n'ai pas encore essayé React Native.Mais s'il charge lib/index.js tant que script d'entrée, l'implémentation d'image par défaut devrait être celle de nodejs. (voir https://github.com/akfish/node-vibrant/blob/master/src/index.coffee)
Vous pouvez essayer d'importer l'image du nœud vous-même en :

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

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

Edit : peu importe. Je viens de voir les commentaires suivis. Si require('node-vibrant/lib/index') ne fonctionne pas, la méthode ci-dessus ne fonctionnera pas non plus.

Je vais configurer React Native et faire des tests une fois que j'en aurai le temps.

@stovmascript merci pour l' React-Nativify qui semble être une approche prometteuse mais je n'ai pas eu le temps de l'essayer. Je suis sur un autre projet en ce moment mais je vais m'en occuper la semaine prochaine.

@chetstone Cool, à son tour, merci pour l'avertissement sur ReactNativity. Je viens de l'essayer et je l'aime mieux. Il y a quand même des compromis.

Avec rn-nodeify, à peu près tout est pris en charge pour vous. Vous n'avez qu'à vous rappeler d'exécuter le script de post-installation après avoir installé de nouveaux packages (c'est-à-dire qu'il s'exécutera après npm install , mais pas après npm install some-package --save ). Ce qui n'est pas si joli, c'est qu'à moins que vous ne sauvegardiez et restaurez votre package.json avant et après la fin de rn-nodeify, il y ajoutera un tas de choses, qui ne doivent pas nécessairement être là si vous avez ajouté le script de post-installation . De plus, il entre dans vos node_modules et commence directement à déconner - d'un autre côté, s'il ne casse rien, peu importe, c'est gitignoré, n'est-ce pas ? J'utilise cette solution jusqu'à présent et j'en suis satisfait.

La solution ReactNativity est IMO plus élégante dans la mesure où vous pouvez fournir votre propre fonction de transformateur de bundle au RN Packager (super cool) et vous pouvez utiliser babel-plugin-rewrite-require pour modifier les appels require() ou import s des modules de nœud de base à leurs versions de navigateur lors de la compilation. Vous avez également beaucoup plus de contrôle sur les dépendances - vous pouvez installer toutes les versions du navigateur en une seule fois avec node-libs-browser ou browserify (les deux fournissent un objet avec des mappages vers les versions du navigateur, dont vous aurez besoin pour configurer le plugin babel ). En plus de cela, vous pouvez ajouter de manière sélective des packages tels que react-native-level-fs pour le module fs. Vous devrez tester minutieusement votre application avec cette solution car elle est plus sujette aux exceptions d'exécution - toutes les bibliothèques de nœuds de base n'ont pas d'homologues de navigateur et rn-nodeify va plus loin pour essayer de résoudre ce problème. Il en va de même pour les nœuds globaux comme process ou __dirname - rn-nodeify fournit une cale assez complète pour ceux-ci, mais avec la méthode ReactNativity, vous devrez maintenir votre propre cale.

Avec les deux méthodes, je suis arrivé au même point de pensée...

Après avoir importé comme ceci :

import Vibrant from 'node-vibrant/lib';

J'obtiens cette erreur :

Le prototype d'objet ne peut être qu'un objet ou null : undefined

provenant de : _node_modules/inherits/inherits_browser.js:5_ (version navigateur du module inherits).

Si vous mettez à jour cette fonction avec le nœud qui utilise actuellement , cela déclenchera la nouvelle erreur personnalisée :

Le super constructeur pour "hériter" doit avoir un prototype

Cela semble se produire parce que le super constructeur qui est censé être passé à cette fonction n'est pas un constructeur, mais en fait une classe instanciée, donc quand vous changez le superCtor en : superCtor = superCtor.constructor , cela fonctionne.

Après le stacktrace, cela mène au package de requête utilisé par jimp, mais s'il s'agit d'un problème avec la requête ou que jimp n'utilise pas correctement la requête, je ne sais pas. Cela fonctionne très probablement bien dans le nœud, mais ne s'interrompt que lorsqu'il est fourni pour le navigateur ou uniquement pour la réaction native même.

Merci beaucoup pour le rapport détaillé. Alors, vos modifications à _inherits_ suffisent-elles pour que le nœud fonctionne avec RN ou êtes-vous toujours bloqué?

Le 6 novembre 2016, 07:24 -0700, Martin Šťovíček [email protected] , a écrit :

@chetstone (https://github.com/chetstone) Cool, à son tour, merci pour l'avertissement sur ReactNativity. Je viens de l'essayer et je l'aime mieux. Il y a quand même des compromis.

Avec rn-nodeify, à peu près tout est pris en charge pour vous. Vous n'avez qu'à vous rappeler d'exécuter le script de post-installation après l'installation de nouveaux packages (c'est-à-dire qu'il s'exécutera après l'installation de npm, mais pas après l'installation de npm some-package --save). Ce qui n'est pas si joli, c'est qu'à moins que vous ne sauvegardiez et restaurez votre package.json avant et après la fin de rn-nodeify, il y ajoutera un tas de choses, qui ne doivent pas nécessairement être là si vous avez ajouté le script de post-installation . De plus, il entre dans vos node_modules et commence directement à déconner - d'un autre côté, s'il ne casse rien, peu importe, c'est gitignoré, n'est-ce pas ? J'utilise cette solution jusqu'à présent et j'en suis satisfait.

La solution ReactNativity est IMO plus élégante en ce sens que vous pouvez fournir votre propre fonction de transformateur de bundle au RN Packager (super cool) et vous pouvez utiliser babel-plugin-rewrite-require pour modifier les appels require() ou les importations de modules de nœud de base en leurs versions de navigateur lors de la compilation. Vous avez également beaucoup plus de contrôle sur les dépendances - vous pouvez installer toutes les versions du navigateur en une seule fois avec node-libs-browser ou browserify (les deux fournissent un objet avec des mappages vers les versions du navigateur, dont vous aurez besoin pour configurer le plugin babel ). En plus de cela, vous pouvez ajouter de manière sélective des packages tels que react-native-level-fs pour le module fs. Vous devrez tester minutieusement votre application avec cette solution car elle est plus sujette aux exceptions d'exécution - toutes les bibliothèques de nœuds de base n'ont pas d'homologues de navigateur et rn-nodeify va plus loin pour essayer de résoudre ce problème. Il en va de même pour les nœuds globaux comme process ou __dirname - rn-nodeify fournit un shim assez complet pour ceux-ci, mais avec la méthode ReactNativity, vous devrez maintenir votre propre shim.

Avec les deux méthodes, je suis arrivé au même point de pensée...

Après avoir importé comme ceci :

importer Vibrant depuis 'node-vibrant/lib'

J'obtiens cette erreur :

Le prototype d'objet ne peut être qu'un objet ou null : undefined

provenant de : node_modules/inherits/inherits_browser.js:5 (version navigateur du module inherits).

Si vous mettez à jour cette fonction avec le nœud actuellement utilisé (https://github.com/nodejs/node/blob/master/lib/util.js#L956-L969), cela déclenchera la nouvelle erreur personnalisée :

Le super constructeur pour "hériter" doit avoir un prototype

Cela semble se produire parce que le super constructeur qui est censé être passé à cette fonction n'est pas un constructeur, mais en fait une classe instanciée, donc lorsque vous modifiez le superCtor (https://github.com/isaacs/inherits/blob/master /inherits_browser.js#L3) à : superCtor = superCtor.constructor, ça marche.

Après le stacktrace, cela mène au package de requête utilisé par jimp, mais s'il s'agit d'un problème avec la requête ou que jimp n'utilise pas correctement la requête, je ne sais pas. Cela fonctionne très probablement bien dans le nœud, mais ne s'interrompt que lorsqu'il est fourni pour le navigateur ou uniquement pour la réaction native même.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub (https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020), ou coupez le fil (https://github.com/notifications/unsubscribe -auth/AA7l1wl7ggsGTqd7RZlpwWup6T3Ookl7ks5q7eMSgaJpZM4KeOV2).

@stovmascript J'ai enfin eu le temps d'essayer avec react-nativify . Je ne pense pas être allé aussi loin que toi. Il semble que la quantité de piratage nécessaire pour que cela fonctionne pourrait être presque infinie.

Premièrement, je n'arrivais pas à faire fonctionner le transformateur. J'ai finalement découvert que la possibilité de spécifier getTransformModulePath() dans rn-cli.config.js avait été supprimée via une régression dans ma version de react-native (0.32.1). J'ai donc contourné cela en utilisant --transformer dans la commande npm start .

Ensuite, le packager, pour une raison quelconque, n'a pas pu trouver le module util même s'il était installé. Encore plus étrangement, il semble qu'il puisse trouver util au besoin dans certains modules ( png.js ) mais pas dans d'autres ( _stream_readable ).

Commentant l'exigence de util dans _stream_readable pour voir si je pouvais aller plus loin, cela a échoué lorsque jimp faisait référence à des variables qui n'étaient pas définies dans le process cale.

Enfin, après avoir lu cet article , je suis prêt à abandonner cette approche. Je n'ai pas essayé avec rn-nodify mais compte tenu de votre expérience, je pense que ce serait perdre plus de temps.

Il semble beaucoup plus simple de créer un wrapper natif pour Android autour de la bibliothèque de palettes réelle. Je ne connais pas Java, mais il est peut-être temps d'apprendre. Et cela ne fonctionnera pas sur iOS, mais j'utilise avec succès le composant

Je viens de publier react-native-palette qui encapsule l'excellente classe Android Palette en tant que module natif. Le composant prend également en charge des fonctionnalités similaires pour iOS, mais avec quelques problèmes.

Ce serait bien d'avoir également une solution uniquement javascript telle que node-vibrant qui fonctionnerait sur iOS car le support natif y fait quelque peu défaut.

Désolé pour le long délai. La vraie vie est arrivée.
D'après ce que je comprends des commentaires ci-dessus, le problème semble être lié à la référence de jimp à fs , qui n'est pas disponible dans l'environnement react-native.

À partir jimp source [1] de jimp , le réglage de process.env.ENVIRONMENT à "BROWSER" ne nécessitera pas le module fs .

Une solution de contournement possible :

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

Quelqu'un pourrait-il vérifier si cette approche fonctionnera? Merci.

Un rappel que GitHub a réactions aux problèmes pour montrer son support sans obstruer le fil

Votre dernière version "3.2.0-alpha" plante dans React Native avec l'erreur "Can't find variable: self"
et après avoir supprimé une seule chaîne :
import * as Vibrant from 'node-vibrant';
l'application fonctionne, il n'y a donc même aucune possibilité de la tester dans React Native.

Votre dernière version "3.2.0-alpha" plante dans React Native avec l'erreur _"Can't find variable: self"_
et après avoir supprimé une seule chaîne :
import * as Vibrant from 'node-vibrant';
l'application fonctionne, il n'y a donc même aucune possibilité de la tester dans React Native.

Je suis désolé, je ne comprends pas vraiment, la bibliothèque node-vibrant fonctionne-t-elle avec RN ou non?

@Psiiirus, cela devrait fonctionner dans la version non alpha

J'obtiens Can't find variable: document en react-native.