noflo ui
1.0.0
O Noflo Development Environment é um aplicativo da Web com capacidade off-line que ajuda os usuários a criar e executar programas baseados em fluxo criados com sistemas compatíveis com FBP, como Noflo, MSGFLO, IMGFLO e Microflo. O ambiente de desenvolvimento Noflo está disponível sob a licença do MIT.
Este projeto foi possível por 1205 apoiadores do Kickstarter. Verifique o Project Changelog para novos recursos e outras alterações.
O FlowHub é uma versão hospedada do ambiente de desenvolvimento Noflo.
Se você deseja apenas criar aplicativos, recomendamos que você use esta versão em vez de criar o seu próprio a partir da fonte.
Embora a própria interface do usuário seja construída com o Noflo, ela não está falando diretamente com o Noflo para executar e construir gráficos. Em vez disso, está utilizando o protocolo de rede FBP, que permite conversar com qualquer sistema FBP compatível. Atualmente, são conhecidos com mais de 5 tempos de execução diferentes por funcionar.
Ao implementar o protocolo em seu tempo de execução, você pode programá -lo com a UI Noflo. Se você usar o WebSockets ou o WebRTC como transporte, não precisará alterar nada na interface do usuário noflo. Você também pode adicionar suporte a outros transportes.
A maneira mais fácil de passar o usuário As informações de conexão do seu tempo de execução é através do modo LIVE . Com isso, os detalhes da conexão são passados para o aplicativo por meio de parâmetros de URL, como este:
http://app.flowhub.io#runtime/endpoint?protocol%3Dwebsocket%26address%3Dws%3A%2F%2F127.0.0.1%3A3569
Os parâmetros suportados para o endpoint incluem:
protocol : o transporte do protocolo FBP para usar para a conexão. Valores possíveis incluem websocket , iframe e webrtcaddress : URL para usar para a conexão. Pode ser, por exemplo ws:// URL para websockets, ou o URL do signaller e o identificador de conexão para WebRTCsecret : segredo para se comunicar com o tempo de execuçãoEsses URLs podem ser mostrados na saída da linha de comando ou fornecidos ao usuário por meio de outro mecanismo. Consulte uma demonstração de vídeo para abrir o aplicativo no modo ao vivo por meio de uma tag NFC.
Opcionalmente, pode -se adicionar modelos de componentes, destaque da sintaxe e um link 'Introdução' para novos horários.
./runtimeinfo/myruntime.yaml . ExemploSomente necessário se você quiser invadir a própria interface do usuário noflo. Não é necessário para criar aplicativos com o FBP.
Foi fornecido um Dockerfile que pode ser usado para construir/executar facilmente a interface do usuário Noflo. Você também pode obter uma imagem construída automaticamente no Docker Hub.
docker build -t noflo-ui . docker run -d -p 9999:80 noflo-uiDepois de construído e o servidor estiver em execução, você pode acessar a interface do usuário em http: // localhost: 9999/index.html
Para poder trabalhar na interface do usuário noflo, você precisa:
Vá para a pasta de checkout e corra:
$ npm install
Isso fornecerá todas as dependências de desenvolvimento necessárias. Agora você pode construir uma nova versão executando:
$ npm run build
Você precisa executar este comando como administrador no Windows.
Sirva a interface do usuário usando um servidor da web e abra o URL em um navegador da web. Exemplo:
$ npm start
Se preferir, você pode iniciar um processo de servidor de dev Webpack que fará uma reconstrução sempre que um dos arquivos mudar:
$ npm run dev
Depois de construído e o servidor estiver em execução, você pode acessar a interface do usuário em http://localhost:9999/index.html
Além deste projeto, o outro repositório de interesse é o widget do editor de gráfico do gráfico usado para editar fluxos.
Em alto nível, a arquitetura Noflo-UI segue as convenções Redux adaptadas ao Noflo. Aqui está como se parece o principal fluxo de dados:
Store OUT -> IN Middleware # Store sends actions together with application state to middleware
Middleware NEW -> ACTION Store # Middleware can trigger new actions
Middleware PASS -> IN Reduce # Actions go from middleware to reducers
Reduce OUT -> STATE Store # Reducers produce a new state object that gets sent to store
Reduce OUT -> STATE View # State also goes to the view
View ACTION -> ACTION Store # View can trigger actions
O fluxo real é mais detalhado. Você pode visualizar e editá -lo em graphs/main.fbp .
NOTA: Os pricípios descritos abaixo estão a arquitetura que estamos buscando. Estamos refatorando partes do sistema para ajustar essa arquitetura à medida que as modificamos. Toda a nova funcionalidade deve ser implementada após essa arquitetura.
O componente da loja acompanha o estado mais recente do aplicativo. Quando recebe novas ações, envia a cadeia de middleware e redutor junto com o estado mais recente do aplicativo.
O middleware NOFLO-UI são componentes ou gráficos que podem interagir com ações específicas. Cada ação passa pela cadeia de middlewares, e cada middleware tem duas opções para lidar com uma ação:
O middleware é onde os efeitos colaterais relacionados ao estado do aplicativo são tratados. Isso pode incluir conversar com serviços da Web externos, comunicações de tempo de execução do FBP e carregar ou salvar dados no indexedDB local. O middleware recebe o estado atual do aplicativo e pode ler dele, mas eles apenas manipulam o estado pela maneira de criar novas ações.
Alguns middleware também podem atuar como geradores, criando novas ações com base na entrada externa.
A abordagem do middleware é explicada mais adiante nesta postagem do blog.
O trabalho dos redutores é receber ações e fazer alterações no estado do aplicativo. Os redutores devem, de fato, ser funções puras, onde o mesmo estado de entrada e combinação de ação sempre produz o mesmo novo estado.
A camada de visualização do aplicativo é implementada como elementos de polímero. A visualização do aplicativo recebe o objeto de estado produzido pelos redutores.
As interações do usuário na visualização do aplicativo não devem fazer alterações diretas no estado. Em vez disso, a exibição do aplicativo pode desencadear novas ações disparando eventos de polímero. Eles então são processados pelo middleware e redutores, fazendo com que o estado mude.
A UI noflo está usando o GitHub para autenticação. Temos um aplicativo padrão configurado para trabalhar em http://localhost:9999 . Se você deseja servir sua interface do usuário noflo a partir de um URL diferente, precisará registrar seu próprio aplicativo OAuth com eles. Certifique -se de combinar a política de URL de redirecionamento do Github.
Para ativar seu próprio aplicativo OAuth, defina as seguintes variáveis de ambiente e reconstrua a interface do usuário Noflo:
$NOFLO_OAUTH_CLIENT_ID : ID do cliente do seu aplicativo Github OAuth$NOFLO_OAUTH_CLIENT_REDIRECT : Redirecionar URL do seu aplicativo Github OAuthPara lidar com a parte secreta do cliente OAuth do processo de login, existem duas opções:
Esta é a opção fácil para o desenvolvimento local da UI noflo. Basta criar o segredo do cliente OAuth no aplicativo de interface do usuário Noflo, configurando -o através da variável de ambiente $NOFLO_OAUTH_CLIENT_SECRET .
NOTA: Isso significa que qualquer pessoa com acesso a esta compilação da UI Noflo poderá ler o segredo do seu cliente. Nunca faça isso com um URL acessível ao mundo. É bom para o desenvolvimento somente para o desenvolvimento, no entanto.
Você pode implantar uma instância do aplicativo Gatekeeper Node.js para lidar com a troca de token OAuth por você. Configure a localização do gatekeeper para a sua interface do usuário noflo com a variável de ambiente $NOFLO_OAUTH_GATE .
Esse é o mecanismo mais seguro, pois apenas o servidor do gatekeeper precisa conhecer o segredo do cliente.
