Storybook: Drehknöpfe über Aktionen ändern [Idee]

Eine ähnliche Idee wurde in dieser #3701 PR eingeführt, die umstritten war (und nicht zusammengeführt wurde).

Wir können wieder eine Diskussion darüber eröffnen und uns die API-Vorschläge anhören =).

Ah danke, diese PR hatte ich noch nicht gesehen. Danke @aherriot für die Zusammenstellung, anscheinend haben wir die gleichen Gedanken.

Bevor man in eine API eintaucht, scheint es, als ob das grundlegende Konzept diskutiert und vereinbart werden muss. Einer der Kommentare in der PR war dieser von @Hypnosphi :

Ich mag die Tatsache nicht, dass es mehrere Quellen der Wahrheit einführt (Komponentenrückrufe und UI-Knöpfe).

Es scheint mir, dass die Idee nicht darin besteht, verschiedene Wahrheitsquellen einzuführen, sondern eher eine _einzige_ Wahrheitsquelle für den Komponentenzustand aufrechtzuerhalten – die Knöpfe. Alle anderen Ansätze, die ich vorgeschlagen habe (Wrapper-Komponenten, Zustands-Add-Ons, Neuzusammenstellung) würden tatsächlich eine andere Quelle der Wahrheit einführen. In meinem Kontrollkästchen-Beispiel wäre ich nicht in der Lage, einen Drehknopf für checked haben und auch einer Wrapper-Komponente zu erlauben, die checked Requisite bereitzustellen. Ich sehe das Regler-Bedienfeld als übergeordnetes Element der Komponente, außer dass es derzeit keine Rückrufe von der Komponente erhalten kann, was irgendwie einseitig ist und nicht so reagiert, wie Apps normalerweise erstellt werden.

Dadurch, dass die Drehregler programmgesteuert gesteuert werden können, kann die Geschichte nur auf die demonstrierte Komponente isoliert werden, wodurch der eigentliche Zustandsverwaltungsmechanismus undurchsichtig bleibt, wie es für eine einfache Präsentationskomponente wie ein Kontrollkästchen sein sollte. Das Kontrollkästchen selbst kümmert sich nicht darum, wie es seine Requisiten erhält, es könnte mit Redux verbunden werden, sein Elternteil könnte setState , vielleicht verwendet es withState aus der Neuzusammenstellung, oder vielleicht werden die Requisiten von gesteuert Märchenbuch-Knöpfe.

Wie auch immer, wie gesagt, ich bin sehr neu in diesem Bereich, also teile ich nur meine intuitiven Gedanken. Wenn ich nicht an der Basis bin und es eine allgemein akzeptierte "Best Practice" für den Umgang mit dieser Art von reinen zustandslosen Komponenten gibt, kann mir vielleicht jemand ein gutes Beispiel nennen, dem ich folgen kann?

Hi :)

Ich möchte nur hinzufügen, dass ich darüber gestolpert bin, da meine Komponenten empfangen werden, ob sie ihre mobilen Layouts (oder nicht) von Requisiten anzeigen sollen, und mein Ziel war es, die Ansichtsfensteränderung an meinen Knopf zu binden, und es wäre wirklich schön gewesen;)

Ich wollte hier nur meinen Anwendungsfall hinzufügen, und da @IanVS sogar ein Rückruf schön gewesen wäre (wenn ich also meine isMobile-Requisiten umschalte, könnte ich eine Ansichtsfensteränderung auslösen).

Ich habe gehört, dass mehrere Leute Interesse an einer Methode zum Aktualisieren des Knopfstatus bekundet haben. Wenn wir uns auf eine gute Architektur einigen können, wird dies meiner Meinung nach für viele Menschen von Wert sein. Vor allem, da dies eine zusätzliche Funktionalität ist, die die Leute verwenden können oder nicht, und weil sie sich nicht negativ auf diejenigen auswirkt, die sie nicht verwenden möchten.

@Hypnosphi , Sie hatten Einwände gegen die vorherige Implementierung, WDYT?

Kommentieren Sie hier, um dieses Problem offen zu halten. Ich bin immer noch gespannt, was @Hypnosphi zu @igor-dv zu sagen hat, das zuvor hier vorgeschlagen wurde.

