Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass JSON example data to components / snippets #1

Open
moonglum opened this issue Oct 15, 2018 · 7 comments
Open

Pass JSON example data to components / snippets #1

moonglum opened this issue Oct 15, 2018 · 7 comments

Comments

@moonglum
Copy link
Member

No description provided.

@moonglum
Copy link
Member Author

We need to offer a way to pass in JSON data to fill the component with example data.

@blynx blynx changed the title Support for mustache templates Pass JSON data to component Jul 13, 2019
@blynx blynx changed the title Pass JSON data to component Pass JSON example data to components / snippets Jul 13, 2019
@blynx
Copy link
Collaborator

blynx commented Jul 13, 2019

Yep! :)

Yet, I just noticed this: What if we have multiple snippets in one document. How do we determine what data goes into which snippet.

We could argue that you probably might only need one data file per document, because that document would only cover a component and its variants. So it would not need different data sets and we could implement a simple convention.

But actually I want to be free to create documents which cover different topics ...

I think it is probably the business of the language processor to be able to choose the data sources so it would need the ability to know about the location of the sources. What do you think?

@moonglum
Copy link
Member Author

But actually I want to be free to create documents which cover different topics ...

I agree, we should not restrict people artificially. That's one of the things that is annoying in existing solutions.

I think it is probably the business of the language processor to be able to choose the data sources so it would need the ability to know about the location of the sources.

Can you describe this in more detail? How would the language processor do that?

@blynx
Copy link
Collaborator

blynx commented Jul 15, 2019

When adding components into the documents via codeblock, aiur can't really know which components get imported by the templating language in that block. You might want to use different data blobs for different components, though.

For JS languages this is no problem as it's obvious to just import data right from there - but what about other languages as Thymeleaf or Handlebars, etc ... ?

I was thinking that you could add some metadata to Thymeleaf templates or add HTML comments in Handlebars templates for example. The language processor would need to know a little bit more about the locations I think.

@FND
Copy link
Collaborator

FND commented Jul 16, 2019

Instead of making aiur distinguish which data is provided to which snippet, why not let snippets decide themselves?

data:
    abc123:
        title: Hello World
        tags:
        - foo
        - bar
    def456:
        title: Lipsum
        tags:
        - 

One snippet might use {{context.abc123.title}} while another references {{context.def456.title}}. (That's pretty much how it works with Fractal.)

@blynx
Copy link
Collaborator

blynx commented Jul 16, 2019

Where is that data put? In a YAML beside the document?

Ah, I think what's missing regarding my thought: I was actually thinking about using the production templates/components in the styleguide but providing them with different data to present different states or so... So the variables in the templates would have the same names but different data would have to be provided.

But for certain templating languages actually yes, they can handle that themselves.

@FND
Copy link
Collaborator

FND commented Jul 16, 2019

I was assuming some sort of adjacent YAML/JSON/… file, as with Fractal.

Personally, I wouldn't recommend (re)using application templates within the pattern library, as that creates coupling we (I) actually wanna avoid - though I can certainly see the appeal. (FWIW, in a recent presentation, Brad Frost briefly mentions that he doesn't like that approach in the Storybook community.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants