作者： | 来源：互联网 | 2023-10-11 19:18
We (storybook team) think this is a really interesting project, and we'd love to help getting first class support for SB in the project (as mentioned in the README).
One thing that's especially interesting is the Cell files; you don't need to squint very hard to see they look a lot like story files (as pointed out by -yx).
We've been thinking about it and we reckon someone could pretty easily write a babel plugin or webpack loader to compile a Cell file to a CSF file. This would be similar to the way that Storybook natively supports MDX by compiling it to CSF via a webpack loader.
That would mean that a user of Redwood could have a storybook setup where they just point SB at all their cell files and get a bunch of stories for free. That'd be pretty amazing! I'm sure there are lot more points we could integrate but this one seems like the most interesting (to me anyway).
Here's a bit of detail on how it might work:
If you take the example UsersCell.js file from the homepage:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| js export const QUERY &＃061; gql&＃096; query USERS { users { id name } } &＃096; export const Loading &＃061; () &＃061;> Loading users... export const Empty &＃061; () &＃061;> No users yet! export const Failure &＃061; ({ message }) &＃061;> Error: {message} export const Success &＃061; ({ users }) &＃061;> { return (
{ users.map(user &＃061;> (
- {user.id} | {user.name}
))}
) } |
The compiler might compile it to something like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| js export default { title: &＃039;UsersCell&＃039;, } const QUERY &＃061; gql&＃096; query USERS { users { id name } } &＃096; export const Loading &＃061; () &＃061;> Loading users... export const Empty &＃061; () &＃061;> No users yet! export const Failure &＃061; ({ message }) &＃061;> Error: {message} Failure.story &＃061; { args: { message: faker.string() } }; export const Success &＃061; ({ users }) &＃061;> { return (
{ users.map(user &＃061;> (
- {user.id} | {user.name}
))}
) } Success.story &＃061; { args: { users: generateMockFromQuery(QUERY) } } |
To implement the
function we could use Apollo's query mocking code.
[Note that the syntax above uses the new args feature that's coming in SB6 and we are publishing an RFC about this week, but hopefully you get the idea!]
If the user wanted to write a set of specific stories (i.e. for different values of
in the success case), I guess a generator that generated a story file that just imported from the Cell and re-exported would make sense.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| js
import { QUERY, Loading, Empty, Failure as FailureInput, Success as SuccessInput } from &＃039;./UsersCell&＃039;;
export default {
title: &＃039;UsersCell&＃039;,
}
export { Loading, Empty };
export const Failure &＃061; props &＃061;> ;
Failure.story &＃061; {
args: { message: faker.string() }
};
export const Success &＃061; props &＃061;> ;
// User can override this or make multiple stories based on &＃096;SuccessInput&＃096;
Success.story &＃061; {
args: { users: generateMockFromQuery(QUERY) }
} |
Another option is the single-file components (that combine cells and stories) that -yx mentioned, but I'm not sure of folks' appetite for that.
该提问来源于开源项目：redwoodjs/redwood
I've been playing around with Storybook on a non-Redwood project, and one thing that's been really nice is pairing it with GraphQL mocking. Since we're embracing GraphQL, we should be prepared to automatically run a mocked GraphQL server on the same port / location as the normal one as part of our Storybook development flow (whatever would run when we type the imaginary command
/
)
Just something to think about when we do finally implement this.
京公网安备 11010802041100号