-
Notifications
You must be signed in to change notification settings - Fork 1k
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
chore(story📗): extract MSW logic into a loader #4919
Conversation
✅ Deploy Preview for redwoodjs-docs canceled.
|
50c2ea3
to
ff4f832
Compare
@virtuoushub awesome! |
@virtuoushub are you waiting on us for this one? Sorry, wasn't clear if this was ready to go or not. If so, should we loop in anyone else for review? Thanks! |
@thedavidprice in theory it is ready to go. That being said, I do want to start getting some of this stuff unit tested; so any recommendations on that front are greatly appreciated. |
ff4f832
to
88c5517
Compare
88c5517
to
f14209d
Compare
@dac09 You had some ideas about better testing for Storybook — not sure how to implement other than via functional tests using Playwright? I can definitely run through QA locally via project:sync @virtuoushub Given that I'm out of my depth here, any thoughts on whether we need to loop in Yann or Michael for a once-over? |
f14209d
to
effc2f7
Compare
gentle bump to @dac09 to get your thoughts on how we might test this change.
At this time, I do not think so. A lot of this code came from a direct discussion with Yann. |
So only real way to test something like this is the playwright e2e test as you suggested! @virtuoushub - I've read through the links and it makes sense to use loaders, but the missing pieces for me are: Would apperciate a screen recording, or if you prefer we can connect real time! |
briefly spoke with the Storybook team on this and there is little risk in adopting loaders even though they are still experimental.
Updated the description, but tl;dr is because loaders happen before render this helps with integration testing.
👍🏻 |
effc2f7
to
dad672d
Compare
Yo sorry @virtuoushub - I pulled in your changes into my branch, and I think codespaes accidentally pushed some of mine into your branch (auto sync maybe?) |
experiment with loaders the loaders are async and execute before the story is rendered https://storybook.js.org/docs/react/writing-stories/loaders https://mswjs.io/ Co-authored-by: Yann Braga <[email protected]>
a7d6877
to
bc89956
Compare
No problem, it looks like from the testing in #5329 this PR is ready to be merged ( cc @jtoar / @thedavidprice ) |
Yup I pulled in your changes into the PR, so lets wait for it to pass and we should be good to go. Github will probably automatically close! |
…ok-smoke-test * 'main' of github.com:redwoodjs/redwood: Remove extra checkout in RC workflow (redwoodjs#5414) chore(deps): update dependency @azure/msal-browser to v2.24.0 (redwoodjs#5412) fix(deps): update react monorepo (redwoodjs#5406) cli upgrade: Always search from the start for semvers (redwoodjs#5368) codegen graphql schema (redwoodjs#5213) fix(deps): update dependency core-js to v3.22.4 (redwoodjs#5409) fix(deps): update typescript-eslint monorepo to v5.22.0 (redwoodjs#5410) Add graphql-scalars to graphql-server (redwoodjs#5408) Update yarn.lock v1.2.1 fix(deps): update dependency cross-undici-fetch to v0.3.6 (redwoodjs#5402) fix(deps): update dependency cross-undici-fetch to v0.3.5 (redwoodjs#5398) fix(deps): update dependency cross-undici-fetch to v0.3.3 (redwoodjs#5378) chore(story📗): extract MSW logic into a loader (redwoodjs#4919)
the loaders are async and execute before the story is rendered.
Why this matters:
interaction testing
Because using a loader happens before a story is rendered, we do not have to worry about the mock data being unavailable to a component. With the previous approach, we possibly had to wait for a couple render cycles in order to guarantee the mock data was available to the component.