Mir scheint, dass die Idee nicht darin besteht, verschiedene Quellen der Wahrheit einzuführen, sondern eine einzige Quelle der Wahrheit für den Komponentenzustand zu ermöglichen – die Knöpfe. Alle anderen Ansätze, die ich vorgeschlagen habe (Wrapper-Komponenten, Zustands-Add-Ons, Neuzusammenstellung) würden tatsächlich eine andere Quelle der Wahrheit einführen. In meinem Checkbox-Beispiel wäre ich nicht in der Lage, einen Knopf für checked zu haben und auch einer Wrapper-Komponente zu erlauben, die geprüfte Requisite bereitzustellen. Ich sehe das Regler-Bedienfeld als übergeordnetes Element der Komponente, außer dass es derzeit keine Rückrufe von der Komponente erhalten kann, was irgendwie einseitig ist und nicht so reagiert, wie Apps normalerweise erstellt werden.

Klingt für mich vernünftig. Lassen Sie uns die API besprechen

Dies wird eine großartige Funktion sein. Ich habe mich hier mit einer sehr einfachen kontrollierten Komponente diesem gleichen Bedürfnis gestellt und hatte es auch zuvor in anderen Komponenten gesehen. Danke, dass du es dir angesehen hast.

Mit der aktuellen Syntax Schritt zu halten, scheint eine kleine Herausforderung zu sein. Vielleicht könntest du sowas verwenden:

const {value: name, change: setName} = text('Name', 'Kent');

@brunoreis , ich würde mir Sorgen machen, dass das Ändern der Rückgabesignatur der Knöpfe eine bahnbrechende Änderung wäre. Mein spontaner Vorschlag wäre, so etwas zu tun:

import {boolean, changeBoolean} from '@storybook/addon-knobs/react';

stories.add('custom checkbox', () => (
    <MyCheckbox
        checked={boolean('checked', false)}
        onChange={(isChecked) => changeBoolean('checked', isChecked)} />
));

Wobei der onChange Callback möglicherweise sogar Currying ermöglicht, damit dies auch funktioniert:

onChange={(isChecked) => changeBoolean('checked')(isChecked)}

// which of course simplifies down to
onChange={changeBoolean('checked')}

Wichtig ist, dass das erste Argument mit der Beschriftung des zu ändernden Knopfes identisch sein muss. Ich glaube, dies würde es Benutzern ermöglichen, sich für dieses Verhalten zu entscheiden, ohne etwas an der Art und Weise zu ändern, wie Regler derzeit verwendet werden. (Es sei denn, Labels müssen derzeit nicht eindeutig sein? Ich nehme an, sie sind…)

@IanVS , das ist schön. Ich stimme Ihnen zu, dass Sie die Art und Weise, wie die Dinge funktionieren, nicht ändern. Ich konnte keine Möglichkeit dazu finden, weil ich nicht daran dachte, das Etikett als Schlüssel zu verwenden. Das könnte funktionieren. Mal sehen, was @Hypnosphi im Sinn hat.

Das Ändern der Return-Signatur der Knöpfe wäre ein Breaking Change

Technisch ist das derzeit kein Problem. Wir haben eine große Veröffentlichung bevor. Aber es wäre in der Tat besser, eine gewisse Abwärtskompatibilität zuzulassen.

Ich mag die Idee der Curry-Unterstützung.

Es sei denn, Labels müssen derzeit nicht eindeutig sein?

Ja, das sind sie, und tatsächlich sind sie für verschiedene Typen einzigartig. Es sollte also keine Notwendigkeit für separate change<Type> Exporte geben, nur change sollte ausreichen. Das ist im Grunde das, was in https://github.com/storybooks/storybook/pull/3701 gemacht wurde
Ich denke, ich werde diese PR einfach wieder öffnen, damit @aherriot sie mit etwas Hilfe von deiner Seite beenden kann

Wir können das haben:

const {value: name, change: setName} = text('Name', 'Kent');

ohne den Rückgabetyp von text ändern zu müssen.

Javascript-Funktionen sind Objekte und können daher Eigenschaften haben.
Objekt kann destrukturiert werden.

@ndelangen die Funktion text ist zwar ein Objekt, ihr Rückgabewert jedoch nicht. Dies funktioniert in Ihrem Beispiel nicht:

const { foo, bar } = x() // note the parens

Wir könnten jedoch so etwas haben (der Name ist umstritten):

const {value: name, change: setName} = text.mutable('Name', 'Kent');

warum wird das nicht funktionieren?

const { foo, bar } = x() // note the parens

Die Rückgabe von x ist eine Funktion, die auch Eigenschaften haben kann.

Ich sprach von x = () => {} aus Ihrem ursprünglichen Beispiel.

Wenn text eine Funktion zurückgibt, müssen Benutzer ihren Code ändern:

// Before
<Foo bar={text('Bar', '')}>

// After
<Foo bar={text('Bar', '')()}>
                         ^^ this

Aha

Was ist mit @IanVS Vorschlag dazu?

Wäre cool diese Funktion zu haben.

was ist mit "destruct", wie mit "react Hooks" ?:

const [foo, setFoo] = useString('foo', 'default');

Kam, um das gleiche zu sagen wie @DimaRGB
Könnte die vorhandene Syntax beibehalten und Hook-ähnliche Aufrufe hinzufügen, zum Beispiel:

.add('example', () => {
  const [selected, setSelected] = useBool(false);

  return <SomeComponent selected={selected} onSelected={setSelected} />
})

Gelegentlich müssen reagieren Komponenten nicht ihre eigenen props aktualisieren, sondern ihren Eltern mitteilen, dass sie geändert werden müssen. Manchmal enthält eine Komponente ein Element, das ihre Requisiten umschalten soll (ich bin darauf gestoßen, weil manchmal ein Navigationsleistenmenü, das ich habe, sich öffnen muss, wenn auf ein untergeordnetes Element geklickt wird).

@IanVS Ich habe genau die gleiche Situation, in der ich eine Umschaltkomponente habe, die nur über übergeordnete Requisiten aktualisiert wird, und sobald der Benutzer einer Storybook-Geschichte sie umschaltet, stimmt der UI-Zustand nicht mit dem überein, was im Drehreglerbereich angezeigt wird. Ich habe es umgangen, indem ich eine private Methode von @storybook/addons-knobs - ein einfacherer Vorschlag wäre, eine offizielle API bereitzustellen, um Folgendes zu tun:

import { manager } from '@storybook/addons-knob/dist/registerKnobs.js'

const { knobStore } = manager
// The name given to your knob - i.e:  `select("Checked", options, defaultValue)`
knobStore.store['Checked'].value = newValue
// Danger zone! _mayCallChannel() triggers a re-render of the _whole_ knobs form.
manager._mayCallChannel()

@erickwilder Ich habe Ihren Ansatz ausprobiert, aber das schien das

BEARBEITEN:

Vergiss das; Ich habe diese Updates nur nicht gesehen, weil ich options() mit Checkboxen verwendet habe, die anscheinend "unkontrolliert" betrieben werden. Durch das Umschalten auf Multi-Select und die Verwendung dieser Methode in einem Callback habe ich die aktualisierten Werte in das Knopfformular erhalten:

// Ditch when https://github.com/storybooks/storybook/issues/3855 gets resolved properly.
function FixMeKnobUpdate(name, value) {
    addons.getChannel().emit(CHANGE, { name, value });
}

Ich habe möglicherweise einige Details meines Setups ausgelassen:

• Wir verwenden Vue.js mit Storybook
• Der Code, der den Wert mutiert und das erneute Rendern auslöst, wurde in einer Methode der Story Wrapping-Komponente ausgeführt.

Ich weiß nicht, ob so ein Ansatz für alle funktionieren würde.

Ich stimme @IanVS voll und ganz zu , ich liebe Märchenbücher, aber ich vermisse wirklich die Möglichkeit, Knöpfe über Aktionen zu aktualisieren. In meinem Fall habe ich zwei einzelne Komponenten A und B, aber in einer meiner Geschichten möchte ich eine Komposition mit beiden zeigen, damit bei jeder Änderung der KI eine Aktion ausgeht, die B modifiziert und umgekehrt.

Ich habe den Hack von

Fehler: Erwartet, nicht in der Angular Zone zu sein, aber es ist!

