Zur Nutzungsanleitung springen
Component Canvasvon ibelick

Component Canvas Skill.

Prüfen Sie echte UI-Komponenten und Varianten auf einer schwenk- und zoombaren Zeichenfläche.

  • Komponentenvarianten
  • Vergleich
Quellprüfung · component-canvasSKILL.md
Aufgabe Prüfen Sie echte UI-Komponenten und Varianten auf einer schwenk- und zoombaren Zeichenfläche. Ergebnisse Eine isolierte Canvas-Route oder ein Einstiegspunkt mit den gewünschten Komponenten. Vor dem Start Damit eine Vorschau funktioniert, dürfen Komponentenquellcode, Hooks oder Stile nicht verändert werden.
Redaktionelle Zusammenfassung · Quelle geprüft am 2026-11-02 · kein generiertes Beispiel

01 Funktionen

Prüfen Sie echte UI-Komponenten und Varianten auf einer schwenk- und zoombaren Zeichenfläche

Erstellen Sie eine isolierte Zeichenfläche für bestehende Komponenten, vergleichen Sie Varianten und bewahren Sie echtes Tastatur-, Portal- und Eingabeverhalten.

Quellenbasierter WorkflowKein Ausführungs-Benchmark

Die Arbeitsweise

Component Canvas baut eine bildschirmfüllende Prüffläche um bereits im Projekt vorhandene Komponenten. Unterstützte Varianten und sinnvolle Zustände werden gruppiert, damit Designer sie auf einen Blick vergleichen und anschließend die echten Bedienelemente bedienen können. Die Quelle hält die Komponentenimplementierung unabhängig von der Zeichenfläche.

Der Ablauf legt genau fest, was Vergleichen bedeutet. Beim Größenvergleich bleiben Text, Stil und Daten konstant; beim Stilvergleich ändert sich nur der Stil. Native Portale, Fokus und verschachteltes Scrollen bleiben erhalten. Eine nützliche Vorschau muss daher mehr leisten als einen Screenshot ihres Ausgangszustands.

Erwartete Ergebnisse

  • Eine isolierte Canvas-Route oder ein Einstiegspunkt mit den gewünschten Komponenten.
  • Benannte Variantengruppen mit dokumentierter Abdeckung und begründeten Auslassungen.
  • Ein Bericht über geänderte Dateien, ausgeführte Prüfungen, Entscheidungen und ungetestetes Verhalten.
Beispiel-Briefing ansehen

Vom Briefing zur Prüfung

  1. 01
    Ein sicheres Beispiel einbinden

    Lesen Sie öffentliche Komponenten-APIs und Projektkonventionen. Verhindern Sie mit Testdaten, Mocks oder bestehenden Callbacks echte Schreibzugriffe, bevor Sie eine einzelne Komponente einbinden.

  2. 02
    Vergleichbare Gruppen aufbauen

    Ergänzen Sie unterstützte Varianten in konsistenten Gruppen. Ändern Sie jeweils nur eine Vergleichsdimension und bewahren Sie das echte Verhalten im deaktivierten, fokussierten und interaktiven Zustand.

  3. 03
    Die Zeichenfläche um die Komponenten prüfen

    Testen Sie Schwenken, Zoom, Einpassen und Tastaturnavigation zusammen mit verschachteltem Scrollen und nativem Portalverhalten. Speichern Sie nur die Kamera dauerhaft und bestätigen Sie, dass Zurücksetzen den Vorschauzustand erhält.

02 Einsatzbereiche

Wann einsetzen?

Damit eine Vorschau funktioniert, dürfen Komponentenquellcode, Hooks oder Stile nicht verändert werden.

Gut geeignet

  • VariantenprüfungVergleichen Sie Buttons, Eingabefelder und andere bestehende Komponenten über ihre echten öffentlichen APIs.
  • KomponentenreviewGeben Sie Designern einen Ort, um unterstützte Zustände zu testen, ohne Produktionsimplementierungen zu ändern.

Zu prüfende Grenzen

  • Komponenten bleiben unverändertDamit eine Vorschau funktioniert, dürfen Komponentenquellcode, Hooks oder Stile nicht verändert werden.
  • Begrenzter ArbeitsbereichGruppen lassen sich nicht ziehen; die Zeichenfläche hat weder Bearbeitungsverlauf noch Rückgängig/Wiederholen.
  • Sichere TestdatenEin interaktives Beispiel wird ausgelassen, wenn Produktionsaufrufe und Schreibzugriffe nicht sicher isoliert werden können.

Diese Eingaben mitbringen

  • KomponentenumfangBenennen Sie die einzubeziehenden Komponenten und öffentlichen Varianten.
  • TestdatenkonfigurationStellen Sie sichere Daten, Provider und Callbacks für interaktive Beispiele bereit.
  • ProjektkonventionenVerwenden Sie bestehende Routen, Theme-APIs, Abhängigkeiten und Zugriffskontrollen.

