codeframe
1.0.0
O CodeFrame é a maneira mais rápida e fácil de criar e implantar páginas da web estática rápida, e foi projetado para ser o melhor lugar para aprender a criar coisas para a web, na web. Você pode encontrá -lo em execução ao vivo no CodeFrame.co.
É fácil de usar. O CodeFrame é construído em primeiro lugar para experimentos rápidos e para as pessoas que aprendem a codificar pela primeira vez, por isso evita a complexidade e recursos adicionais para simplicidade e facilidade de uso.
É rápido. Seu ambiente de desenvolvimento deve se mover na velocidade de suas idéias e, sem ferramentas de construção, não há razão para que o código de código não possa ser instantâneo. Eu criei o CodeFrame para reduzir o tempo da ideia para o protótipo compartilhável o máximo possível fisicamente. Basta abrir o editor, escrever código e compartilhar um clique.
? É de código aberto e totalmente inspecável. Tudo o que executa o CodeFrame, da pilha de back -end até o código JavaScript por trás do Editor de CodeFrame, é de código aberto e inspecionável no navegador. Eu acho que ter o código -fonte legível no produto entregue faz a diferença para as pessoas que aprendem a codificar, e o código de código prioriza isso sobre complexidade adicional e pequenos ganhos de eficiência com pacotes minificados e fonte proprietária.
Se você não precisar especificamente de algo projetado para velocidade ou para os alunos novos em codificação, existem outras ferramentas que podem funcionar melhor para você, com mais recursos. O Codepen é o IDE clássico da Web no navegador, com recursos mais poderosos e opções de personalização; O CodesandBox é incrível para experimentar projetos com etapas de construção / pacote, e o Repl.it tem um incrível conjunto de ferramentas de desenvolvimento para seu ambiente HTML, incluindo a capacidade de criar arquivos / pastas e multiplayer adicionais, o que permite uma colaboração tranquila em tempo real.
Tudo o que você precisa para executar sua própria versão do CodeFrame está neste repositório de código aberto. Veja como você pode executar sua própria versão no CodeFrame no seu computador ou servidor.
Você precisará dessas ferramentas:
git , para copiar o repositório do Github para o seu computador. Obtenha git aqui.npm (ou seu yarn alternativo) para instalar dependências como o Express. NPM normalmente vem com Node.js.ls , cd , etc.Depois de instalar essas ferramentas, a primeira etapa é clonar este repositório Git para o seu computador. Vá para um diretório onde você deseja configurar o CodeFrame e corra
$ git clone https://github.com/thesephist/codeframe.git (Se você tem o SSH configurado para o Git e sabe como usá -lo, pode usar o git:// URL. Se não o fizer, não se preocupe.)
Agora, cd no novo diretório codeframe GIT acabou de ser criado e você deve ver todos os arquivos no repositório CodeFrame.
$ cd codeframe/
$ ls
src/ static/ docs/ README.md LICENSE ... Aqui, vamos tentar iniciar o CodeFrame com o Node.js usando o comando npm start .
$ npm start
...
Error: Cannot find module ' express '
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:603:15)
... Isso significa que o Node.js não conseguiu encontrar express , uma biblioteca JavaScript para criar servidores da Web de que o código de código depende. Vamos instalar dependências como o Express executando npm install e tente novamente.
$ npm install
...
$ npm start
Codeframe running on localhost:4556 Você pode notar que o NPM cria um novo diretório chamado node_modules/ , onde ele instalará as dependências do CodeFrame.
Se você vir o Codeframe running on localhost:4556 , isso significa que você tem código de código em funcionamento no seu computador. Vá para o seu navegador e abra o endereço http://localhost:4556 . Isso deve dizer ao seu navegador para encontrar a página em execução na porta 4556 (porta padrão do CodeFrame) no seu computador e carregar a página principal do CodeFrame.
Depois de alterar qualquer arquivo de serviço de back-end (em src/ ), você pode reiniciar o servidor com npm start (CTRL + C para encerrar um servidor em execução) para ver as alterações ocorreram. Se você estiver editando o código do front -end, não há necessidade de reiniciar - basta recarregar a página no navegador!
Se você está curioso sobre o trabalho interno do CodeFrame, estou construindo uma versão totalmente anotada da base de código disponível aqui nas páginas do GitHub usando uma ferramenta chamada Litterate. Embora seja um bom lugar para ver como tudo é implementado, esta seção fornece uma visão geral de alto nível de como o sistema é projetado.
Todos os códigos de código são (por enquanto) um par de arquivos, um arquivo HTML e um arquivo JavaScript, que podemos apenas tratar como pedaços de texto. O CodeFrame armazena todos os arquivos, tanto HTML quanto JavaScript, no mesmo local, da mesma maneira, de uma maneira que não pode ser modificada depois de salvos. Este é o banco de dados imutável e baseado em hash do CodeFrame.
Quando um usuário cria um novo arquivo ou uma nova versão de um arquivo, o editor envia o arquivo para o back -end. O back -end recebe o arquivo e hashes (atualmente usando o sha256) e usa o hash para criar um nome de arquivo curto e praticamente exclusivo para o arquivo. O arquivo é salvo em um local no back -end ( db/ por padrão) com esse nome de arquivo hashed. Isso garante que, se tentassemos salvar o mesmo arquivo várias vezes, economizaríamos efetivamente apenas um arquivo no back -end. Porque isso acontece muito na prática usando o CodeFrame, isso é eficiente.
Cada arquivo é identificado por seu hash dessa maneira; portanto, usando dois hashes (um para os arquivos HTML e JavaScript de um CodeFrame), podemos definir qualquer código de código exclusivo. É assim que o código de código funciona; Cada URL de CodeFrame contém dois hashes, um para HTML e JavaScript. Quando você solicita um código de código, o back -end encontra arquivos salvos antes de usar esses hashes como nomes de arquivos e retorna os arquivos ao editor ou ao navegador para sua visualização.
Este banco de dados de arquivos baseado em hash tem algumas vantagens. O fato de cada arquivo ser salvo uma vez e nunca substituir significa que qualquer código de código, a qualquer momento, é completamente caracterizado por seu URL. Seu Changelog é efetivamente o histórico do seu navegador, e qualquer código de código que você compartilha permanecerá exatamente essa versão para sempre. Isso também significa que o serviço de back-end permanece extremamente simples-é um design completamente funcional, sem efeitos colaterais fora do banco de dados, que é uma loja imutável de valor-chave.
A implementação atualmente, que é apenas baseada no sistema de arquivos, também fica aquém em algumas áreas. Principalmente, ele usa o FS como a camada de armazenamento do banco de dados. Como os sistemas de arquivos não são projetados para serem usados dessa maneira, em grandes números, podemos atingir um gargalo de escalabilidade, onde teremos que mudar para uma loja de valores-chave diferente, como o S3 da Amazon. Atualmente, também armazenamos alterações incrementais em cada arquivo em um arquivo completamente separado no banco de dados. É também a maneira como o Git lida com as mudanças, mas com o uso do CodeFrame, isso pode ser massivamente ineficiente. Esses problemas não estão no momento, mas podem se tornar mais importantes daqui para frente; nesse momento, abordaremos.
A interface do usuário do frontend do CodeFrame é criada como um único componente Torus, que é o editor de código CodeFrame. Este editor pode ser executado independente, como acontece na visualização do editor de tela cheia de qualquer código de código, ou pode ser incorporado como um <iframe> em certos sites permitidos, como está na página principal. Tudo o que você vê no front -end, incluindo o restante da página inicial, é simples, HTML manuscrito, CSS e JavaScript.
Eu escolhi o Toro para construir o front-end porque (1) escrevi a biblioteca, então a conheço de dentro para fora e ele foi projetado para se encaixar nos meus gostos, (2) é rápido e leve, assim como o CodeFrame foi projetado para ser e (3) torna a prototipagem muito rápida; A v1.0 do CodeFrame foi construída em 20 horas em 2 dias, então a prototipagem rápida era uma prioridade, enquanto coisas como suporte para navegadores mais antigas não eram um objetivo central. Também foi uma boa chance de deixar o Torus esticar as pernas e testá -lo em um ambiente de produção.
Todo o editor é implementado em um único arquivo JavaScript, no static/js/main.js , que você pode ler aqui.
Para o editor de texto dentro do CodeFrame, nos navegadores da área de trabalho, estou usando o Monaco, um editor de texto construído para o navegador do editor de código do Visual Studio da Microsoft. É rápido, elegante e funciona muito bem nos navegadores de mesa. Falta o suporte móvel de Mônaco, no entanto, em navegadores móveis, enviamos um editor diferente, Codemirror. O Codemirror é amplamente utilizado em Chrome Devtools e Glitch, entre outras ferramentas, é leve e rápido para carregar e muito mais utilizável em navegadores móveis do que o Mônaco. As experiências de uso de ambos os editores estão quase paridade pela experiência básica, enquanto cada editor traz alguns aprimoramentos menores de recursos em relação ao outro. Você pode ler sobre como alcançamos essa arquitetura flugable na seção "back -end do editor flugable" abaixo.
O painel de visualização no editor é um <iframe> simples que abre uma visualização da página JS HTML + gerada para o CodeFrame, para que você possa vê -lo à medida que atualiza ao vivo. Hoje, ele opera completamente independentemente do editor, mas no futuro podemos adicionar alguma comunicação entre os dois para possibilitar recursos mais sofisticados, como atualizações ao vivo.
O Editor do CodeFrame possui apenas uma única dependência do núcleo: Torus, que é uma estrutura de interface do usuário leve. Para velocidade de desenvolvimento, o CodeFrame atualmente envia a dependência como uma tag simples <script> no editor HTML, que aponta a versão mais recente do pacote NPM no unpkg. No futuro, podemos agrupar o toro com uma versão compilada do nosso script editor. Mas até agora, a UNPKG se mostrou confiável o suficiente.
A parte do editor de código do CodeFrame não está contida nesta base de código. Embora exista uma implementação de referência de um editor muito nua aqui implementado como um <textarea> , na produção, conforme explicado acima, o CodeFrame usa o Monaco ou o Codemirror como editor de código de escolha, dependendo do cliente (navegadores móveis versus desktop). Podemos mudar de maneira fácil e confiável entre esses três editores e outros potenciais no futuro, porque o CodeFrame Frontend faz interface com o editor através de um pequeno conjunto de APIs que podem ser implementadas em torno de qualquer editor de código razoável. Chamamos esse conjunto de APIs de interface EditorCore .
O CodeFrame é transmitido com os invólucros EditorCore para Mônaco e Codemirror, e escolhe carregar um ou outro no tempo de execução, dependendo do cliente (se não estivermos usando um editor, nenhuma parte do código desse editor é carregada no navegador). Se mudarmos para um back -end de editor diferente ou trocar um editor com outro no futuro, essa arquitetura de wrapper com uma pequena superfície da API facilita muito - algumas horas no máximo para envolver a interface em torno de um novo editor. Enquanto o invólucro do editor implementar a interface corretamente, o editor funcionará com o restante do código de código.
O CodeFrame é de código aberto por dois motivos.
Para o segundo ponto, existem muitos cantos do quadro de código que são difíceis e podem usar algum polimento. Se você é um desenvolvedor de JavaScript experiente e deseja ver o CodeFrame melhorar, meus DMs e PRs estão abertos.
Mais importante, porém, fiz código aberto de código com a intenção de que os recém-chegados à programação da Web possam aprender com a fonte do CodeFrame. Se você encontrar um pouco de código no repositório que o confunde, sinta -se à vontade para registrar um problema ou adicionar uma solicitação de tração para obter melhores explicações, esclarecimentos ou melhor código.
Uma parte essencial do CodeFrame é sua biblioteca de modelos de partida amigáveis. É um pequeno conjunto por enquanto, mas quero transformar isso em um repositório de quadros de código de amostra de alta qualidade que permitem que as pessoas entrem e aprendam sobre novas tecnologias da Web com facilidade.
Se você possui códigos ou amostras que deseja incluir na primeira página do CodeFrame como outro modelo de partida, adicione um arquivo em starter_fixtures/ e interno const STARTER_FIXTURES no src/models.js e registre uma solicitação de tração! Os modelos iniciantes configurados dessa maneira estão configurados no banco de dados no momento da implantação, garantindo que todas as versões em execução do CodeFrame configuram.
Um dos principais recursos do Editor de Codeframe é o seu recurso "Recarregar enquanto você digita". Ou seja, no modo padrão (com o recurso ativado), o editor recarregará periodicamente o painel de visualização com o código do editor, às vezes no meio da digitação. Isso geralmente contribui para uma experiência de edição superior - sem mudar o que estamos fazendo, vemos o resultado do nosso código imediatamente à medida que estamos editando, e esse loop de feedback apertado é ótimo para o desenvolvimento.
No entanto, em certos casos, especialmente ao escrever JavaScript, isso significa que a pré -visualização recarrega no meio da digitação, quando estamos escrevendo javascript potencialmente inválidos ou de buggy. Um desses comportamentos de buggy que poderíamos recarregar inadvertidamente no painel de visualização é um loop infinito. Em certos contextos, por exemplo, quando estamos escrevendo for(){} e while(){} loops, podemos criar um loop infinito no meio da digitação do nosso programa que é recarregado em nossa janela de visualização, que, por design, moe toda a guia do editor até uma parada e resulta em potencial perda de dados nas edições feitas no editor.
O CodeFrame não é o primeiro editor a se deparar com isso, e o codepen.io tem uma abordagem interessante para instrumentar o JavaScript em um ambiente de reloalização ao vivo para impedir esse comportamento. O problema é um desafio, porque a prevenção de loops infinitos no caso geral é impossível - é uma variante clássica do problema de interrupção. No caso de Codepen, eles instrumentam o código JavaScript gerado, de modo que, quando o mesmo loop é executado continuamente por mais do que algum período de tempo ou iterações, ele interrompe o loop. É uma solução pragmática, embora deselegante. A falha, por outro lado, não faz nada para evitar loops infinitos em ambientes de recarga ao vivo.
Descobri que, na prática, é bastante raro escrever um código JavaScript com sintaxe, que também resulta em loops infinitos. E para esses casos raros, o CodeFrame tem a opção de desativar a recarga do tipo como você no editor. Mas, por padrão, o CodeFrame segue a precedência de Glitch em não modificar ou instrumentar o JavaScript para impedir a execução infinita. Se tivermos mais casos de uso em que isso se tornar um problema, podemos revisitar esse problema.
Um efeito colateral elegante da simplicidade do código que você pode escrever no CodeFrame (sem etapa de compilação, sem agrupamento) é que a saída que você obtém em uma página de visualização HTML é literalmente o código que você digitou no editor, além de algum código HTML do invólucro. Portanto, em vez de adicionar explicitamente um botão "exportar" ou um item de menu, o usuário pode simplesmente abrir a visualização e salvar o documento HTML para "exportar" os quadros de código que eles criaram.
Se você gosta de usar o CodeFrame e deseja apoiar o que eu faço daqui para frente, considere fazer uma doação ao CodeFrame através do PayPal ou Venmo.
Como alternativa, considere doar para algumas das melhores organizações sem fins lucrativos que fazem um ótimo trabalho no espaço educacional da CS, Khanacademy, Hack Club e Stutech.
