في الوقت الحالي ، لا نخطط لتنفيذ ذلك. هذا لأنه يجعل التنقل أكثر صعوبة. يمكنك أنواع قصة مساحة الاسم بنقطة مثل "ui.core" ، "ui.app". ثم يمكنك تصفيتها حسب حاجتك.

إذا كان هناك الكثير من القصص ، يمكنك أن تبدأ في بعض حالات القصص القصيرة. يمكنك القيام بذلك من خلال وجود دليلين لتكوين القصص القصيرة. لكن ، على أي حال ، هذه حالة متطرفة.

أنا على استعداد للتنازل عن هذه النقطة ، واعتقدت أنني سأقوم فقط بعمل تكوين مختلف وتشغيله على منفذ مختلف وما إلى ذلك ...

لكنني أعتقد أنه سيكون من الأفضل بكثير السماح لكتاب القصة بأخذ ملفات تكوين متعددة ... ثم التبديل بين ملفات التكوين المسماة ، وربما إعادة التحميل ...

بالنسبة إلى واجهة المستخدم لتبديل التكوينات ، فإنها ستظهر فقط إذا "حمل" ملف التكوين الخاص بك ملفات تكوين أخرى ، ويمكن أن تكون عناصر الشريط الجانبي في الجزء العلوي أو السفلي من تنقل الشريط الجانبي.

على أي حال - أعتقد أنه بالنسبة للتطبيقات الأكبر حجمًا ، إذا كنت لا تستطيع (أو لا) تقسيم التكوينات ، فهذا جنون نوعًا ما.

يبدو أن إضافة تكوينات إضافية معقدة للغاية. ماذا عن تبديل العرض الكلاسيكي / الهرمي؟ يسعدني تنفيذ برنامج خلال الأيام القليلة المقبلة.

ستكون هذه ميزة قيّمة جدًا بالنسبة لي أيضًا ، ولكن لتنظيم أنواع المكونات داخل تطبيق واحد بدلاً من تطبيقات متعددة.

سأكون أكثر من سعيد لتقديم أي مساعدة في تشكيل تطبيق يمكن أن يعمل لكلتا حالتي الاستخدام إذا كان هذا قادرًا على المضي قدمًا.

travi من بين أفكارنا الأخرى توفير قائمة منسدلة أسفل مربع التصفية مباشرة لتحديد الفئة.

يتم تعيين فئة في config.js ومجموعة مختلفة من الملفات. لذلك ، يمكن أن يكون لدينا طبقة أخرى من التجميع.

أعتقد أن هذا النوع من الحل سيكون كافياً لتلبية احتياجاتي في هذه المرحلة. بالإضافة إلى ذلك ، أعتقد أن اصطلاح تباعد الأسماء المذكور أعلاه يمكن أن يظل طريقة معقولة لتعيين الفئة التي يمكن تفسيرها في الاختيارات في القائمة المنسدلة. مثل هذا الحل سيمكن الربط عبر الفئات ليظل بسيطًا أيضًا.

الطريقة التي نتعامل بها مع هذا في التطبيق الذي أقوم ببنائه (مئات المكونات ، منظمة داخل مناطق "أعمدة" مفكوكة) هي باستخدام نص يكتب ديناميكيًا القصص للمنطقة التي نعمل عليها حاليًا.

find.file(
  /\.story\.js/,
  path.resolve(__dirname, '../src/app/components', targetComponentPath),
  function(files) {
    var requires = files.map(function(file) {
      return "require('" + path.relative(__dirname, file) + "');";
    });
    fs.writeFileSync(path.resolve(__dirname, '../.storybook/stories.js'), requires.join("\n"));
  }
);

هذا يعني أن Storybook لا تحتاج حتى إلى بناء المكونات الأخرى. أرغب في مستوى معين من الدعم لهذا كخيار مدمج.

201 يمكن أن تساعد في هذا.

أي تحديثات على هذه؟

+1

أنا argee هذه ميزة مفيدة للغاية!

+1

+1

+1

+1

+1

+1

مرحبًا arunoda ، هل كان هناك أي تقدم على صعيد تنفيذ الفئات؟

إذا لم يكن الأمر كذلك ، فهل لدى أي شخص آخر مثال على التطبيق يقوم بالتبديل بين تكوينين لقصص القصص القصيرة؟

+1 أحتاج تمامًا إلى مستوى إضافي واحد من التعشيش: /

+1

+1

+1

+1

+1

+1

يبدو جيدًا أنه بينما ينمو تطبيقك ، تنمو قائمة المكونات أيضًا ، وتحتاج إلى مزيد من التداخل. 1 مستوى آخر سيغطي بالفعل الكثير من الحالات

+1

مرحبا شباب!

