Storybook: Einzelne Geschichten ziehen die Stylesheets aller anderen Geschichten ein?

Außerdem sendet Webpack all diese Geschichten aus. Ich frage mich also, ob ich das Webpack so konfiguriert habe.

Ich habe auch versucht, einen Dekorateur zu verwenden, und dies war halb kaputt, da ich zumindest das zusätzliche Stylesheet zur Geschichte isolieren konnte, aber als ich andere durchquerte, brachen diese Stile, wenn ich nicht eine harte Aktualisierung durchführte.

.addDecorator((getStory) => {
  require('./story.sass');
  return getStory();
})

@arunoda @mnmtanish

Interessant! Haben Sie ein Repo, das dies demonstriert?

@ndelangen wird in

@ndelangen https://github.com/moimikey/729-single-stories-pulling-all-stylesheets

Ich versuche immer noch, die Zeit zu finden, um das herauszufinden.

danke; D es ist komisch. Ich habe es mir angesehen, bin mir aber nicht sicher, wo ich anfangen soll.

Ich denke also, dass alle CSS-Dateien vom Webpack Style-Loader aufgenommen und einfach in den Kopf gespritzt werden. ob sie verwendet werden oder nicht.

Aber wie kann man das beheben?

Was ich für mein CSS getan habe, ist die Verwendung von CSS-Modulen. und importiere die generierten Klassennamen in mein JS. Selbst wenn alles CSS zusammen in den Kopf injiziert wird, spielt es keine Rolle, da es garantiert eindeutige Klassen / Selektoren sind.

Es löst nicht wirklich das genaue Problem, das Sie haben. Aber ich denke, das ist das beabsichtigte Verhalten des Style-Loaders.

Das ist wahr. Ich (und meine Firma) arbeiten mit CSS, aber wir führen eine große Code-Neuentwicklung durch, daher haben wir gemeinsame Stile, also eine Kombination aus styleName und className . Was sich also letztendlich auf das Storybook auswirkt, sind diese "Außenseiter" -Css-Dateien.

Ich werde heute Abend noch einmal in den Storybook-Code schauen, nachdem ich ein paar Biere getrunken habe, und herausfinden, wie ich das vielleicht in Bezug auf die Implementierung lösen kann.

@moimikey für Ihr Problem Ich denke, Sie müssen den Style-Loader überspringen und CSS-Dateien manuell mit einem Dekorateur laden. So etwas vielleicht:

.addDecorator(getStory => (
  <div>
    <link ... />
    {getStory()}
  </div>
))

Wow ... das ist mir nie in den Sinn gekommen ... das werde ich versuchen.

ick aber andererseits mit sass ... x_x. Ich habe sogar versucht, eine Inline-Anforderung. aber ich hatte nicht viel glück. das wäre aber eine exzellente lösung für direktes css :)

also @mnmtanish. Danke für deine Beratung. Ich habe mein Problem mit Ihrer Inspiration gelöst:

.addDecorator((getStory) => {
  require('./story.sass');
  return getStory();
})