Ich habe versucht, dies irgendwie außerhalb von Angular auszuführen, aber ich habe es nicht geschafft ... Im schlimmsten Fall werde ich eine dritte Komponente C erstellen, die ein Wrapper von A und B ist.

Die temporäre Lösung @davidolivefarga von

Hat bei uns mit React genauso funktioniert wie oben beschrieben

+1, um eine öffentlich sichtbare Methode zum Triggern hinzuzufügen, die den Namen des Reglers als zu aktualisierende Zeichenfolge und einen neuen Wert enthält, zum Beispiel:

import { manager } from "@storybook/addon-knobs"

manager.updateKnob(
  propName, // knobs property, example from above "Checked"
  newValue, // new value to set programmatically, ex. true
)

Ich möchte wirklich, dass dies offiziell unterstützt wird.

In der Zwischenzeit musste ich mit Storybook v5 diese schrecklich hackige Lösung wählen:

window.__STORYBOOK_ADDONS.channel.emit('storybookjs/knobs/change', {
  name: 'The name of my knob',
  value: 'the_new_value'
})

🙈

🙈

Verwandte: #6916

Das wäre cool... Vor allem wegen der Modals.

Ich denke, das wäre nützlich.

Beispiel:

storiesOf('input', module)
  .addDecorator(withKnobs)
  .add('default', () => <input type={text('type', 'text')} value={text('value', '')} disabled={boolean('disabled', false)} placeholder={text('placeholder', '')} onChange={action('onChange')} />)

Dies funktioniert derzeit, aber es scheint natürlich, dass wir den Zielwert des onChange-Ereignisses mit dem in den Requisiten des getesteten Elements festgelegten Wert verbinden möchten. Dies würde die Anwendung des Elements besser demonstrieren.

Das wäre nützlich

+1 an @mathieuk/ @raspo für den Hinweis auf eine Lösung hier.

Wir können möglicherweise auch auf andere Weise darauf zugreifen. Einige generische Methoden in einem helpers Modul erstellen?

import addons from "@storybook/addons";

export const emitter = (type, options) => addons.getChannel().emit(type, options);

export const updateKnob = (name, value) => (
  emitter("storybookjs/knobs/change", { name, value })
);

Und rufen nach Bedarf in Geschichten...

import { text } from "@storybook/addon-knobs";
import { updateKnob } from 'helpers';

// ...
const value = text("value", "Initial value");
<select
  value={value}
  onChange={({ target }) => updateKnob("value", target.value)}
>

...aber fühlt sich immer noch wie eine funky Zwei-Wege-Bindungslösung für etwas an, das in die Knobs-API eingebaut werden könnte

Irgendein Update zu den oben genannten? Wäre ein sehr nützliches Feature 👍

Mit dieser implementierten Funktion können wir ganz einfach einige wirklich leistungsstarke, kreuzabhängige Regler ausführen. Stellen Sie sich vor, Sie erstellen eine Paginierungskomponenten-Story, wenn Sie einen Knopf haben könnten, der sich dynamisch in Abhängigkeit von einem anderen aktualisiert, mit so etwas in Ihrer Story:

const resultsCount = number(
    'Results count',
    currentPage, {
        max: 100,
        min: 0,
        range: true
    }
);
const resultsArray: React.ReactNode[] = new Array(resultsCount)
    .fill(true)
    .map((_, idx) => <div key={idx + 1}>Test Pagination Result #{idx + 1}</div>);
const childrenPerPage = 10;
const currentPage = number(
    'Current page index',
    0, {
        max: Math.ceil(resultsCount / childrenPerPage) - 1,
        min: 0,
        range: true
    }
);

Ich habe im Wesentlichen versucht, dies zu tun, in der Hoffnung, dass der maximale Bereich auf meinem currentPage Knopf dynamisch aktualisiert würde, wenn der resultsCount Knopf um 10 erhöht wird, aber es scheint der Anfangswert jedes Knopfes zu sein wird zum Zeitpunkt der Erstellung zwischengespeichert und gewöhnt sich nicht daran, interne Zustandswerte in nachfolgenden Renderings zu überschreiben. Wenn ich mit dem obigen Code resultsCount um 10+ erhöhe, würde ich erwarten, dass die max von currentPage ebenfalls um 1 steigen, jedoch bleibt der Wert gleich, obwohl die zugrunde liegenden Werte verwendet, um die Änderung zu berechnen (die Protokollierung von Math.ceil(resultsCount / childrenPerPage) - 1 zeigt den erwarteten neuen Wert).

Wir sind fast fertig mit 5.3 (Anfang Jan Release) und schauen uns eine Knobs Rewrite für 6.0 (End Mär Release) an, die eine Reihe langjähriger Probleme mit Knobs lösen wird. Ich werde sehen, ob wir das einarbeiten können! Danke für Ihre Geduld!

@shilman Ich freue mich sehr über dieses Feature 😄

Ich, @atanasster & @PlayMa256 arbeiten seit einiger Zeit an der Grundlage dafür. Es wird noch ein paar Iterationen dauern, bis es richtig ist, aber ich bin sehr zuversichtlich, dass wir in 6.0.0 100% erreichen und Daten und Reaktivität für Storybook wirklich revolutionieren können.

Revolutionieren? Heiße verdammte diggity. Hör auf mich zu ärgern, mein Körper ist bereit.

+1 für Modal :)