على الرغم من حقيقة أن مثل هذه الميزة لم يتم التخطيط لها في المستقبل القريب ، فإن هذا لا يعني أنه لا يمكننا الحصول على مثل هذا السلوك عبر Storybook Addons API

هنا ملحق من هذا القبيل:

فصول القصص القصيرة

يضيف مستويات غير محدودة من التداخل للقصص (الفرعية)

لإضافة مستوى متداخل واحد فقط ضع .chapter(name) إلى قصصك:

// stories.js:

storiesOf('React App', module)
    .chapter('Left panel')
        .add('Button 1', fn(1))
        .add('Button 2', fn(2))
        .chapter('Bottom Panel')
            .add('Input 3', fn(3))
            .add('Input 4', fn(4))
            .endOfChapter()
        .chapter('Header Panel')
            .add('Input 5', fn(5))
            .add('Input 6', fn(6))
            .endOfChapter()
        .endOfChapter()
    .chapter('Right panel')
        .add('Button 7', fn(7))
        .add('Button 8', fn(8))
        .endOfChapter()

سمات

• الهيكل الهرمي للمواد
• متوافق مع Knobs و addWithInfo والوظائف الإضافية الأخرى
• استخدم storyDecorator لإنهاء كل الفصول

الصفحة التجريبية

مشروع

مثال

سيكون موضع تقدير أي ردود فعل! :)

تضمين التغريدة

UsulPro Storybook Chapters هو حل رائع. شكرا!

UsulPro يبدو أن excactly ما كنت أبحث عنه، وذلك بفضل!

تحية للجميع! عدم محاولة التنافس مع UsulPro (الذي قام بعمل رائع بـ storybook-chapters ) ، لكنني توصلت إلى حل صغير مختلف قليلاً يسمح لك بالتبديل بين مجموعات مختلفة من القصص باستخدام زر في preview نافذة related components view a la توثيق bootstrap و detailed components view a la ما هو كتاب القصص المناسب تمامًا ونحن لديها الكثير من المكونات للتباهي. كنت أعتبر هذا إصدارًا خفيف الوزن من إعداد العديد من حالات القصص القصيرة:

إذا كان مفيدًا لك ، فيمكنك التحقق منه هنا - https://github.com/majapw/storybook-addon-toggle

لقد بنيت على storybook-chapters الرائع منUsulPro لإنشاء مُحمل القصص القصيرة الذي القصص القصيرة :

باستخدام هذا ، يمكنني وضع قصصي في ملف أو مجلد _stories يتماشى تمامًا مع المكونات الخاصة بي. يجد المُحمل جميع ملفات القصة ويضعها في بنية ملاحية مقابلة.

شكرا لردود الفعل الدافئة يا شباب!

رائع حقًا أن ترى hadfieldn storybook-filepath-chapters ! 👍

أحب storybook-addon-toggle كمثال ، أنه من المستحسن أن يكون لديك إمكانية لبناء تسلسل هرمي ليس فقط في العمق ولكن أيضًا في الأعلى. في الواقع ، هذا ممكن تقنيًا ، لكنني أعتقد أنه من الصعب اختيار أفضل طريقة (البقاء داخل واجهة برمجة التطبيقات الإضافية). ربما يمكن القيام بذلك باستخدام أدوات الديكور (مثلmajapw) أو عبر اللوحات الإضافية.

لا أخطط لإضافة تسلسل هرمي على القصص حتى الآن ، لكن الملحق storybook-chapters يحتوي الآن على واجهة برمجة تطبيقات ، وهو قادر على تبسيط بناء هذا التسلسل الهرمي:

enable / disable لإظهار / إخفاء قصصك

-

أضف enable() / disable() إلى قصصك. كوسيطة ، حدد رد الاتصال الذي سيتم نقل وظيفة التحكم إليه.

let toLight = () => {};
let toDark = () => {};

storiesOf('Heroes Lightside', module)
    .enable((en) => { toLight = en; })
    .add('Yoda', info('Yoda'))
    .add('Mace Windu', info('Mace Windu'));

storiesOf('Heroes Darkside', module)
    .disable((en) => { toDark = en; })
    .add('Darth Sidious', info('Darth Sidious'))
    .add('Darth Maul', info('Darth Maul'));

ثم يمكنك استخدام toLight(false) لإخفاء Heroes Lightside و toDark(true) لإظهار قصص Heroes Darkside . قد ترغب في وضع toLight و toDark في بعض المصممين أو ربما لإعادة الاتصال من قصص أخرى. سأعرض أبسط مثال ممكن:

storiesOf('Choose Your Side', module)
    .add('Lightside', () => {
        toLight();
        toDark(false);
        return (<div>{'Lightside selected'}</div>);
    })
    .add('Darkside', () => {
        toDark();
        toLight(false);
        return (<div>{'Darkside selected'}</div>);
    });

