search

react-cosmos / rfcs

Change requests for React Cosmos
MIT License
1 stars 2 forks source link

Cosmos Export Separate Documents #9

Open jamiebuilds opened 4 years ago

jamiebuilds commented 4 years ago

What's up?

In a CI environment I might want to run other tools against all (or some) of my fixtures. This might be something like visual regression tests or maybe some scripts written with Puppeteer to do smoke testing.

In those scenarios, I probably wouldn't care very much about the Cosmos UI itself, I'd just want to have statically built pages that I could use in other tools.

pages=$(cosmos-export --pages) # or some other flag, idk
# ./path/to/built/fixture.html
# ./path/to/other/built/fixture.html

for page in "${pages}"; do
   ./scripts/run-smoke-tests-on-page "${page}"
done

Mkay, tell me more...

This could potentially be extended by other tools out of the box:

cosmos-export --pages | cosmos-browser-visual-regressions
cosmos-export --pages | cosmos-etc
ovidiuch commented 4 years ago

In those scenarios, I probably wouldn't care very much about the Cosmos UI itself, I'd just want to have statically built pages that I could use in other tools.

Just realized the getFixtureUrls example is outdated. If you call it with fullScreen set to true it will actually return URLs that don't include any Cosmos UI. The full screen URLs basically load the renderer iframe content with a fixture ID parameter.

jamiebuilds commented 4 years ago

Hmm... I think it would be better to have something even more "pure" than that, where it's just static HTML pages with "no" runtime (short of rendering the component with ReactDOM.render()) or routing logic. 

<!doctype html>
<html>
  <body>
     <div id="root"></div>
     <script src="./path/to/fixture-entry-point.js"></script>
  </body>
</html>

The benefit is that you can write scripts with tools like Puppeteer without having to be concerned with any implementation details of how Cosmos works. If you want to select an element, you just query for it, you don't have to select the iframe and enter its context or anything.

It would also be nice if these separate HTML files pointed to separate entry points for each different fixtures so that loading one fixture didn't load all of them. This makes the pages load faster, and also makes it faster to parallelize work on different fixtures in scripts.