Kann nicht glauben, dass es von Anfang an unmöglich ist. Warten auf Updates...

Hallo Leute!
Als vorübergehende Lösung habe ich in meiner App den nächsten Code verwendet:

import { addons } from '@storybook/addons';
import { CHANGE } from '@storybook/addon-knobs';

const channel = addons.getChannel();

channel.emit(CHANGE, {
  name: 'prop_name',
  value: prop_value,
});

Noch warten diese Funktion wird nativ implementiert.

Ich habe das Problem mit Observable gelöst. Ich benutze Bilderbuch mit eckigen

`
.add('Diagrammdaten aktualisieren', () => {

const myObservable= new BehaviorSubject([{a: 'a', b: 'b'}]);
return {
  template: '
  <my-component
    myInput: myData,
    (myEvent)="myEventProp($event)"
  ></my-component>
  ',
  props: {
    myData: myObservable,
    myEventProp: $event => {
      myObservable.next([]);
      action('(myEvent)')($event);
    }
  }
};

})
`

@norbert-doofus danke dein Beispiel hat mir geholfen 👍

Hallo Bande, wir haben gerade Addon-Steuerelemente in der 6.0-Beta veröffentlicht!

Controls sind tragbare, automatisch generierte Knöpfe, die Add-On-Knöpfe langfristig ersetzen sollen.

• Bedienelemente README
• Migrationsanweisungen

Bitte aktualisieren Sie sie und probieren Sie sie noch heute aus. Vielen Dank für Ihre Hilfe und Unterstützung, um diesen Stall zur Veröffentlichung zu bringen!

Das ist großartig! Ich kann es nicht genau sagen, wenn ich die README gelesen habe (ich habe sie vielleicht übersehen), können diese neuen controls programmatisch geändert werden, was war die Anfrage in dieser Ausgabe?

Sie können sein, obwohl ich nicht sicher bin, ob die API noch offiziell unterstützt wird (obwohl wir genau das für die Steuerelemente in den Addon-Dokumenten tun). Ich werde mit @tmeasday zusammenarbeiten , um den besten Weg zu finden, dies nach der ersten Stabilisierungsrunde der Controls-Bugs einzubinden.

• [ ] updateArgs zum Story-Kontext hinzufügen?
• [ ] den Story-Kontext für einen Callback verfügbar machen, der aus der Story aufgerufen wird? ( this.context?.updateArgs(....) )

Für alle, die sich für Controls interessieren, aber nicht wissen, wo sie anfangen sollen, habe ich eine Quick & Dirty Schritt-für-Schritt-Anleitung erstellt, um von einem frischen CRA-Projekt zu einer funktionierenden Demo zu gelangen. Hör zu:

=> Storybook-Steuerung mit CRA & TypeScript

Es gibt auch einige Migrationsdokumente für "Knöpfe zu Kontrollen" in der README-Datei für Kontrollen:

=> Wie migriere ich von Addon-Knobs?

Hallo Leute!
Als vorübergehende Lösung habe ich in meiner App den nächsten Code verwendet:

import { addons } from '@storybook/addons';
import { CHANGE } from '@storybook/addon-knobs';

const channel = addons.getChannel();

channel.emit(CHANGE, {
  name: 'prop_name',
  value: prop_value,
});

Noch warten diese Funktion wird nativ implementiert.

Denken Sie daran, dass Sie bei der Verwendung von groupId die Gruppen-ID wie folgt zu name hinzufügen müssen:

 const show = boolean('Show Something', true, 'Group')

channel.emit(CHANGE, {
  name: 'Show Something_Group',
  value: prop_value,
});

Außerdem ist channel ein EventEmitter, also können Sie addListener darauf zugreifen, um zu überprüfen, welche Parameter empfangen werden.

channel.addListener(CHANGE, console.log)

Hier ist ein Code-Snippet für alle, die daran interessiert sind, dies mit addon-controls in v6 zu tun.

import { useArgs } from '@storybook/client-api';

// Inside a story
export const Basic = ({ label, counter }) => {
    const [args, updateArgs] = useArgs();
    return <Button onClick={() => updateArgs({ counter: counter+1 })>{label}: {counter}<Button>;
}

Ich weiß nicht, ob dies die beste API für diesen Zweck ist, aber es sollte funktionieren. Beispiel im Monorepo:

https://github.com/storybookjs/storybook/blob/next/examples/official-storybook/stories/core/args.stories.js#L34 -L43

Danke, @shilman! Das hat funktioniert.

Für interessierte Leute haben wir zufällig genau die Checkbox Story checked Requisite, die diesen ganzen Thread gestartet hat. Hier ist unsere neu verkabelte Geschichte mit Storybook 6.0.0-rc.9:

export const checkbox = (args) => {
  const [{ checked }, updateArgs] = useArgs();
  const toggleChecked = () => updateArgs({ checked: !checked });
  return <Checkbox {...args} onChange={toggleChecked} />;
};
checkbox.args = {
  checked: false,
  label: 'hello checkbox!',
};
checkbox.argTypes = {
  checked: { control: 'boolean' },
};

@shilman Ich habe versucht, useArgs in einer Story für eine kontrollierte Texteingabe zu verwenden (ein Fall, in dem wir normalerweise den useState Hook verwenden, um die value Requisite der Komponente über zu aktualisieren sein onChange Ereignis). Ich bin jedoch auf ein Problem gestoßen, bei dem jedes Mal, wenn der Benutzer ein Zeichen eingibt, die Komponente den Fokus verliert. Wird dies vielleicht dadurch verursacht, dass die Geschichte jedes Mal aktualisiert / neu gerendert wird, wenn wir die Argumente aktualisieren?

Gibt es eine andere empfohlene Methode für die Verwendung von Argumenten/Steuerelementen für eine Komponente mit kontrollierter Texteingabe?

Dies war mit 6.0.0-rc.13

@jcq Können Sie ein neues Problem mit einem Repro erstellen? Dies war nicht der primäre Anwendungsfall für useArgs , aber sicherlich einer, den wir unterstützen möchten, also würden wir uns gerne darauf einlassen.

@shilman Kein Problem – hier ist die neue Ausgabe:
https://github.com/storybookjs/storybook/issues/11657

Ich hätte auch klarstellen sollen, dass das fehlerhafte Verhalten in Docs angezeigt wird, während es im normalen Canvas-Modus ordnungsgemäß funktioniert.

Ich habe das Problem mit Observable gelöst. Ich benutze Bilderbuch mit eckigen

`
.add('Diagrammdaten aktualisieren', () => {

const myObservable= new BehaviorSubject([{a: 'a', b: 'b'}]);
return {
  template: '
  <my-component
    myInput: myData,
    (myEvent)="myEventProp($event)"
  ></my-component>
  ',
  props: {
    myData: myObservable,
    myEventProp: $event => {
      myObservable.next([]);
      action('(myEvent)')($event);
    }
  }
};

})
`

Dies hat bei mir mit Angular funktioniert, aber in Zeile 5 zu myData.value gewechselt

Ich habe dies noch nicht ausprobiert (vorerst an einer älteren Version von Storybook hängen geblieben), aber es scheint, als ob dieses Problem jetzt geschlossen werden kann. Danke für die tolle Arbeit an args/controls!