codeframe
1.0.0
CodeFrame est le moyen le plus rapide et le plus simple de créer et de déployer des pages Web statiques rapides, et il est conçu pour être le meilleur endroit pour apprendre à créer des choses pour le Web, sur le Web. Vous pouvez le trouver en direct sur codeframe.co.
C'est facile à utiliser. CodeFrame est construit avant tout pour des expériences rapides et pour les personnes qui apprennent à coder pour la première fois, donc cela évite la complexité et les fonctionnalités supplémentaires pour la simplicité et la facilité d'utilisation.
C'est rapide. Votre environnement de développement devrait se déplacer à la vitesse de vos idées, et sans outillage de construction, il n'y a aucune raison pour que CodeFrame ne puisse pas être instantané. J'ai construit CodeFrame pour réduire le temps de l'idée au prototype partageable autant que possible physiquement. Ouvrez simplement l'éditeur, écrivez du code et partagez en un seul clic.
? C'est open-source et entièrement inspecté. Tout ce qui exécute CodeFrame, de la pile backend au code JavaScript derrière l'éditeur CodeFrame, est open source et inspectable dans le navigateur. Je pense que le code source lisible dans le produit livré fait une différence pour les personnes qui apprennent le code, et CodeFrame hiérarte à ce sujet de complexité supplémentaire et de petits gains d'efficacité avec des faisceaux minifiés et une source propriétaire.
Si vous n'avez pas spécifiquement besoin de quelque chose conçu pour la vitesse ou pour les étudiants nouveaux dans le codage, il existe d'autres outils qui pourraient mieux fonctionner pour vous, avec plus de fonctionnalités. CodePen est l'ide Web classique dans le navigateur avec des fonctionnalités et des options de personnalisation plus puissantes; Codesandbox est génial pour expérimenter des projets avec des étapes de construction / regroupement, et il a une suite incroyable d'outils de développement pour leur environnement HTML, y compris la possibilité de créer des fichiers / dossiers supplémentaires et un multijoueur, ce qui permet une collaboration en temps réel fluide.
Tout ce dont vous avez besoin pour exécuter votre propre version de CodeFrame est dans ce référentiel open source. Voici comment exécuter votre propre version sur CodeFrame sur votre ordinateur ou votre serveur.
Vous aurez besoin de ces outils:
git , pour copier le référentiel de GitHub à votre ordinateur. Obtenez Git ici.npm (ou son yarn alternatif) pour installer des dépendances comme Express. NPM est généralement livré avec Node.js.ls , cd , etc.Une fois que ces outils ont installé et prêt, la première étape consiste à cloner ce référentiel GIT sur votre ordinateur. Accédez à un répertoire où vous souhaitez configurer CodeFrame et exécuter
$ git clone https://github.com/thesephist/codeframe.git (Si vous avez la configuration de SSH pour GIT et que vous savez comment l'utiliser, vous pouvez utiliser l'url git:// à la place. Si vous ne le faites pas, ne vous inquiétez pas.)
Maintenant, cd dans le nouveau répertoire codeframe Git vient de créer, et vous devriez voir tous les fichiers du référentiel CodeFrame.
$ cd codeframe/
$ ls
src/ static/ docs/ README.md LICENSE ... Ici, essayons de démarrer CodeFrame avec Node.js en utilisant le npm start .
$ npm start
...
Error: Cannot find module ' express '
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:603:15)
... Cela signifie que Node.js n'a pas pu trouver express , une bibliothèque JavaScript pour créer des serveurs Web dont dépend du code de code. Installons les dépendances comme Express en exécutant npm install , puis réessayez.
$ npm install
...
$ npm start
Codeframe running on localhost:4556 Vous remarquerez peut-être que NPM crée un nouveau répertoire appelé node_modules/ , où il installera les dépendances de CodeFrame.
Si vous voyez le message Codeframe running on localhost:4556 , cela signifie que vous avez CodeFrame et en cours d'exécution sur votre ordinateur. Allez dans votre navigateur et ouvrez l'adresse http://localhost:4556 . Cela devrait indiquer à votre navigateur de trouver la page en cours d'exécution sur le port 4556 (port par défaut de CodeFrame) sur votre ordinateur et de charger la page principale de CodeFrame.
Après avoir modifié tout fichier de service backend (sous src/ ), vous pouvez redémarrer le serveur avec npm start (Ctrl + C pour mettre fin à un serveur en cours d'exécution) pour voir les modifications. Si vous modifiez le code Frontend, il n'est pas nécessaire de redémarrer - il suffit de recharger la page dans le navigateur!
Si vous êtes curieux de savoir les travailleurs intérieurs de CodeFrame, je construis une version entièrement annotée de la base de code disponible ici sur les pages GitHub à l'aide d'un outil appelé Litterate. Bien que ce soit un bon endroit pour voir comment tout est mis en œuvre, cette section fournit un aperçu de haut niveau de la façon dont le système est conçu.
Tous les frames de code sont (pour l'instant) une paire de fichiers, un fichier HTML et un fichier JavaScript, que nous pouvons simplement traiter comme des morceaux de texte. CodeFrame stocke tous les fichiers, HTML et JavaScript, au même endroit, de la même manière, d'une manière qui ne peut pas être modifiée une fois enregistrée. Il s'agit de la base de données immuable basée sur le hachage de CodeFrame.
Lorsqu'un utilisateur crée un nouveau fichier ou une nouvelle version d'un fichier, l'éditeur envoie le fichier au backend. Le backend obtient le fichier et hache (actuellement en utilisant SHA256) et utilise le hachage pour créer un nom de fichier court et pratiquement unique pour le fichier. Le fichier est enregistré dans un emplacement dans le backend ( db/ par défaut) avec ce nom de fichier hachée. Cela garantit que si nous essayions de enregistrer le même fichier plusieurs fois, nous n'enregistrerions effectivement qu'un seul fichier dans le backend. Parce que cela se produit beaucoup dans la pratique en utilisant CodeFrame, c'est efficace.
Chaque fichier est identifié par son hachage de cette manière, donc en utilisant deux hachages (un chacun pour les fichiers HTML et JavaScript d'un CodeFrame), nous pouvons définir n'importe quel code de code unique. C'est ainsi que CodeFrame fonctionne; L'URL de chaque CodeFrame contient deux hachages, un chacun pour HTML et JavaScript. Lorsque vous demandez un code de code, le backend trouve des fichiers enregistrés avant d'utiliser ces hachages comme noms de fichiers et renvoie les fichiers à l'éditeur ou au navigateur pour votre visualisation.
Cette base de données de fichiers basée sur le hachage présente quelques avantages. Le fait que chaque fichier soit enregistré une fois et jamais remplacé signifie qu'un tout cas, à tout moment, est complètement caractérisé par son URL. Votre Changelog est effectivement l'historique de votre navigateur, et tout code de code que vous partagez restera exactement cette version pour toujours. Cela signifie également que le service backend reste extrêmement simple - c'est une conception complètement fonctionnelle sans effets secondaires en dehors de la base de données, qui est un magasin de valeurs clés immuables.
La mise en œuvre actuellement, qui est juste basée sur le système de fichiers, est également insuffisante dans certains domaines. Il utilise principalement le FS comme couche de stockage de la base de données. Étant donné que les systèmes de fichiers ne sont pas conçus pour être utilisés de cette façon, en grand nombre, nous pouvons frapper un goulot d'étranglement d'évolutivité où nous devrons passer à un autre magasin de valeurs clés comme le S3 d'Amazon. Nous stockons également actuellement des modifications incrémentielles dans chaque fichier dans un fichier complètement séparé dans la base de données. C'est aussi la façon dont GIT gère les changements, mais avec l'utilisation de CodeFrame, cela peut s'avérer massivement inefficace. Ces problèmes ne sont pas pour le moment, mais peuvent devenir plus importants à l'avenir, à quel point nous nous en aborderons.
L'interface utilisateur Frontend de CodeFrame est conçue en tant que composant Torus unique, qui est l'éditeur de CodeFrame. Cet éditeur peut exécuter autonome, comme il le fait dans la vue de l'éditeur complet de n'importe quelframe de code, ou il peut être intégré en tant que <iframe> dans certains sites Web autorisés, comme il est sur la page principale. Tout ce que vous voyez sur le frontend, y compris le reste de la page d'accueil, est simple, manuscrit HTML, CSS et JavaScript.
J'ai choisi Torus pour construire le frontend parce que (1) j'ai écrit la bibliothèque, donc je le sais à l'envers et il est conçu pour s'adapter à mes goûts, (2) il est rapide et léger, tout comme le code de code est conçu pour l'être, et (3) il rend le prototypage très, très rapide; Le V1.0 de CodeFrame a été construit en 20 heures sur 2 jours, donc le prototypage rapide était une priorité tandis que des choses comme le support pour les navigateurs plus âgés n'étaient pas un objectif central. C'était également une bonne chance de laisser Torus étirer ses jambes et de le tester dans un cadre de production.
L'éditeur entier est implémenté dans un seul fichier JavaScript, dans static/js/main.js , que vous pouvez lire ici.
Pour l'éditeur de texte dans CodeFrame, sur les navigateurs de bureau, j'utilise Monaco, un éditeur de texte conçu pour le navigateur de l'éditeur de code Visual Studio de Microsoft. Il est rapide, élégant et fonctionne très bien sur les navigateurs de bureau. Cependant, le support mobile de Monaco fait défaut, donc sur les navigateurs mobiles, nous expédions un éditeur différent, Codemirror. Codemirror est largement utilisé dans Chrome Devtools et Glitch, entre autres outils, est léger et rapide à charger, et bien plus utilisable sur les navigateurs mobiles que Monaco. Les expériences d'utilisation des deux éditeurs sont presque parité pour l'expérience de base, tandis que chaque éditeur apporte des améliorations de fonctionnalités plus petites par rapport à l'autre. Vous pouvez lire comment nous réalisons cette architecture enfichable dans la section "Backend Editor enfichable" ci-dessous.
Le volet d'aperçu de l'éditeur est une simple <iframe> qui ouvre une vue de la page HTML + JS générée pour le CodeFrame, vous pouvez donc le voir tel qu'il met à jour en direct. Aujourd'hui, il fonctionne complètement indépendamment de l'éditeur, mais à l'avenir, nous pouvons ajouter une communication entre les deux pour rendre les fonctionnalités plus sophistiquées possibles, comme les mises à jour en direct.
L'éditeur de CodeFrame n'a qu'une seule dépendance de noyau: Torus, qui est un cadre d'interface utilisateur léger. Pour la vitesse de développement, CodeFrame expédie actuellement la dépendance en tant que balise <script> simple dans l'éditeur HTML qui pointe la version la plus récente du package NPM sur UNPKG. À l'avenir, nous pouvons regrouper le tore avec une version compilée de notre script d'éditeur. Mais jusqu'à présent, l'UNPKG s'est avéré assez fiable.
La partie de l'éditeur de code de CodeFrame n'est pas elle-même contenue dans cette base de code. Bien qu'il y ait une implémentation de référence d'un éditeur très nu ici implémenté en tant que <textarea> , en production, comme expliqué ci-dessus, CodeFrame utilise monaco ou CodeMirror comme éditeur de code de choix, selon le client (les navigateurs de bureau mobile versus). Nous pouvons nous déplacer facilement et de manière fiable entre ces trois éditeurs et d'autres potentiels à l'avenir, car le frontend CodeFrame interface avec l'éditeur via un petit ensemble d'API qui peut être implémenté autour de tout éditeur de code raisonnable. Nous appelons cet ensemble d'API l'interface EditorCore .
CodeFrame est expédié avec EditorCore Wrappers pour Monaco et CodeMirror, et choisit de charger l'un ou l'autre au moment de l'exécution en fonction du client (si nous n'utilisons pas un éditeur, aucune partie du code de cet éditeur n'est chargée dans le navigateur). Si nous devions passer à un autre éditeur de backend ou échanger un éditeur avec un autre à l'avenir, cette architecture de wrapper avec une petite surface d'API rend cela très facile - quelques heures au maximum pour envelopper l'interface autour d'un nouvel éditeur. Tant que le wrapper de l'éditeur implémente correctement l'interface, l'éditeur fonctionnera avec le reste de CodeFrame.
CodeFrame est open-source pour deux raisons.
Au deuxième point, il y a beaucoup de coins de code de code qui sont rugueux et peuvent utiliser du vernis. Si vous êtes un développeur JavaScript expérimenté et que vous souhaitez voir CodeFrame s'améliorer, mes DM et les PR sont ouverts.
Mais plus important encore, j'ai fait de CodeFrame Open-source dans l'intention que les nouveaux arrivants à la programmation Web puissent apprendre de la lecture de la source de CodeFrame. Si vous rencontrez un peu de code dans le référentiel qui vous confond, n'hésitez pas à déposer un problème ou à ajouter une demande de traction pour de meilleures explications, clarifications ou un meilleur code.
Un élément clé de CodeFrame est sa bibliothèque de modèles de démarrage amicaux. C'est un petit ensemble pour l'instant, mais je veux transformer cela en un référentiel d'exemples de codes de haute qualité qui permettent aux gens de pénétrer et de se renseigner facilement sur les nouvelles technologies Web.
Si vous avez du code ou des échantillons que vous souhaitez inclure sur la page d'accès de CodeFrame comme un autre modèle de démarrage, ajoutez un fichier sous starter_fixtures/ et à l'intérieur const STARTER_FIXTURES dans src/models.js et lisez une demande de traction! Les modèles de démarrage configurés de cette façon sont configurés dans la base de données à l'heure du déploiement, garantissant que chaque version en cours d'exécution de CodeFrame l'a configurée.
L'une des principales fonctionnalités de l'éditeur CodeFrame est sa fonctionnalité "Recharger As You Type". Autrement dit, dans le mode par défaut (avec la fonctionnalité activée), l'éditeur rechargera périodiquement le volet d'aperçu avec le code de l'éditeur, parfois au milieu de la saisie. Cela constitue généralement une expérience d'édition supérieure - sans changer ce que nous faisons, nous pouvons voir le résultat de notre code immédiatement pendant que nous édits, et cette boucle de rétroaction serrée est idéale pour le développement.
Cependant, dans certains cas, en particulier lors de l'écriture de JavaScript, cela signifie que l'aperçu recharge au milieu de la saisie, lorsque nous écrivons un JavaScript potentiellement invalide ou buggy. Un tel comportement de buggy que nous pourrions recharger par inadvertance dans le volet d'aperçu est une boucle infinie. Dans certains contextes, par exemple lorsque nous écrivons for(){} et while(){} boucles, nous pouvons créer une boucle infinie au milieu de la saisie de notre programme qui est rechargé dans notre fenêtre d'aperçu, qui, par conception, broie l'intégralité de l'éditeur, et entraîne une perte de données potentielle sur les modifications effectuées dans l'éditeur.
CodeFrame n'est pas le premier éditeur à avoir rencontré cela, et Codepen.io a une approche intéressante de l'instrumentation JavaScript dans un paramètre de rechargement en direct pour empêcher ce comportement. Le problème est difficile car la prévention des boucles infinies dans le cas général est impossible - c'est une variante classique du problème d'arrêt. Dans le cas de Codepen, ils instrument le code JavaScript généré, de sorte que lorsque la même boucle s'exécute en continu pendant plus d'une période de temps ou d'itérations, elle arrête la boucle. C'est une solution pragmatique, quoique inélégante. Glitch, en revanche, ne fait rien pour empêcher les boucles infinies dans les paramètres de rechargement en direct.
J'ai trouvé que, dans la pratique, il est assez rare d'écrire accidentellement le code JavaScript de syntaxe valide qui se traduit également par des boucles infinies. Et pour ces rares cas, CodeFrame a une option pour désactiver le rechargement de type As-You dans l'éditeur. Mais par défaut, CodeFrame suit la priorité de Glitch dans le non-modification ou l'instrumentation JavaScript pour empêcher l'exécution infinie. Si nous rencontrons davantage de cas d'utilisation où cela devient un problème, nous pouvons revoir ce problème.
Un effet secondaire soigné de la simplicité du code que vous pouvez écrire sur CodeFrame (pas d'étape de compilation, pas de regroupement) est que la sortie que vous obtenez dans une page HTML d'aperçu est mot pour mot. Ainsi, plutôt que d'ajouter explicitement un bouton "Exporter" ou un élément de menu, l'utilisateur peut simplement ouvrir l'aperçu et enregistrer le document HTML lui-même pour "exporter" tous les frames de code qu'ils ont créés.
Si vous aimez utiliser CodeFrame et que vous souhaitez soutenir ce que je fais à l'avenir, veuillez envisager de faire un don à CodeFrame via PayPal ou Venmo.
Alternativement, veuillez envisager de faire un don à certaines des meilleures organisations à but non lucratif faisant un excellent travail dans l'espace d'éducation CS, Khanacademy, Hack Club et Stutech.