إذن لدينا الآن 3 مجموعات من القصص: Choose Your Side ، Heroes Lightside و Heroes Darkside . من بين الأخيرين ، واحد فقط مرئي والأول يسمح لك بالتبديل.

في الإصدار التالي ، أخطط لإضافة القدرة على التحكم في رؤية القصص عبر لوحة الوظائف الإضافية القابلة للتخصيص

-

باستخدام ميزة التمكين / التعطيل ، يمكنك إنشاء تنقل مخصص بمنطقك المفضل.

مثال كامل هنا

سنقوم بتنفيذ متصفح هرمي ، لكننا نحب المفاهيم التي يعتقد المجتمع أنها يجب أن تتم:

• UX حكيم
• كيفية تكوين المجموعات

UX wise ، أحب هذه الفكرة: http://multi-level-push-menu.make.rs/demo/basichtml/basichtml.html

التكوين الذي لا أعرفه حتى الآن .. يمكننا استخدام استكشاف الملفات وعكس نظام الملفات ، أو يمكننا القيام بشيء مثل هذا: https://github.com/sm-react/storybook-chapters/issues/1#issue -215446017

ndelangen هل فكرت (على الأقل اختياريًا؟) في السماح بتحديد التنقل خارج القصص؟ يبدو لي أنه قد تكون هناك قيمة في معالجة شكل القصة (منطقة المعاينة / إطار iframe) وكيف تريد تنظيم التصفح (المدير) كمخاوف منفصلة.

jackmccloy أنا مهتم ، هل يمكنك إخباري بالمزيد حول ما

لقد ذكرت في قضية مختلفة ، ولكن هدفي مع الفئات سيكون في الغالب التوافق مع التصميم الذري . مختبر الأنماط هو نهج دليل النمط الرسمي للتصميم الذري ، لكن إضافة فئات إلى كتاب القصص ستسد الفجوة المتبقية المتبقية.

لقد قمت بالفعل بترتيب مكوناتي في مجلدات المستوى الأعلى لتلك الفئات ، لذا فإن القدرة على تحميل المكونات إلى فئات بناءً على مجلدات المستوى الأعلى ستكون شيئًا رائعًا للتصوير أيضًا.

travi هل يمكن أن تعطيني طباعة تخطيط المجلد الخاص بك؟

أنا مهتم بالتأكيد بتحسين القصص القصيرة لهذا الغرض بالتحديد ، لكنني مهتم بما هو مطلوب تقنيًا لقراءة هذا التصنيف من هيكل مجلدك.

في الأساس

project root
|
+--
|  +-- atoms
|  |  +-- foo
|  |    +-- index.js // the component
|  |    +-- stories.js
...
|  +-- molecules
|  |  +-- bar
|  |    +-- index.js
|  |    +-- stories.js
...
|  +-- organisms
|  |  +-- baz
|  |    +-- index.js
|  |    +-- stories.js

هل هذا يساعد؟ لدي عدة مكونات تحت كل مجلد من المستوى الأعلى ، وأحيانًا يتم تجميعها حسب مستوى مجلد آخر. يسعدنا تقديم المزيد من التفاصيل إذا كان ذلك مفيدًا

حسنًا ، ما يمكننا فعله هو تعيين علامة في config.js . شيء مثل autoDiscoverStories أو نحو ذلك. مما يعني أنك لست مضطرًا إلى استيراد القصص يدويًا ، وسيتم استخدام مجلدات نظام الملفات كفئة.

ndelangen أعتقد أن ما أفكر فيه هو هذا: في الوقت الحالي ، تدور محادثتنا حول "كيف نجعل التنقل أفضل" ، لكنه يفترض أنه سيكون هناك تنقل واحد يستخدمه الجميع. أشعر أنه قد يكون من المفيد الحديث عن طرق لجعل التنقل قابلًا للتوسعة ، بطريقة مماثلة لكيفية توسيع الوظائف الإضافية لوظائف القصص نفسها.

احتمال واحد:
حاليًا ، تتم إضافة كل قصة على خطوتين - الخطوة الأولى حيث يتم تعيين فئة ، والخطوة الثانية حيث يتم تعيين العنوان ، أي

storiesOf('storyCategory', module).add('storyTitle', () => <Component />)

يمكنك إضافة قصص متعددة إلى نفس الفئة بشكل متسلسل ، لكن الهيكل يحد من المرونة إلى حد ما - يجب أن تحتوي جميع القصص على فئة وعنوان ، والفئات هي "مستوى أعلى" من العناوين.

ولكن إذا كان من الممكن تعريف القصص بطريقة مختلفة قليلاً ، أي

const storyData = {
  category: "category",
  title: "storyTitle",
}
stories.add(() => <Component />, storyData)

يمكننا تجربة خيارات التنقل المختلفة بسهولة أكبر.

يمكن أن يظل التنقل الافتراضي كما هو. إنه تقصير عقلاني ، وربما يعمل بشكل جيد بما يكفي لمعظمنا. يمكن أن يكون storyData اختياريًا - يمكن أن تظهر القصص التي لا تحتوي على فئة في المستوى الأعلى ، ويمكن أن تكون القصص التي ليس لها عنوان افتراضيًا إلى displayName للمكون.

ولكن يمكن للمجتمع تجربة طرق مختلفة لتنظيم قصصهم عن طريق (أ) إضافة حقول بيانات وصفية إضافية إلى stroyData و / أو (ب) تغيير طريقة عرض لوحة التنقل بناءً على حقول البيانات الوصفية.

بعض الافكار:

// add an additional level to the hierarchy called subCategory
const stroyData = {
  category: "Buttons",
  subCategory: "Blue",
  title: "BlueButton",
}
stories.add(() => <BlueButton />, storyData)

// add tags to a story that you could then filter by
const stroyData = {
  category: "Buttons",
  tags: ["button", "homepage"],
  title: "HomepageButton",
}
stories.add(() => <HomepageButton />, storyData)

// have a story to appear in multiple categories
const stroyData = {
  categories: ["Buttons", "Homepage Elements"],
  title: "HomepageButton",
}
stories.add(() => <HomepageButton />, storyData)

لطيف - جيد! هذا خارج الصندوق تمامًا ، وهو قابل للتوسعة بالفعل. سأفكر في هذا قليلاً. 🤔

مذهل. اسمحوا لي أن أعرف ما الذي تقرره - سأقدم عرضًا حيثما يمكنني بغض النظر عن الاتجاه الذي تختاره - معجب كبير بالمشروع

اقتراح jackmccloy رائع ، شكرًا على الفكرة الرائعة!

ومع ذلك ، يبدو أنه لا يشجع على استخدام حالة استخدام واحدة قوية لـ Storybooks والتي تفكر في واجهة المستخدم كسلسلة من "حالات الاختبار المرئي" وتحديد حالات واجهة المستخدم بسهولة كقصص فردية باستخدام add() call لكل ولاية.

يبدو تسجيل البيانات الوصفية للقصة في المكالمة add() وكأنها تضيف الفئة في المستوى الخطأ. أرغب في رؤية نفس الاقتراح ، ولكن باستخدام الوظيفة storiesOf() :

storiesOf({
  title: Component,
  category: "My Category"
}, module)
  .add("when empty", () => <List items=[] />)
  .add("with items", () => <List items=["one", "two", "three"] />)
  .add("etc.", () => <List items={etc} />);

تعجبني فكرة أن تكون قادرًا فقط على أخذ العنوان من Component.displayName وجميع الأفكار الأخرى حول الفئات الفرعية أو إضافة مكون إلى فئات متعددة ، أود فقط الحفاظ على بساطة إضافة الحالات.

هناك شيء واحد يجب مراعاته ، بغض النظر عن مكان تعريف الفئة ، وهو أن ملفًا آخر يجب أن يكون قادرًا على الإضافة إلى الفئة. إذا كان من الممكن تحديد فئة من ملف واحد فقط ، فأعتقد أنها ستكون محدودة للغاية

أوافق travi - ولهذا السبب تعتبر الفئة مجرد سلسلة (والتي أتخيل أنها ستعين إلى بعض مفاتيح القاموس) جذابة.

أتخيل أنني قد أحدد الفئات الخاصة بي في مكان واحد لمنع الأخطاء الإملائية مثل:

// categories.js
export const Layouts = "Layouts";
export const Components = "Components";
export const Styles =  "Styles";

// DashboardLayout.story.js
import { Layouts } from "../categories";
import DashboardLayout from "./DashboardLayout";

storiesOf({
  title: DashboardLayout,
  category: Layouts
}, module)
  .add("default", () => <DashboardLayout />);

ولكن هذا سيكون أحد تفاصيل التنفيذ التي تُركت لتطبيقي.

theinternedjackmccloy تعجبني اقتراحاتكم.

أفكر كيف يمكنك استخدام اقتراحاتك في تسلسل هرمي من العمق التعسفي. ربما بدلاً من category / subCategory يمكن أن يكون path مع مصفوفة من مكونات المسار. (أعلم أنك لم تكن تنوي بالضرورة التفاصيل هناك ، فقط استغل أفكارك).

أحب أيضًا فكرة خيار التكوين لاستخدام نظام الملفات لإنشاء التسلسل الهرمي للتنقل. مع تمكين هذا الخيار ، ستكون الوسيطة path اختيارية.

هذا أكثر من مجرد هدف ممتد ، ولكن قد يكون من الجيد تحميل كل صفحة من القصص في التسلسل الهرمي كقطعة منفصلة ، للحفاظ على وزن كتاب القصص مع زيادة حجمه. سيكون من الرائع أيضًا السماح لمحمل القصص المصورة بالعمل مع مجلد نظام ملفات محدد كسياق جذر ، بحيث يمكنه إنشاء كتاب قصص مع القصص المحددة فقط في هذا المجلد بدلاً من جميع القصص في المشروع بأكمله.

ما رأيكم في التفكير في تحديد / تسجيل الفئات مقدمًا في التكوين الخاص بك؟

// config.js
import { configure, addCategory } from '@kadira/storybook';

function init() {
  require('../src/stories');
  addCategory({
    id: 'atom',
    name: 'Atoms',
    index: 0
  });
  addCategory({
    id: 'molecule',
    name: 'Molecules',
    index: 1
  })
}

configure(init, module);

// component.story.js
import Component from "./Component";

storiesOf({
  title: Component,
  category: 'atom'
}, module)
  .add("default", () => <DashboardLayout />);

قد ندعم أيضًا مصفوفة: category: ['atom', 'deprecated'] ، لماذا لا؟

سيساعد هذا في التأكد من ترتيب الفئات بالترتيب الصحيح ، وهو أمر مهم في التصميم الذري.

سيكون استرداد الفئات من التكوين أمرًا رائعًا ، فالسلسلة السحرية سيئة 👎

هذا يبدو منطقيا بنسبة إلي.

أيضًا ، +1 لسحب فئة القصة مما تم تعريفه في التكوين بدلاً من الأمل في مطابقة السلاسل

ndelangen تحديد الفئات مقدمًا حتى نتمكن من التحكم في الطلب سيكون ضخمًا! لكنني أعتقد أنه سيكون من المهم أن نجعله بحيث يمكن تعريف الفئات في التكوين ، وليس أنه يجب تحديدها هناك.

أحد الأشياء التي أحبه في Storybook هو أنه يمكنني معرفة ما إذا كان أحد المكونات موجودًا أم لا في Storybook فقط عن طريق التحقق مما إذا كان هناك ملف story.jsx مشترك مع المكون. هذا يضمن -
أنه في حالة وجود ملف story.jsx ، فإن القصة موجودة - وهي قصة مهمة لا يجب التراجع عنها عن طريق التحديد المسبق للفئات ، imo.

من وجهة النظر هذه ، قد لا تكون الحاجة إلى id و index للفئات في التكوين ضرورية - شيء من هذا القبيل (على افتراض أنه يستخدم البرنامج المساعد للخيارات) يمكن أن يعمل