mmm, das einzige Problem ist jetzt, dass beim Navigieren von Geschichte zu Geschichte die Stile gestapelt werden :(

Möglicherweise kann der Style Loader so konfiguriert werden, dass er an einer anderen Stelle als HEAD eingefügt wird, damit er entfernt werden kann. Ich habe das nicht getan, bin mir also nicht sicher, ob es überhaupt möglich ist. Schauen Sie sich diese an.

Ist es nicht die Verantwortung von React Storybook, die Komponente vollständig isoliert zu laden und daher nur JavaScript / CSS auszuführen, das sich auf die aktuell ausgewählte Story bezieht?

Bezieht sich das auf https://github.com/storybooks/react-storybook/issues/686?

@ ConneXNL ja. guter Punkt. das ist wahr ...; X.

@mnmtanish Meine nächste Antwort führt natürlich zu einem anderen Problem: insertAt könnte nützlich sein, aber es ist nur in der neuesten Version von style-loader verfügbar, die mit Storybook nicht verwendet werden kann, da sie verwendet wird [email protected] . Storybook verwendet immer noch 0.x . Die neueste mögliche Version, die wir verwenden können, ist [email protected] : (...

Hey @moimikey, vielleicht kannst du den Ansatz ausprobieren, der zuletzt mit der Alpha-Version erwähnt wurde?

Ist es nicht besser / sicherer, beim Wechseln von Storys ein neues Iframe-Element zu erstellen?

Das wäre sicher und auch schlecht für die Leistung.

Der neue Iframe müsste das Javascript analysieren, das CSS analysieren, eine Verbindung zum Postmessage-Kanal herstellen, die Verbindung zum Websocket wiederherstellen und wahrscheinlich mehr.

Vielleicht reicht es aus, <style> Elemente auf dem Story-Switch zu entfernen, um dieses Problem zu beheben?

Natürlich gibt es keine globalen Stile und alles ist richtig benannt, dies wäre kein Problem. Wunschdenken, denke ich. 😃

Wenn jemand beweisen kann, dass die obigen Aussagen falsch sind oder keine negativen Konsequenzen haben, bin ich ganz Ohr!

Ich habe heute einige Tests gemacht. Das Dekorationsmuster hat gut funktioniert, sodass Stile erst dann eingefügt werden, wenn Sie zur Geschichte wechseln. Ich hatte jedoch das gleiche Problem, bei dem die Stile beim Wechseln von Storys nicht entfernt wurden.

Ich habe mit dem Entfernen von Stilen in einem Dekorateur herumgespielt, aber es scheint, dass der erforderliche Stil nur einmal angewendet wird. Ist es möglich, ein require () erneut auszulösen? Ich habe versucht, Singleton: false zu verwenden, aber das hat das Problem nicht behoben.

Ich zögere fast, dies überhaupt vorzuschlagen, aber Sie könnten versuchen, den Webpack-Cache zu sprengen:
https://webpack.github.io/docs/api-in-modules.html#advanced

Dies ist Webpack 1-Dokumentation, funktioniert aber möglicherweise immer noch.

Idee: Sie könnten einen Dekorateur schreiben, der beim Wechseln von Geschichten alle <style>...</style> . Um die Stile zu bereinigen, die für die aktuelle Geschichte nicht relevant sind.

Ich bin fast da. In der Webpack-Konfiguration verwende ich
'style-loader/useable' instead of 'style-loader',

Dadurch wird eine API hinzugefügt, mit der Sie arbeiten können. .use (), um die Stile hinzuzufügen, unuse (), um sie zu entfernen. In meiner Story-Datei verwende ich den Dekorateur wie folgt:

.addDecorator((c) => <ReactStylesheet stylesheets={[require('./stories.scss')]}>{ c() }</ReactStylesheet> )

Verwenden der folgenden Reaktionskomponente zum Hinzufügen und Entfernen der Stile.

import * als Reagieren von 'reagieren';

export class ReactStylesheet extends React.Component{

    componentWillUnmount(){
        let stylesheets = Array.isArray(this.props.stylesheets) ? this.props.stylesheets : [this.props.stylesheets];
        stylesheets.forEach((stylesheet) => {
            console.log("Unmounting....");
            stylesheet.unuse();
        });

    }

    componentDidMount(){
         let stylesheets = Array.isArray(this.props.stylesheets) ? this.props.stylesheets : [this.props.stylesheets];
        stylesheets.forEach((stylesheet) => {
            console.log("Mounting....");
            stylesheet.use();
        });
    }

    render(){
        return this.props.children;
    }
}

Durch korrektes Ändern des Stylesheets werden die Styles neu geladen. Das Wechseln zu einer anderen Story unuse () wird aufgerufen und die Stylesheets werden bereinigt. Die Methode bricht jedoch ab, wenn die Stile erneut hinzugefügt werden, da die nicht hrm-aktualisierte Version des Stylesheets angezeigt wird. Wenn Sie danach Änderungen vornehmen, wird auch der folgende Fehler ausgelöst:

Uncaught (in promise) TypeError: Cannot read property 'refs' of undefined
    at update (webpack:///./~/style-loader/addStyles.js?:63:4)
    at eval (webpack:///./src/Component/stories.scss?:32:4)
    at Object.hotApply [as apply] (http://dev.test:6006/static/preview.bundle.js:499:14)
    at cb (webpack:///(webpack)-hot-middleware/process-update.js?:52:36)
    at eval (webpack:///(webpack)-hot-middleware/process-update.js?:68:13)
    at <anonymous>

Ich bin nicht sicher, wie ich die require-Anweisung aktualisieren soll, um auf die neueste HRM-Version zu verweisen.

Fantastische Ermittlungsarbeit! Ich habe mich vorher nach so etwas umgesehen und konnte es nicht finden.

Was können wir auf dieser Seite tun, um

Die Lösungen rücken näher. Die Idee von stylesheet.use() und unuse war mir fremd, aber dies scheint auf dem richtigen Weg zu sein.

Dies ist auch eine weitere interessante Sache für das Sandbox-Storybook https://github.com/Wildhoney/ReactShadow

Hallo allerseits! In dieser Ausgabe scheint in letzter Zeit nicht viel los zu sein. Wenn noch Fragen, Kommentare oder Fehler vorliegen, können Sie die Diskussion fortsetzen. Leider haben wir nicht die Zeit, um zu jeder Ausgabe zu gelangen. Wir sind immer offen für Beiträge. Bitte senden Sie uns eine Pull-Anfrage, wenn Sie helfen möchten. Inaktive Ausgaben werden nach 60 Tagen geschlossen. Vielen Dank!

@ConneXNL , um dieses Problem zu

Wenn Sie keinen guten Platz dafür finden, können Sie ihn einfach irgendwo im Markdown-Format ablegen. Ich werde mich darum kümmern, es einzulegen.

🙇

Hallo allerseits! In dieser Ausgabe scheint in letzter Zeit nicht viel los zu sein. Wenn noch Fragen, Kommentare oder Fehler vorliegen, können Sie die Diskussion fortsetzen. Leider haben wir nicht die Zeit, um zu jeder Ausgabe zu gelangen. Wir sind immer offen für Beiträge. Bitte senden Sie uns eine Pull-Anfrage, wenn Sie helfen möchten. Inaktive Ausgaben werden nach 60 Tagen geschlossen. Vielen Dank!

Hey, ich bin es wieder! Ich werde dieses Problem schließen, um unseren Betreuern zu helfen, sich stattdessen auf die aktuelle Entwicklungs-Roadmap zu konzentrieren. Wenn das erwähnte Problem weiterhin ein Problem darstellt, öffnen Sie bitte ein neues Ticket und erwähnen Sie dieses alte. Prost und danke, dass du Storybook benutzt!

Das gleiche Problem hier, Storybook isoliert nicht jede Geschichte, so dass es für visuelle Tests / Abnahmetests unbrauchbar wird.

Das Aufstellen einer Schattenwurzel um Geschichten würde dieses Problem sofort lösen, ohne die Leistungsbedenken von @ndelangen

@bennypowers interessant! Hätten Sie ein Codebeispiel, wie Sie dies erreichen können? 🙇

Könnte auch für sein .

Hallo. Ich habe auch dieses Problem
Wurde dies behoben oder gibt es eine Problemumgehung?

@ndelangen

Der schnellste Weg zur Zufriedenheit ist hier wahrscheinlich @moimikeys Vorschlag, ReactShadow zu verwenden

Die Strategie könnte darin bestehen, das Stammverzeichnis in eine ReactShadow-Komponente zu verpacken und dann die Stile mit adoptedStyleSheets (oder einem <style> -Element für nicht unterstützende Browser) einzufügen.

https://github.com/storybookjs/storybook/blob/ba74d889fcfd87849a6ae9369f5e4176e8149d33/lib/core/src/client/preview/start.js#L253

Bitte öffnen Sie dies erneut. Dieses Problem macht das Hinzufügen von benutzerdefinierten Stilen pro Story äußerst schwierig. Ich habe völlig separate MDX-Storys, die benutzerdefinierte Stile für ihre Beispiele implementieren, und die globale Einbeziehung aller Stile aus jeder Story macht diesen Anwendungsfall unhaltbar.

edit: Danke !!!

Ich hoffe, dass dies bis zum 21. März 2020 gelöst sein wird.

@moimikey Hast du Interesse daran? Der beste Weg, um sicherzustellen, dass es bis zu einem bestimmten Datum fertig ist ... 😉

IMO sollten wir Parameter oder Addons hinzufügen, um diese Funktion zu handhaben, anstatt spezielle Funktionen nur für Stylesheets hinzuzufügen. Dies führt zu inkonsistentem Verhalten zwischen Stylesheets und Skripten. Aber vielleicht ist es ein guter Zeitpunkt, um zu überlegen, wie "Isolation" sein sollte?

Ich habe einen kurzen PoC für den Addon-Ansatz geschrieben, für wen ist es möglich?
https://github.com/pocka/storybook-addon-css

@pocka Du bist super! 💯

yazzzzz. Prost @pocka

Erwähnenswert ist, dass die Lösung von @pocka aufgrund von mdx-js / mdx # 894 nicht funktioniert, wenn Sie MDX-Storys verwenden.

Edit: Mein schlechtes, das tut es definitiv! Sie müssen Style-Loader 1.x + haben und dann so etwas tun:

--- a/components/grid/GridChild.stories.mdx
+++ b/components/grid/GridChild.stories.mdx
@@ -1,7 +1,9 @@
 import { Meta, Story, Preview } from '@storybook/addon-docs/blocks';
 import { GridContainer, GridRow, GridChild } from './';
 import '../../shared/critical-path.scss';
-import 'o-grid/demos/src/scss/_demos.scss';
+import demoStylesModule from '!!style-loader?injectType=lazyStyleTag!css-loader!sass-loader!o-grid/demos/src/scss/_demos.scss?story';
+
+export const demoStyles = Promise.resolve(demoStylesModule);

 <Meta title="Core|Grid/GridChild" component={GridChild} />

@@ -37,7 +39,12 @@ You supply it a `colspan` prop in one of the following formats:
     ```

 <Preview>
-  <Story name="Default unresponsive columns">
+  <Story
+    name="Default unresponsive columns"
+    parameters={{
+      styles: [demoStyles],
+    }}
+  >
     <GridContainer>
       <GridRow>
         <GridChild colspan="1">

@aendrew
Vielen Dank für den Hinweis, dass ich MDX komplett vergessen habe: no_mouth:
Ich habe PoC aktualisiert und MDX-Beispiele hinzugefügt .

Beim Addon-Ansatz (pro Story-Stil) werden im Gegensatz zum File-Scoping-Ansatz (pro Dateistil) auf der Registerkarte "Dokumente" alle Stylesheets für jede Story abgerufen. In meinem Beispiel importieren "foo" - und "baz" -Storys foo.css und "bar" -Storys bar.css , dann erhält die Registerkarte "Dokumente" sowohl foo.css als auch bar.css . Ich denke, das ist unvermeidlich und ich weiß nicht, ob das akzeptabel ist oder nicht.

@pocka Ich denke, dieser Ansatz könnte mit https://github.com/storybookjs/storybook/tree/next/addons/cssresources WDYT gut funktionieren.

@ndelangen
Ah, das stimmt!

foo.story = {
  parameters: {
    cssresources: [
      {
        id: 'foo',
        code: `<style>${require('!to-string-loader!css-loader!./foo.css')}</style>`,
        picked: true
      }
    ]
  }
}

Ein Problem: Wenn ein Benutzer sehr große Stylesheets importiert, ist die Registerkarte "CSS-Ressourcen" unübersichtlich.

@pocka richtig, ich denke, das cssresources-Addon kann in dieser Abteilung erheblich verbessert werden. Hast du Lust, das anzunehmen?

@ndelangen
Ja: Smiley:

Was halten Sie übrigens davon, dass Benutzer Raw-Webpack-Abfragen schreiben können? (wie !to-string-loader!... ) Ich denke, wir brauchen viel schwarze Magie im Addon-Code, wenn wir das loswerden wollen ...

Ich denke, wir unterstützen standardmäßig Babel-Makros, sodass Benutzer möglicherweise Makro-Prävalenz verwenden , um auch Dateiinhalte in das Bundle

Das wusste ich nicht, ich werde es mir bald ansehen!

Hallo, ich habe das gleiche Problem.

Versuchen Sie diese Problemumgehung, wenn Sie mit dem Problem konfrontiert sind. (Es braucht allerdings ein wenig tiefes Webpack-Wissen).

@ndelangen Ich habe mir das Makro angesehen, aber es ermöglicht "Laden von CSS-Dateien aus dem Dateisystem", richtig? Ich denke, viele Benutzer möchten SASS-, Less-, Stylus-, CSS-Dateien mit PostCSS usw. importieren, damit dieser Ansatz die Anforderungen nicht erfüllt. Meine aktuelle Idee ist das CSSResource-Addon, das eine Regel hinzufügt, die eine CSS-Datei mit to-string-loader (oder file-loader ) importiert, damit der Benutzer eine CSS-Datei importieren und diese dann für das Addon verwenden kann.

// adding a rule like this
{
  test: /\.css$/,
  resourceQuery: /cssresources/,
  use: ['to-string-loader', 'css-loader', 'postcss-loader']
}

Für Vorprozessoren ist auch eine Option zum Anpassen von test und use erforderlich. Es ist möglich, eine Regel für eine Stildatei auszuwählen und sie dann mit oneOf ändern, aber es wäre so kompliziert ...

Was denken Sie?

@pocka ja das klingt nach einem interessanten

Hallo, fragst du dich, ob daran noch gearbeitet wird? Ich habe auch das Problem, bin mir der Problemumgehung bewusst, möchte aber wissen, ob in Kürze ein Fix verfügbar sein wird.

Hallo, können Sie ein Beispiel für die Problemumgehung mit einer Vue-Story geben?

Soweit ich das beurteilen kann, führt

Da keine Respektlosigkeit beabsichtigt ist, fehlt mir der Addon-Ansatz von import './Button.css' innerhalb von Button.jsx , das nur in Story-Dateien verwendet wird, in denen Button.jsx wird importiert. Per-Story-Styling, wie es @pocka bereitgestellt hat, ist für mich bei Button (direkt oder indirekt) importiert, davon betroffen ist Alle CSS-Regeln ab Button.css . (Die Sorge hier ist, dass sichergestellt werden soll, dass beispielsweise OtherWidget.css nicht an einigen Regeln fehlen, die versehentlich in Button.css endeten - vielleicht wurden sie bei einem Refactoring oder so etwas übersehen - und fehlten Dies liegt daran, dass die Storys für OtherWidget das gesamte statisch importierte CSS der gesamten App abrufen, sodass OtherWidget im Storybook immer noch gut aussieht.)

Ich denke, ich würde stattdessen alle CSS-Loader so ändern, dass sie mit lazyStyleTag injiziert werden, und dann mithilfe der Webpack-API ein neues Modul generieren, das die CSS-Module nach den Story-Dateien gruppiert, die sie letztendlich benötigen, und Story-Änderungen abhört Ereignisse zum Ein- und Ausschalten der entsprechenden Module.
Wurde dieser Ansatz bereits in Betracht gezogen und verworfen, oder gibt es Probleme damit, die Sie jetzt sehen? Ich denke, ich kann alles in einem Storybook-Addon tun, aber es könnte sauberer sein, wenn es als Kernfunktion in Storybook integriert wird.

Wenn Sie eine starke Stilkapselung wünschen, werden Browser mitgeliefert. Ich bin mir immer noch nicht sicher, warum all dieses Userland-JavaScript (mit den damit verbundenen Komplexitätskosten) notwendig ist, um etwas zu erreichen, das eingebaut und einsatzbereit ist.

Warum nicht einfach das DOM jeder Geschichte mit so etwas in eine Schattenwurzel rendern?

customElements.define('encapsulated-story', class EncapsulatedStory extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }

  /* not sure why we'd need this getter, but let's say */
  get storyHTML() {
    return this.shadowRoot.innerHTML;
  }

  set storyHTML(string) {
    this.shadowRoot.innerHTML = storyHTML;
  }
});

und wann immer sich die Geschichte ändert

encapsulatedStory.storyHTML = theStoryDOMStringWithAllStyleTags;

und fertig? Hier ist theStoryDOMStringWithAllStyleTags nur die Verkettung des HTML-Codes einer Story mit allen zugehörigen Stilen, die als Inline-Tags <style> . Storys könnten das Host-Element wie gewohnt mit dem Selektor :host formatieren.

Dies ist ein absoluter Ausgangspunkt, auf dem später möglicherweise mit etwas Bibliothekscode aufgebaut werden könnte, aber zumindest wird das Ziel einer starken Stilkapselung erreicht, ohne dass all diese neuen vorgeschlagenen APIs erforderlich sind.

Wie funktioniert das mit Webpack? Webpack packt alles in ein JavaScript-Bundle, nicht in eine DOM-Zeichenfolge. Bei der aktuellen Konfiguration des Webpacks werden alle Storys in einem einzigen Bundle zusammengefasst. Ich glaube nicht, dass eine Schattenwurzel hilft, wenn das (Hot-Re-) geladene JavaScript Stile direkt in den Kopf des Dokuments einfügt. Sie müssen auf die eine oder andere Weise eine haarige Webpack-Konfiguration vornehmen, um dies zu ändern.

Die Verwendung des Schatten-DOM zum vollständigen Isolieren jeder Story würde auch bedeuten, dass die von vielen Storys gemeinsam genutzten Stil-Tags in jede Story repliziert werden. Die Verwendung eines gemeinsamen Stils, wie er vom Webpack gebündelt wird, ist effizienter. Vielleicht nicht genug, um einen großen Unterschied zu machen, aber möglicherweise genug, um die Vorteile auszugleichen, wenn es welche gibt, das Schatten-DOM anstelle von lazyStyleTag (was meiner Meinung nach die einzige Komplexität ist, die Schattenwurzeln haben würden rette dich).

Ich bin auch daran interessiert, dass dies früher oder später behoben wird.

Das wäre sicher und auch schlecht für die Leistung.

Der neue Iframe müsste das Javascript analysieren, das CSS analysieren, eine Verbindung zum Postmessage-Kanal herstellen, die Verbindung zum Websocket wiederherstellen und wahrscheinlich mehr.

@ndelangen Entschuldigung, Sie aus dem Jahr 2017 zu zitieren, aber ist dies immer noch Ihre Perspektive, dass das Nachladen eines Iframes zu teuer ist? Browser machen solche Dinge ständig; Sie sind wahrscheinlich sehr dafür optimiert. In diesem Fall wäre es sogar schneller als ein normales Laden von Seiten, da keine Netzwerkanforderungen beteiligt sind.

Für mich überwiegt der Nutzen die Kosten, da ich für jede Geschichte einen neuen Iframe sehr bevorzugen würde. Ich würde eine Verzögerung von bis zu 600 ms für einen solchen Luxus tolerieren.

(Mein Anwendungsfall ist, dass ich versuche, einige ältere AngularJS-Komponenten im Storybook zu rendern, und sagen wir einfach, dass die Komponenten nicht sehr rein sind. Sie sind sehr statusbehaftet; sie haben Nebenwirkungen und nutzen AngularJS-Dienste, die es sind auch sehr zustandsbehaftet. Dinge brechen auf unerwartete Weise.)

Eine Idee für eine API-Oberfläche besteht darin, das Storybook in .storybook/manager.js zu konfigurieren.

addons.setConfig({
  refreshBetweenStories: true,
})

Dies kann als UI-Einstellung angesehen werden, wenn Sie Ihren Kopf in die richtige Richtung neigen.

Es würde keine Laufzeitkosten für Leute geben, die dieses Flag nicht aktivieren, und für diejenigen, die es aktivieren, brauchen sie es wirklich, so dass eine solche Verzögerung tolerierbar wäre.

Wenn Sie dies beheben möchten, stimmen Sie bitte ab, indem Sie der Problembeschreibung ein 👍 hinzufügen. Wir nutzen dies, um Prioritäten zu setzen!

.addDecorator ((getStory) => {
erfordern ('./ story.sass');
return getStory ();
})

HALLO!!!!
wo kann ich das hinstellen? !!!