03 Wichtige Entscheidungen

Wichtige Entscheidungen

  1. Echtes Verhalten

    Beispiele reagieren auf native Zeiger- und Tastaturinteraktion.

  2. Faire Vergleiche

    Konstante übrige Eigenschaften zeigen, was eine Variante tatsächlich verändert.

  3. Abgegrenzte Implementierung

    Kamera- und Layoutlogik bleiben vom Komponentenquellcode getrennt.

04 Beispielbriefing

Ein konkretes Briefing ausprobieren

Das folgende Beispiel-Briefing wurde nicht getestet. Prüfen Sie die Einrichtung des Skills, bevor Sie es verwenden.

Quelle und Einrichtung prüfen

Benennen Sie die einzubeziehenden Komponenten und öffentlichen Varianten.

Upstream-Quelldatei
https://github.com/ibelick/ui-skills/blob/4907a526b07943b3a338177558d42fae4fdf0a86/skills/component-canvas/SKILL.md

Der folgende Verweis öffnet die Originalanleitung. Prüfe vor der Nutzung die Einrichtung des Repositorys; dies ist kein Installationsbefehl.

Mit einem Ergebnis beginnen

Passen Sie Umfang, Quellmaterial und Rahmenbedingungen in diesem Briefing an, bevor Sie den Skill ausführen.

Beispiel-Briefing
Verwende component-canvas, um unsere vorhandenen Komponenten Button, Select und Dialog zu prüfen. Lies ihre öffentlichen APIs und zeige die unterstützten benannten Varianten mit Testdaten. Vergleiche jeweils nur eine Eigenschaft und halte Beschriftungen und andere Einstellungen konstant. Lass den Komponentenquellcode unverändert und nutze den aktuellen Theme-Provider. Beginne mit einem sicheren Beispiel und ergänze dann die übrigen Gruppen. Prüfe Tastatureingabe, Fokus, verschachteltes Scrollen und Portalposition bei mehreren Zoomstufen. Berichte über ausgelassene Fälle und Prüfungen, die nicht verfügbare Geräte erfordern.

Ergebnis prüfen

Prüfen Sie die tatsächliche Ausgabe anhand dieser beobachtbaren Kriterien.

  • Der Komponentenquellcode hat keine Änderungen, und Testdaten verursachen keine echten Schreibzugriffe.
  • Portalausrichtung, Fokus und native Eingabe bleiben beim Zoomen nutzbar.
  • Die Kameraposition wird nach dem Neuladen wiederhergestellt; Zurücksetzen erhält den aktuellen Vorschauzustand. Vorschauentwürfe nach einem Neuladen sind nicht garantiert, und Speicherfehler werden sicher abgefangen.

OpenDesign bietet einen lokalen Design-Arbeitsbereich für Coding-Agenten. Dieser Eintrag bedeutet nicht, dass der Skill mitgeliefert wird oder dass seine externen Tools, Zugangsdaten und Software-Abhängigkeiten enthalten sind.

05 Quelle und Lizenz

Quelle und Lizenz

Diese Seite beschreibt die unten verlinkte, festgelegte Quellrevision. Verhalten und Anforderungen im Upstream können sich ändern.

Quellinhaber
ibelick
Skill-Datei
SKILL.md
Lizenz
MIT
Geprüfter Stand
2026-11-02 · 4907a526b079
Redaktionelle Quellenzusammenfassung
Prüfen Sie echte UI-Komponenten und Varianten auf einer schwenk- und zoombaren Zeichenfläche.

Originalzusammenfassung von OpenDesign auf Grundlage der verlinkten Quelle. Repository-Sterne sind ein datiertes Popularitätssignal, keine Skill-Nutzung und keine Qualitätsbewertung.

06 Fragen vor dem Start

Fragen vor dem Start

Kann ich Komponentengruppen ziehen?

Die Quelle hält Gruppen ausdrücklich fest. Schwenken und Zoomen bewegen stattdessen die Kamera.

Erfindet der Skill fehlende Komponentenvarianten?

Nein. Er liest die öffentliche API und listet ausgelassene Fälle auf, statt eine Komponente für vorgetäuschte Unterstützung zu verändern.

Was bleibt nach einem Neuladen erhalten?

Die vorgegebene Persistenz speichert die Kamera. Vorschauentwürfe müssen das Neuladen nur überstehen, wenn dies gesondert verlangt wird.

OpenDesign

Briefing und Designarbeit an einem Ort.

Halten Sie Briefing, Quellmaterial und Designarbeit in einem lokalen Arbeitsbereich zusammen. Prüfen Sie die Einrichtung des Skills, bevor Sie ihn in Ihren Workflow aufnehmen.

Upstream-Quelldatei
https://github.com/ibelick/ui-skills/blob/4907a526b07943b3a338177558d42fae4fdf0a86/skills/component-canvas/SKILL.md