setOptions({
  categoryOrder: [
    "First Category",
    "Second Category",
    "Third Category",
});

حيث يتم ضمان ظهور First Category و Second Category و Third Category في المرتبة الأولى والثانية والثالثة ، وستظهر أي فئات أخرى تم الإعلان عنها في القصص أبجديًا بعد هذه الفئات الثلاثة.

يمكن أن يكون هذا النهج أيضًا طريقة ذكية للتحكم في التداخل العشوائي للعمق أيضًا ، من خلال القيام بشيء مثل هذا:

categoryOrder: [
  {
    "Atoms": [
      {
        "Buttons": []
      }
    ],
  }, {
    "Molecules": [],
}],

ستظهر القصص التي تحمل فئة "الأزرار" داخل Atoms -> Buttons . ستظهر القصص التي تحمل فئة "Atoms" داخل Atoms ، أقل من Buttons (ولكن ليس بداخلها) ، إلخ.

سيحصل المستخدمون على مستوى واحد من العمق بدون أي تكوين (تمامًا مثل الآن) ، ومستويات عشوائية من العمق مع الحد الأدنى من التكوين. الأهم من ذلك ، ستكون الفئات ذات العمق (تم تعيينها على مستوى التكوين) بدلاً من القصص نفسها (أي أن القصص ستحدد فئتها فقط - لن تحدد مكان ظهور هذه الفئة في التسلسل الهرمي).

theinterned أنا أتفق معك بشأن إعادة: الحاجة إلى الحفاظ على بساطة إضافة الدول. لم أفكر في ذلك ، ربما ب / ج أستخدم ملحق المقابض بكثافة. لذا ، بالنسبة لي ، أحاول أن تكون لدي علاقة 1-1 بين المكونات والقصص ، وعناوين قصتي وصفية للمكوِّن بدلاً من وصف الحالة التي يتواجد فيها المكون.

أحد الحلول المحتملة التي قد تنجح في كلتا حالتي الاستخدام هو القيام بشيء كهذا

const storyData = {
  category: "category",
  title: "first item",
}
stories.add(() => <Component />, storyData)
  .add(() => <Component />, {title: "second item"})
  .add(() => <Component />, {title: "third item"})

حيث (أ) يمكن التحكم في ترتيب القصص من حيث تم الإعلان عنها (على عكس الحاجة إلى تكوين خارجي) و (ب) يمكن للمعلمة storyData الاحتفاظ بالعنصر السابق ، والكتابة فوق القيم التي صراحة.

مجرد فكرة.

بينما سأكون سعيدًا حتى مع الفئات ذات المستوى الأعلى فقط ، إذا سارت الأمور بعيدًا بما يكفي لدعم الفئات المتداخلة ، فمن الجدير بالذكر أنه ليس من الآمن افتراض أن أسماء الفئات ستكون فريدة بين الفئات المختلفة.

استمرارًا لمثال التصميم الذري ، من الشائع وجود فئة فرعية تحمل الاسم نفسه عبر كل فئة من فئات المستوى الأعلى للذرات والجزيئات والكائنات الحية. في العرض التوضيحي لمعمل الأنماط ، تعد النماذج مثالًا جيدًا على ذلك. يتم سرد عناصر المجال الفردية تحت الذرات ، ويتم سرد مجموعة المجال والتسمية تحت الجزيئات ، وتظهر الحقول المتعددة المجمعة كشكل كامل تحت الكائنات الحية.

قد يكون التفكير المثير للاهتمام هو التفكير فيما إذا كان من الممكن تعريف الفئة باستخدام رد اتصال يحصل على العنوان والقصة والمسار إلى ملف القصة ... وأيضًا بعض البيانات الوصفية التي يمكن للمستخدم تمريرها لتكوين رد الاتصال.

storyData = {
  title: Component,
  category: ({ title, story, storyPath, meta }) => someCategoryPath,
  meta: { ..whateverMeta }
}

الشرط الوحيد هو أن رد الاتصال يحتاج إلى إرجاع كائن يحدد مسار الفئة للقصة:

storyData.category() //=> returns the below array

// a simple category path might look like:
[ "One category" ];

// The path for a story nested three categories deep would look like:
[ "Parent Category",  "Child Category", "Grandchild category where the story lives" ];

سيسمح هذا للأشخاص بكتابة أي نظام تصنيف يريدونه.

إذا كنت ترغب في الحصول على تهيئة عامة ، فيمكنك تسجيل ذلك داخل رد الاتصال واستخدام البيانات الوصفية المخصصة لتكوين الفئات / الفئات الفرعية التي تريد تسجيل القصة بها.

categories: [
  {
    "Atoms": [
      {
        "Buttons": []
      }
    ],
  }, {
    "Molecules": [],
}];

function setCategory({ meta }) {
  const { categroyPath } = meta; // maybe a dot path string like "Atoms.Buttons" ?
  const category = categroyPath.split('.'); // [ "Atoms", "Buttons" ]
  return validatePath(category, categories); // categories["Atoms"]["Buttons"] is a valid path
}

إذا كنت ترغب في تعيين هيكل الفئة بناءً على بنية الملف ، فلديك معلومات المسار للقيام بذلك.

function setCategory({ storyPath }) {
  // for story path `src/components/Atoms/MyComponent.story.js`
  let folders =storyPath.split('/'); // [ "src", "components", "Atoms", "MyComponent.story.js" ];
  folders = without(folders, 'src'); // ["components", "Atoms", "MyComponent.story.js" ];
  folders.pop(); // [ "components", "Atoms" ]
  return folders;
}

إذا كنت ترغب فقط في استخدام اسم فئة بسيط ، يمكنك فقط استخدام واحد! (وربما يمكن للفئة أن تأخذ واحدة من سلسلة بسيطة ، أو مصفوفة تصف مسار الفئة أو رد نداء يقوم بإرجاع مسار فئة).

الآن السماء هي الحد!

في ملاحظة مماثلة ، لتحديد ترتيب الفرز ، أقترح وظيفة addCategorySort يمكنك تسجيلها والتي تأخذ بنية فئة الشجرة التي تم إنشاؤها عن طريق تحميل جميع المجموعات النصية وفرزها.

import { configure, addCategorySort } from "@kadira/storybook";

addCategorySort( categories => /* sort logic here */ );

configure(loadStories, module);

travi لم أفكر في الحاجة إلى فئات ذات أسماء مكررة ، لكنني أوافق على أنها مهمة. اي افكار حول الحل؟ هذا ما يتبادر إلى ذهني ، ولكن ربما يوجد حل أفضل:

const storyData = {
  categories: ["Buttons"],  // any category with the title "buttons"
}

const storyData = {
  categories: ["Atoms.Buttons"],  // any category with the title "buttons" that also has the parent category "atoms"
}

theinterned أنا أحفر النهج ، لكني قلق من أنه قد يجعل الأمور أكثر صعوبة / أقل بديهية للمستخدمين

jackmccloy نعم ... أوافق على أن تنفيذ وظيفة لا ينبغي أن يكون مطلبًا للجميع. ولكن يبدو أن هناك عددًا من حالات الاستخدام المختلفة التي يتطلع الأشخاص إلى دعمها ، لذا يبدو أن نظام رد الاتصال هو طريقة لطيفة لتوفير إمكانية التمدد للجميع لتخصيص حالة الاستخدام الخاصة بهم.

لتهدئة القلق من أنه يجعل "الطريق السعيد" أكثر صعوبة ، أوصي بما يلي:

1. دع storydData.category يقبل سلسلة في هذه الحالة ستكون الفئة فئة من المستوى الأعلى.
2. دع storydData.category يقبل مصفوفة حيث العناصر في المصفوفة هي المسار إلى الفئة:

// given
storydData.category = ["grand parent", "parent", "story category"];
// category tree would look like:
categories = {
  "grand parent": {
    "parent": {
      "story category": /* the story lives here */
    }
  }
};

1. اسمح لبيانات القصة بقبول وظيفة كما هو موضح أعلاه (https://github.com/storybooks/react-storybook/issues/151#issuecomment-292689536).
2. يمكننا بالفعل كتابة عدد قليل من معالجات الفئات التي تغطي بعض حالات الاستخدام الشائعة لدينا هنا (التصميم الذري ، المستند إلى المجلد ...) ؛

وبالمثل بالنسبة للفرز ، يمكننا دعم الإستراتيجية الافتراضية (ألفا بلا شك) افتراضيًا وإذا كانت هناك حاجة يمكننا توفير استراتيجيات فرز أخرى مسبقة الصنع (الفرز بناءً على شكل الكائن ، وفرز الفهارس في البيانات الوصفية ، إلخ ...) ؛

ndelangen ماذا ترى

عندما أحصل على إشعار ، بدأ العمل من قبل أي شخص ويكون الحل الخاص به قابلاً للتطبيق ، أزل العلامة PR needed . إذن ، هذا حاليًا على خريطة الطريق ، لكن لم يتم إنجاز أي عمل بعد.

إذا كنت تريد البدء في ذلك ، فسيكون ذلك موضع ترحيب كبير!

jackmccloy هل يمكنني الانضمام والمشاركة في هذا العمل أيضًا إذا كنت لا تمانع؟

UsulPro 100٪ ، سأكون متحمسًا لذلك. تخطط لبدء إلقاء نظرة حقيقية عليها بعد ظهر يوم الأحد (بتوقيت مدينة نيويورك). إذا كنت متصلاً بالإنترنت في نفس الوقت ، فيمكننا نقل المحادثة إلى سلاك. وإلا فسوف أنشر هنا مع بعض الأفكار بعد أن أحفر قليلاً

jackmccloyusulpro أرغب بالتأكيد في العمل على هذا أيضا.

theinterned سيكون ذلك رائعا! الاتصال في الركود؟

UsulPro آسف - ضربت أنفلونزا المعدة السيئة بيتي.

لدي يوم اختراق في العمل يوم الجمعة وأخطط للعمل عليه بعد ذلك. هل سنحت لك الفرصة للبدء؟ سأكون سعيدًا بالمزامنة مع Slack. أنا في قناة SB.

إذا كنت تحتاج فقط إلى مستوى واحد من التداخل ، فقد تناسب React Storybook Addon Chapters احتياجاتك.

لقد قمت بإصدار الإصدار الأول من تطبيق @ igor-dv الممتاز للتسلسل الهرمي للقصص وأرغب في الحصول على تعليقاتك على ألفا حتى نتمكن من تحسينها قبل إطلاقها على المجتمع الأوسع:

https://gist.github.com/shilman/947a3d1d4cfdf5c3a8bb06d3d4eb84cf

@ 1i1itandrubotarunodaatnovemberdanielbartschfranzihubrickhadfieldniaanvnimsnifisuvorovjackmccloyjoeruellojohnnyghostlnmunhozmajapwmarkopavlovicmystetskyivladmzedelerndelangennirhart @ noahprince22revolunetsethkinasttheinternedthesisb traviusulproyangshunzeroasteriskzvictor

مجرد غرابة صغيرة لاحظتها في التسلسل الهرمي للقصة:
اعتمادًا على ما إذا كان الدليل يحتوي على أدلة فرعية يغير نتيجة النقر فوق دليل.
إذا كانت هناك عناوين فرعية ، فسيتم توسيع المجلد ، ولكن إذا كان منخفضًا عند مستوى المجموعة النصية ، فسيتم تحديد القصة تلقائيًا.
قد يرغب المستخدم في عرض محتويات dir دون تحديد قصة بالداخل.

تحديث:

يمكن أن تكون مرتبطة بهذه المشكلة في react-treebeard
https://github.com/alexcurtis/react-treebeard/issues/33
قد يكون من المفيد استكشاف العلاقات العامة هناك لـ storybooks/react-treebeard repo

في التطبيق السابق عند اختيار kind تم اختيار قصته الأولى تلقائيًا. لذلك أردت الحفاظ على هذه الوظيفة. ولكن ربما مع التسلسل الهرمي يبدو بالفعل وكأنه خطأ.

في الصورة ، Component 5 ليس دليلاً - إنه kind .

في الواقع أنا لا أحب هذا السلوك أيضًا ...

أسماء القصة الطويلة تلتف بغرابة

يؤدي تغيير حجم الشريط الجانبي ليكون صغيرًا جدًا إلى تجاوز جزء المعاينة فيه.

هل من الممكن دمج المجلدات الهرمية مع القصص الفردية؟ لدي بعض القصص التي أريدها في المستوى الأعلى ، وإلا لدي مجلد به عنصر واحد

حاليا إذا كنت تفعل هذا

storiesOf('Something', module).add('top story');
storiesOf('Something.Chapter', module).add('substory');

ثم يقوم بإنشاء مدخلين لـ "شيء ما" ، أحدهما بمجلد والآخر به عنصر

TheSisb ، شكرًا ، سيتم إصلاحه في الإصدار الرسمي.

psimyn ، في التطبيق الحالي هذا غير ممكن .. ولكن يمكن تغييره .. ذكر UsulPro هذا في العلاقات العامة الأولية أيضًا.
IMO هذا ليس سلوكًا جيدًا (ويجلب المزيد من التعقيد). بمقارنته بكل IDE ، توجد مساحات أسماء (dirs / مجلدات / حزم) ويمكن أن تكون بعض العناصر في مساحات الأسماء تلك (أو بالقرب منها) بنفس الاسم ..
على أي حال ، إذا كان هذا هو السلوك المرغوب فيه من المجتمع ، فيجب تغييره ، لكنني لا أرغب في أن يكون توقف الإصدار =)

هذا هو الحل الدقيق الذي احتاجه !!! شكرا لك +1

psimyn الرجاء فتح عدد جديد يصف الميزة؟ سيتم إغلاق هذا الإصدار بشكل حقيقي قريبًا بإصدار 3.2.0

هل من الممكن الآن الحصول على مستويات متعددة من التداخل باستخدام تنسيق CSF الجديد؟

@ gaurav5430 لقد كان ممكنًا لبعض الوقت ، انظر مثالنا هنا:

CSF:

import React from 'react';
import { linkTo } from '@storybook/addon-links';
import { Welcome } from '@storybook/react/demo';

export default {
  title: 'Other/Demo/Welcome',
  component: Welcome,
};

export const ToStorybook = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;
ToStorybook.storyName = 'to Storybook';

ياndelangen
شكرًا ، لقد حصلت على ذلك من هنا: https://storybook.js.org/docs/basics/writing-stories/#story -hierarchy

أعتقد أن ما أريده هو القدرة على إنشاء مجلدات فرعية بناءً على story.name وليس فقط عنوان التصدير الافتراضي

export default {
  title: 'Other/Demo/Welcome',
  component: Welcome,
};

export const ToStorybook = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;
ToStorybook.story = { name: 'to/Storybook' };

سيظهر كـ Other/Demo/Welcome/To/Storybook

أعتقد أن الحل البديل للمشكلة المذكورة أعلاه هو إنشاء ملفات قصة متعددة وتصدير افتراضي بالتسلسل الهرمي الصحيح في كل منها.

كما في one.stories.js :

export default {
  title: 'Other/Demo/Welcome/One',
  component: Welcome,
};

export const ToStorybookOne = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;

وفي two.stories.js

export default {
  title: 'Other/Demo/Welcome/Two',
  component: Welcome,
};

export const ToStorybookTwo = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;

بهذه الطريقة ، ستظهر كلتا القصتين كما هو متوقع في هيكل مجلد القصص القصيرة

@ gaurav5430 هذا هو الاستخدام الموصى به ، وليس حلاً. 😄

@ gaurav5430 هذا هو الاستخدام الموصى به ، وليس حلاً. 😄

نعم ، لقد كنت مترددًا في القيام بذلك لأن كلا الملفين لحالات مختلفة من نفس المكون. في حالتي ، يحتوي المكون على حالتين رئيسيتين وحالات فرعية متعددة بناءً على هاتين الحالتين الرئيسيتين. عادةً ما احتفظ بجميع حالات المكون في نفس الملف ، لكن في هذه الحالة سأحتاج إلى ملف منفصل للتسلسل الهرمي في القصص.