Node-vibrant: Solicite uma versão utilizável em reagente nativo

Hmmm. Acho que estou sendo ingênuo em esperar que os módulos de nó funcionem em react-native. Descobri que esse problema específico surge porque o empacotador reagente nativo honra o campo browser em package.json portanto, a versão do navegador é carregada em vez da versão do nó. exigir node-vibrant/lib/index contorna isso, mas o próximo erro é Requiring unknown module 'fs'

@chetstone Você já tentou o rn-nodeify ? Os módulos do nó principal não funcionam por padrão em um aplicativo RN porque, na verdade, não é executado no nó (V8), mas no JSC. Não é à prova de balas, mas funciona razoavelmente bem pela minha experiência.

Dito isso, estou tendo problemas com o nó vibrante. Você pode tentar também e ver onde você chega? Não tenho problemas com fs , mas acho que rn-nodeify hacks para stream em pngjs ou módulos stream-to não estão sendo adicionados - apenas um palpite.

Editar: isso pode ser relevante se for relacionado a pngjs: https://github.com/lukeapage/pngjs/issues/64

(Para referência)

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

Hum. O PL # 21 anterior parece indicar nó vibrante uma vez trabalhado com React Native.
Ainda não experimentei o React Native.Mas se ele carregar lib/index.js como script de entrada, a implementação de imagem padrão deve ser a do nodejs. (consulte https://github.com/akfish/node-vibrant/blob/master/src/index.coffee)
Você pode tentar importar a imagem do nó por conta própria:

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

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

Edit: deixa pra lá. Apenas vi comentários seguidos. Se require('node-vibrant/lib/index') não funcionar, o método acima também não funcionará.

Vou configurar o React Native e fazer alguns testes assim que tiver tempo.

@stovmascript obrigado pelo React-Nativify, que parece uma abordagem promissora, mas não tive tempo de tentar. Estou em outro projeto no momento, mas analisarei isso na próxima semana.

@chetstone Cool, por sua vez, obrigado pelo aviso sobre o ReactNativity. Apenas experimentei e gostei mais. No entanto, existem compensações.

Com o rn-nodeify, praticamente tudo é cuidado para você. Você só precisa se lembrar de executar o script de pós-instalação após instalar novos pacotes (ou seja, ele será executado após npm install , mas não após npm install some-package --save ). O que não é tão bonito é que, a menos que você salve e restaure seu package.json antes e depois do término do rn-nodeify, ele adicionará um monte de coisas a ele, que basicamente não precisa estar lá se você adicionou o script postinstall . Também vai para o seu node_modules e começa a mexer diretamente - por outro lado, se não quebrar nada, quem se importa, é gitignored certo? Tenho usado essa solução até agora e estou feliz com ela.

A solução ReactNativity é IMO mais elegante porque você pode fornecer sua própria função de transformador de pacote para o RN Packager (super legal) e você pode usar o babel-plugin-rewrite-require para alterar as require() chamadas ou import s de módulos de nó de núcleo para suas versões de navegador durante a compilação. Você também tem muito mais controle sobre as dependências - você pode instalar todas as versões do navegador de uma vez com o node-libs-browser ou browserify (ambos fornecem um objeto com mapeamentos para as versões do navegador, que você precisará para configurar o plugin babel ) Além disso, você pode adicionar pacotes seletivamente como react-native-level-fs para o módulo fs. Você terá que testar completamente seu aplicativo com esta solução porque é mais propenso a exceções de tempo de execução - nem todas as bibliotecas de nó central têm contrapartes de navegador e o rn-nodeify vai além para tentar resolver isso. O mesmo vale para nós globais como process ou __dirname - rn-nodeify fornece um shim bastante extenso para eles, mas com o método ReactNativity, você terá que manter seu próprio shim.

Com os dois métodos, cheguei ao mesmo ponto, pensei ...

Depois de importar assim:

import Vibrant from 'node-vibrant/lib';

Estou recebendo este erro:

O protótipo do objeto pode ser apenas um objeto ou nulo: indefinido

originado em: _node_modules / inherits / inherits_browser.js: 5_ (versão do navegador do módulo herda).

Se você atualizar esta função com o nó que

O superconstrutor para "herdar" deve ter um protótipo

Parece que está acontecendo porque o superconstrutor que deve ser passado para essa função não é um construtor, mas na verdade uma classe instanciada, portanto, quando você altera o superCtor para: superCtor = superCtor.constructor , ele funciona.

Seguindo o rastreamento de pilha, ele leva ao pacote de solicitação usado pelo jimp, mas se é um problema com a solicitação ou o jimp não está usando a solicitação corretamente, não sei. Provavelmente funciona bem no nó, mas só quebra quando empacotado para o navegador ou apenas para reagir nativo mesmo.

Muito obrigado pelo relatório completo. Portanto, suas modificações em _inherits_ são suficientes para obter um funcionamento vibrante de nó com RN ou você ainda está preso?

Em 6 de novembro de 2016, 07:24 -0700, Martin Šťovíček [email protected] , escreveu:

@chetstone (https://github.com/chetstone) Legal, por sua vez, obrigado pelo aviso sobre o ReactNativity. Apenas experimentei e gostei mais. No entanto, existem compensações.

Com o rn-nodeify, praticamente tudo é cuidado para você. Você só precisa se lembrar de executar o script postinstall após instalar novos pacotes (ou seja, ele será executado após a instalação do npm, mas não após a instalação do npm algum-pacote --save). O que não é tão bonito é que, a menos que você salve e restaure seu package.json antes e depois do término do rn-nodeify, ele adicionará um monte de coisas a ele, que basicamente não precisa estar lá se você adicionou o script postinstall . Também vai para o seu node_modules e começa a mexer diretamente - por outro lado, se não quebrar nada, quem se importa, é gitignored certo? Tenho usado essa solução até agora e estou feliz com ela.

A solução ReactNativity é IMO mais elegante, pois você pode fornecer sua própria função de transformador de pacote para o RN Packager (muito legal) e pode usar o babel-plugin-rewrite-require para alterar as chamadas de require () ou importações de módulos do nó principal para suas versões de navegador durante a compilação. Você também tem muito mais controle sobre as dependências - você pode instalar todas as versões do navegador de uma vez com o node-libs-browser ou browserify (ambos fornecem um objeto com mapeamentos para as versões do navegador, que você precisará para configurar o plugin babel ) Além disso, você pode adicionar pacotes seletivamente como react-native-level-fs para o módulo fs. Você terá que testar completamente seu aplicativo com esta solução porque é mais propenso a exceções de tempo de execução - nem todas as bibliotecas de nó central têm contrapartes de navegador e o rn-nodeify vai além para tentar resolver isso. O mesmo vale para nós globais como process ou __dirname - rn-nodeify fornece um shim bastante extenso para eles, mas com o modo ReactNativity, você terá que manter seu próprio shim.

Com os dois métodos, cheguei ao mesmo ponto, pensei ...

Depois de importar assim:

importar Vibrant de 'node-vibrant / lib'

Estou recebendo este erro:

O protótipo do objeto pode ser apenas um objeto ou nulo: indefinido

originado em: node_modules / inherits / inherits_browser.js: 5 (versão do navegador do módulo inherits).

Se você atualizar esta função com o nó que está usando atualmente (https://github.com/nodejs/node/blob/master/lib/util.js#L956-L969), isso acionará o novo erro personalizado:

O superconstrutor para "herdar" deve ter um protótipo

Parece que está acontecendo porque o superconstrutor que deve ser passado para esta função não é um construtor, mas na verdade uma classe instanciada, então quando você muda o superCtor (https://github.com/isaacs/inherits/blob/master /inherits_browser.js#L3) para: superCtor = superCtor.constructor, funciona.

Seguindo o rastreamento de pilha, ele leva ao pacote de solicitação usado pelo jimp, mas se é um problema com a solicitação ou o jimp não está usando a solicitação corretamente, não sei. Provavelmente funciona bem no nó, mas só quebra quando empacotado para o navegador ou apenas para reagir nativo mesmo.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub (https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020) ou ignore o tópico (https://github.com/notifications/unsubscribe -auth / AA7l1wl7ggsGTqd7RZlpwWup6T3Ookl7ks5q7eMSgaJpZM4KeOV2).

@stovmascript Finalmente tive algum tempo para tentar com react-nativify . Eu não acho que cheguei tão longe quanto você. Parece que a quantidade de hacking envolvida para fazer isso funcionar pode ser quase infinita.

Primeiro, não consegui fazer o transformador funcionar. Finalmente descobri que a capacidade de especificar getTransformModulePath() em rn-cli.config.js foi removida por meio de uma regressão em minha versão do react-native (0.32.1). Então, contornei isso usando --transformer no comando npm start .

Então, o empacotador por algum motivo não conseguiu encontrar o módulo util , embora ele estivesse instalado. Ainda mais estranhamente, parece que ele poderia encontrar util quando exigido de alguns módulos ( png.js ), mas não de outros ( _stream_readable ).

Comentando a exigência de util em _stream_readable para ver se eu poderia ir mais longe, ele falhou quando jimp referiu a variáveis ​​que não foram definidas em process calço.

Finalmente, depois de ler este artigo , estou pronto para desistir dessa abordagem. Eu não tentei com rn-nodify mas dada a sua experiência, acho que estaria perdendo mais tempo.

Parece muito mais simples construir um wrapper nativo para o Android em torno da biblioteca de paletas real. Não sei java, mas talvez seja hora de aprender. E não funcionará no iOS, mas tenho usado o componente colorgrabber em meu aplicativo iOS com muito sucesso. Não tão completo quanto a paleta, mas bom o suficiente para meus propósitos.

Acabei de publicar o react-native-palette que envolve a excelente classe Android Palette como um módulo nativo. O componente também oferece suporte a funcionalidades semelhantes para iOS, mas com alguns problemas.

Seria bom também ter uma solução somente javascript, como node-vibrant, que funcionasse no iOS, já que o suporte nativo está faltando.

Desculpe pela longa demora. A vida real aconteceu.
Pelo que entendi com os comentários acima, o problema parece estar relacionado à referência de jimp a fs , que não está disponível no ambiente nativo reativo.

Da fonte de jimp [1] , definir process.env.ENVIRONMENT como "BROWSER" exigirá o módulo fs .

Uma possível solução alternativa:

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

Alguém poderia verificar se essa abordagem funcionará? Obrigado.

Um lembrete de que o GitHub tem 👍 reações aos problemas para mostrar suporte sem obstruir o thread

Sua versão mais recente "3.2.0-alpha" trava no React Native com o erro "Não é possível encontrar a variável: self"
e depois de excluir apenas 1 string:
import * as Vibrant from 'node-vibrant';
app funciona, então não há sequer a possibilidade de testá-lo no React Native.

Sua versão mais recente "3.2.0-alpha" trava no React Native com o erro _ "Não foi possível encontrar a variável: self" _
e depois de excluir apenas 1 string:
import * as Vibrant from 'node-vibrant';
app funciona, então não há sequer a possibilidade de testá-lo no React Native.

Desculpe, não entendi direito, a biblioteca node-vibrant está funcionando com RN ou não?

@Psiiirus deve estar funcionando na versão não alfa

Estou recebendo Can't find variable: document em reagente nativo.