Dies ist der Open-Source-Webclient von Scratch! Dies ist der Code für einen Großteil der Scratch-Website.
Diese Codebasis umfasst insbesondere Code für:
Das Scratch-WWW-Projekt weist viele Aspekte seines Designs auf, die speziell für unsere Backend-Systeme gelten. Um es für Ihr eigenes Projekt zu verwenden, müssten Sie sich alle Orte ansehen, an denen es Backend-Aufrufe durchführt, und Ihre eigenen Backend-Systeme erstellen, um diese Funktionen auszuführen.
Das Scratch-GUI-Projekt hingegen ist so konzipiert, dass es von jedem genutzt werden kann, ohne dass Backend-Systeme erstellt werden müssen, es kann jedoch auch Backend-Systeme zum Speichern von Projekten und Assets unterstützen.
Wir freuen uns über Ihre Beiträge zu dieser Codebasis! Möglicherweise möchten Sie damit beginnen, die aktuelle Liste der offenen Probleme mit der Bezeichnung „Hilfe gesucht“ zu durchsuchen.
Bei Scratch-WWW mitzuwirken kann schwieriger sein als bei Scratch-GUI. Dies liegt daran, dass Scratch-GUI alleine ausgeführt werden kann, ohne dass andere Dienste ausgeführt werden müssen, während Scratch-WWW mit mehreren Backend-Systemen kommunizieren muss, die das Scratch-Team ausführt (siehe „Wie dies mit anderen Scratch-Repos zusammenpasst“) über). Wenn Sie zum ersten Mal am Quellcode von Scratch mitwirken, empfehlen wir Ihnen, sich zunächst mit Scratch-GUI und seiner Liste offener Probleme mit der Bezeichnung „Hilfe gesucht“ vertraut zu machen.
Um einen Beitrag zu leisten, befolgen Sie bitte die Standardschritte für den Beitrag zu einem Projekt auf GitHub.
Siehe die LICENSE-Datei in diesem Repo.
Hier sind einige Ressourcen, die Ihnen helfen sollen, sich mit unserer Arbeit an der Scratch-Codebasis vertraut zu machen:
Zu den wichtigen Kerntechnologien, die diese Codebasis verwendet, gehören:
Unsere Tests verwenden:
Stellen Sie sicher, dass Sie Folgendes installiert haben:
Es ist wichtig sicherzustellen, dass alle Abhängigkeiten auf dem neuesten Stand sind, da der Scratch-WWW-Code nur mit bestimmten Versionen der Abhängigkeiten funktioniert. Sie können die Pakete mit dem folgenden Befehl aktualisieren:
npm install
Diese Warnungen können getrost ignoriert werden:
npm WARN [email protected] requires a peer of react@^0.14.0 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.0 but none was installed.
npm WARN [email protected] requires a peer of redux@^2.0.0 || ^3.0.0 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.7 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.8 but none was installed.
Diese sind derzeit in static/js/lib vorhanden.
Um den Quellcode in HTML- und JavaScript-Bundles zu kompilieren, die von Browsern gelesen werden können, können Sie eine temporäre Version der Website auf Ihrem Computer erstellen, auf die Sie über Ihren Webbrowser zugreifen können.
Sie können die Site entweder einmalig „erstellen“, indem Sie Folgendes ausführen:
npm run build
Oder Sie können einen Server ausführen, der die Dateien neu aufbaut, während Sie sie bearbeiten, indem Sie die folgenden Befehle ausführen:
npm run translate
npm start
HINWEIS: npm run translate
erstellt das intl-Verzeichnis. Die Site lässt sich auch ohne sie gut erstellen, aber übersetzbare Textzeichenfolgen werden erst dann korrekt angezeigt, wenn Sie die integrierte Version erstellt haben.
Während der Entwicklung überwacht npm start
alle Aktualisierungen, die Sie an Dateien in ./static
oder ./src
vornehmen, und löst eine Neuerstellung des Projekts aus. In der Entwicklung wird der Build im Speicher gespeichert und nicht aus dem Verzeichnis ./build
bereitgestellt.
Sobald Sie die lokale Site entweder mit npm run build
oder npm start
erstellt haben, kann ein Webbrowser auf die auf Ihrem lokalen Computer gehostete Site zugreifen, indem Sie localhost:8333
in die Adressleiste Ihres Browsers eingeben.
Wenn Sie npm start
ausführen, sollten Sie auf die folgenden wichtigen Protokollmeldungen achten:
webpack: bundle is now VALID.
– Das Bundle wurde in den Speicher geladen und ist nun im Browser sichtbar. Dies wird sowohl angezeigt, sobald npm start
die Einrichtung abgeschlossen hat, als auch, sobald von Ihnen an Dateien vorgenommene Aktualisierungen zur Anzeige im Browser neu kompiliert wurden.webpack: bundle is now INVALID.
– Wenn Sie dies sehen, bedeutet das, dass Sie Aktualisierungen an Dateien vorgenommen haben, die noch für die Browseranzeige kompiliert werden. Die Seiten sind weiterhin sichtbar, es werden jedoch noch keine von Ihnen vorgenommenen Aktualisierungen angezeigt. Um den npm start
zu stoppen, der die Site für Ihren Webbrowser verfügbar macht (oben in „To Build“ erstellt), verwenden Sie ^C
(Strg-C) im Terminal.
npm start
kann mit den folgenden Umgebungsvariablen konfiguriert werden, indem sie am Anfang des Befehls vor npm start
festgelegt werden:
Variable | Standard | Beschreibung |
---|---|---|
API_HOST | https://api.scratch.mit.edu | Hostname für API-Anfragen |
ASSET_HOST | https://assets.scratch.mit.edu | Hostname für Asset-Anfragen |
BACKPACK_HOST | https://backpack.scratch.mit.edu | Hostname für Rucksackanfragen |
PROJECT_HOST | https://projects.scratch.mit.edu | Hostname für Projektanfragen |
FALLBACK | '' | Durchgangsstandort für alten Standort |
THUMBNAIL_URI | /internalapi/project/thumbnail/{}/set/ | URI-Vorlage zum Aktualisieren von Projektminiaturansichten, {} wird beim Aufrufen einer Anfrage durch die Projekt-ID ersetzt |
THUMBNAIL_HOST | '' | Hostname für den Uploader-Dienst |
GTM_ID | '' | Google Tag Manager-ID |
GTM_ENV_AUTH | '' | Google Tag Manager-Umgebungs- und Authentifizierungsinformationen |
NODE_ENV | null | Wenn es sich nicht um production handelt, verhält sich die App wie eine Entwicklung |
PORT | 8333 | Port für Devserver (http://localhost:XXXX) |
HINWEIS: Da standardmäßig API_HOST=https://api.scratch.mit.edu
gilt, beachten Sie bitte, dass Sie auf der Scratch-Website standardmäßig echte Daten sehen und mit ihnen interagieren.
Die meisten unserer Unit-Tests werden mit Jest ausgeführt, ältere Unit-Tests verwenden jedoch das TAP-Framework.
Um die Anwendung zu erstellen und alle Unit- und Lokalisierungstests auszuführen, verwenden Sie den folgenden Befehl:
npm test
Um eine einzelne Unit-Test-Datei über die Befehlszeile mit Jest auszuführen, verwenden Sie den folgenden Befehl:
node_modules/.bin/jest ./test/unit/PATH/TO/FILENAME.test.js
HINWEIS: Ersetzen Sie PATH/TO/FILENAME
durch den tatsächlichen Pfad zu der Datei, die Sie ausführen möchten.
Bei unseren Integrationstests wird davon ausgegangen, dass eine größere Umgebung als nur Scratch-www allein ausgeführt wird. Viele verlangen beispielsweise, dass sich ein Testbenutzer bei der Site anmelden kann, was Backend- und Datenbankunterstützung erfordert.
Standardmäßig werden Tests für unsere Staging-Instanz ausgeführt. Sie können jedoch mit der Umgebungsvariablen ROOT_URL (siehe unten) einen anderen Speicherort übergeben, wenn Sie die Tests für einen anderen Speicherort ausführen möchten – beispielsweise Ihren lokalen Build.
Alle unsere Integrationstests verwenden Jest als Testframework.
So führen Sie alle Integrationstests über die Befehlszeile aus:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu UNOWNED_SHARED_PROJECT_ID= # UNOWNED_UNSHARED_PROJECT_ID=# OWNED_SHARED_PROJECT_ID=# OWNED_UNSHARED_PROJECT_ID=# npm run test:integration
Bei den Tests werden mehrere Benutzer mit ähnlichen Benutzernamen und demselben Passwort verwendet. Sie verwenden den Benutzernamen, den Sie mit SMOKE_USERNAME übergeben, sowie denselben Benutzernamen mit einer 1, 2, 3, 4, 5 und 6 (bald auch höhere Zahlen) am Ende. Wenn Sie also den Benutzernamen „test“ verwenden, werden auch die Benutzernamen „test1“, „test2“, „test3“ usw. verwendet. Stellen Sie sicher, dass Sie Konten mit diesem Muster erstellt haben und verwenden Sie für alle beteiligten Konten dasselbe Passwort.
Sie können jeden Satz von Benutzernamen verwenden, der diesem Muster entspricht. Jedes Konto muss dasselbe Passwort haben, das als SMOKE_PASSWORD übergeben wird.
Damit die Tests ausgeführt werden können, müssen mehrere Umgebungsvariablen übergeben werden. Die meisten von ihnen verfügen über Standardeinstellungen, die auf den Staging-Server verweisen.
So führen Sie eine einzelne Datei über die Befehlszeile mit Jest aus:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu node_modules/.bin/jest ./test/integration/filename.test.js
So führen Sie eine einzelne Datei über die Befehlszeile mit TAP aus:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu node_modules/.bin/tap ./test/integration-legacy/smoke-testing/filename.js -R classic --no-coverage --timeout=3600
-R classic
sorgt dafür, dass tap den alten Berichtsstil verwendet, wodurch ein Fehler mit dem Paket „nyc“ vermieden wird--no-coverage
liegt daran, dass wir die Coverage-Tracking-Funktion von tap nicht verwendentimeout
Argument gilt für die Länge der gesamten Tap-Testsuite; Wenn Sie einen Timeout-Fehler erhalten, müssen Sie diesen Wert möglicherweise anpassen (die Ausführung einiger Selenium-Tests dauert eine Weile). Integrationstests können mit Saucelabs durchgeführt werden, einem Onlinedienst, der mehrere Browser-/Betriebssystemkombinationen aus der Ferne testen kann. (Derzeit sind alle Tests für die Verwendung für Chrome auf dem Mac geschrieben).
Sie benötigen ein Saucelabs-Konto, um es zum Testen verwenden zu können. Wenn Sie einen haben, finden Sie Ihren Zugangsschlüssel:
Um Tests mit Saucelabs auszuführen, führen Sie den folgenden Befehl aus:
SMOKE_USERNAME=username SMOKE_PASSWORD=password SAUCE_USERNAME=saucelabsUsername SAUCE_ACCESS_KEY=saucelabsAccessKey ROOT_URL=https://scratch.mit.edu npm run test:integration:remote
HINWEIS: Derzeit können Jest-Tests nicht mit Saucelabs ausgeführt werden.
Variable | Standard | Beschreibung |
---|---|---|
ROOT_URL | scratch.ly | Standort, an dem Sie die Tests ausführen möchten |
SMOKE_USERNAME | None | Benutzername des Scratch-Benutzers, mit dem Sie sich zum Testen anmelden |
SMOKE_PASSWORD | None | Passwort für den Scratch-Benutzer, mit dem Sie sich zum Testen anmelden |
SMOKE_REMOTE | false | Tests mit Sauce Labs hin oder her. True, wenn test:smoke:sauce ausgeführt wird |
SMOKE_HEADLESS | false | Führen Sie den Browser im Headless-Modus aus. Im Moment flockig |
SAUCE_USERNAME | None | Benutzername für Ihr Sauce Labs-Konto |
SAUCE_ACCESS_KEY | None | Den Zugriffsschlüssel für Sauce Labs finden Sie unter Benutzereinstellungen |
Bei der Bereitstellung im Staging oder in der Produktion wird Code auf S3 hochgeladen und Fastly konfiguriert.
npm install
virtualenv ENV
. ENV/bin/activate
pip install -r requirements.txt
npm run build && npm run deploy
Variable | Standard | Beschreibung |
---|---|---|
FASTLY_SERVICE_ID | '' | Fastly-Service-ID für bin/configure-fastly.js |
FASTLY_API_KEY | '' | Fastly-API-Schlüssel für bin/configure-fastly.js |
FASTLY_ACTIVATE_CHANGES | false | Aktivieren Sie die Änderungen und löschen Sie alles nach der Konfiguration |
AWS_ACCESS_KEY_ID | '' | AWS-Zugriffsschlüssel-ID für S3 |
AWS_SECRET_ACCESS_KEY | '' | Geheimer AWS-Zugriffsschlüssel für S3 |
S3_BUCKET_NAME | '' | S3-Bucket-Name für die Bereitstellung |
Bei der Bereitstellung wird die API von Fastly verwendet, um die aktive VCL-Konfiguration zu klonen, nur die relevante Komponente mit Inhalten aus der routes.json
Datei dieses Repos zu aktualisieren und die neue VCL-Konfiguration zu aktivieren.
Ein Großteil der Datei „routes.json“ ist unkompliziert, aber bei einigen Feldern ist ihr Zweck nicht offensichtlich.
routeAlias
hilft uns, zu verhindern, dass die Gesamtlänge und Komplexität des Regex-Vergleichscodes in Fastly zu groß wird. Es gibt einen großen regulären Ausdruck, mit dem wir die eingehende Anforderungs-URL fastly testen lassen, um festzustellen, ob er mit einer statischen Datei in S3 antworten kann. Wenn keine Übereinstimmung gefunden wird, gehen wir davon aus, dass wir die Anfrage an Scratchr2 weiterleiten müssen. Wir könnten jede einzelne pattern
Regex in routes.json
testen, aber viele sind ähnlich, also nehmen wir stattdessen einfach den eindeutigen Satz aller routeAlias
Einträge, der kürzer und schneller ist.
Für die Entwicklung unter Windows müssen Sie wahrscheinlich ein Programm verwenden, das Ihnen eine Unix-Schnittstelle bietet.
Hierfür gibt es mehrere Möglichkeiten:
Darüber hinaus müssen Sie Node installieren. Hier finden Sie Anweisungen zur Installation von Node auf WSL.
Wir sind derzeit dabei, die bestehende Struktur von Scratch auf diesen Web-Client umzustellen. Beim Übergang wird es einige Probleme geben, die sich darauf beziehen, wie dieser Kunde mit der vorhandenen Infrastruktur interagieren muss, um in der Produktion ordnungsgemäß zu funktionieren.
Neben der Umstellung auf die Verwendung als Webclient stellt Scratch auch auf die Verwendung eines neuen API-Backends um, der Scratch REST API (Closed-Source). Da sich auch dieser derzeit in der Entwicklung befindet und noch unvollständig ist, sind wir darauf eingestellt, auf die Verwendung vorhandener Scratch-Endpunkte zurückzugreifen, wenn kein API-Endpunkt vorhanden ist – und hier kommt der FALLBACK
ins Spiel.
Die meisten Probleme, die wir derzeit haben, drehen sich um die Verwendung von FALLBACK
. Diese Variable wird verwendet, um anzugeben, auf welche URL zurückgegriffen werden soll, falls eine Anfrage im Kontext dieses Webclients oder bei Verwendung von API_HOST
fehlschlägt. Wenn es im Prozess nicht angegeben wird, wird es nicht verwendet und jede Anfrage, die nicht über den Webclient oder die API gestellt wird, ist nicht erreichbar.
Wenn Sie FALLBACK=https://scratch.mit.edu
festlegen, kann der Webclient Daten von der Scratch-Website in Ihrer Entwicklungsumgebung abrufen. Aus Sicherheitsgründen funktioniert der Versuch, Daten über Ihre Entwicklungsumgebung an Scratch zu senden, jedoch nicht. Das bedeutet, dass folgende Dinge vorerst kaputt sein werden:
Wenn Sie außerdem FALLBACK=https://scratch.mit.edu
festlegen, beachten Sie, dass Sie durch Klicken auf Links zu Teilen der Website, die noch nicht migriert wurden (derzeit z. B. Discuss
, Profile
, My Stuff
“ usw.), dorthin gelangen die Scratch-Website selbst.