What's up?

Now that we made the proxy API great again, it's time to target our next victim. 😈

The README starts with this proposition:

Cosmos scans your project for components and enables you to...

Indeed Cosmos scans your project for components, but the API is terrible. Namely, componentPaths, fixturePaths, getComponentName are rigid and confusing. These options work if A. your project structure is perfectly organized or B. you know how Cosmos works inside out. Not a #PainlessOnboarding!

Mkay, tell me more...

I've worked with several large codebases lately and I've reached the conclusion that the filesystem API should primarily focus on giving users full control over which components to add to Cosmos where to import them from. This is not a matter of improving documentation, but making the API obvious and flexible in the first place.

Note: My plan is to support the existing options indefinitely and add complementary ones on top. This only affects an isolated part of the project (react-cosmos-voyager) so it won't add much maintenance cost.

The new API is meant to accommodate any level of control, from manually targeting and naming fixtures to letting Cosmos guess where your components are.

Level 0: Control freak

Manually target component and fixture files. Supports any file structure and allows manually naming components and fixtures.

// cosmos.config.js
{
  components: {
    Foo: './src/components/Foo',
    Bar: './src/components/Foo'
  },
  fixtures: {
    Foo: {
      one: './src/components/Foo/__fixtures__/one',
      two: './src/components/Foo/__fixtures__/two'
    },
    Bar: {
      one: './src/components/Bar/__fixtures__/one',
    }
  }
}

Users with intricate codebases can automate on top of this by using glob and similar tools.

Level 1: I did it my way

Manually target component files, place fixtures by convention. Supports any component file structure and allows manually naming components.

// cosmos.config.js
{
  components: {
    Foo: './src/components/Foo',
    Bar: './src/components/Foo'
  }
}

This will work:

components/Foo/index.js
components/Foo/__fixtures__/one.js
components/Foo/__fixtures__/two.js

This will also work:

components/Foo.js
components/__fixtures__/Foo/one.js
components/__fixtures__/Foo/two.js

A nice feature of Level 0 and 1 is the ability to whitelist which components to load, instead of adding tons of ignore rules.

Level 0 and 1 can be implemented and shipped alone. The following levels are here to create a big picture and should be implemented separately to avoid monster PRs.

Level 2: Let it be

Manually target component directories, place components and fixtures by convention. Supports multiple component directories (eg. components and containers).

// cosmos.config.js
{
  componentDirs: ['./src/components']
}

This works similar to the existing componentPaths, but should do fewer things. No more fixturePaths or getComponentName. There is Level 0 and Level 1 for that level of customization.

Level 3: How did you do that?

// cosmos.config.js
// *crickets*

Try our best at detecting the component dirs based on popular patterns. Searching for ./components, ./src/components, etc. If it doesn't work out we ask the user to define componentDirs and go back to Level 2.

Notes:

• fixturesDir will continue to work for the new API, so the __fixtures__ convention can be customized
• I will not be working on this due to other priorities, so anyone can pick it up
• v2 will be released without this, but it's meant to be backwards compatible anyway

What do you think?

@flaviusone @NiGhTTraX @ovidiubute @tkjone @xavcz @amrdraz @jlc467 @maciej-ka This is a draft so I'd love to hear your feedback!

As far as I can see, Cosmos really struggles to be useful when working with responsive layouts / media queries. In Chrome, the only way I can get a media query to trigger is to go full screen and make my window small. Using the device toolbar in Dev Tools doesn't work, even in full screen mode.

Does anyone have any better 'no work required' solutions? I'd love to delete this PR!

I've whipped up a very quick proof of concept PR for adding responsive development tools to Cosmos:

The UX is very much a placeholder, but the rough idea is that users can define their own list of dimensions and labels (perhaps via their cosmos.config), which we show on the top. I'll also add support for an adhoc dimension option directly in the UX. You can trigger the responsive layout directly from a fixture with a specific dimension, or you can toggle it with the new responsive button next to the full screen button. I'd also like to add support for setting the background color, but perhaps that's better done in a proxy?

If a dimension is too big to fit in your window, we faithfully reproduce it and scale the contents, so you can still see exactly what your content might look like on e.g. a 1080p screen.

Credits due to https://docs.catalog.style/specimens/react#display-all-defined-screen-sizes-1 where I got some of the ideas (and CSS!) for this.

This originally started off as a proxy, but a brief chat with @skidding a couple weeks ago suggested this will be better both in terms of the development side and the user experience side if it's a core feature.

However, I need some help from @skidding please. If you load a fixture that has props, and change the screen size, it crashes. Hopefully it's something obvious, any thoughts?

I didn't want to put too much effort in yet until there's no 'major' blockers in terms of getting the cosmos fundamentals to work with this model.

What's up?

Cosmos v3 beta is out, including the new filesystem API and Playground Tree View.

Always install react-cosmos-webpack@next to get the latest beta

Mkay, tell me more...

To include in the public release:

• @skidding ~~Add exclude option to complement new fileMatch option for matching fixture files. I deliberately chose a different name than the previous ignore to avoid confusion. Start here.~~ #479
• @maxsalven ~~Persisted Tree View~~ #482
• @skidding ~~Add React Error Handling in Loader~~ #481
• @skidding ~~Surface rootPath as projectKey in Playground~~ #485 (complements #471)
• @maxsalven ~~Support for fixture nesting in tree view (right now only component names are expanded)~~ #483
• @Timer ~~Add react-error-overlay~~ #484
• @skidding ~~Capture when Loader iframe points to missing index.html and show Playground message with instructions (one of the most common onboarding issues) + Update CP onboarding + Loading bundle message~~ #498
• @skidding ~~Update README to reflect new fixture format and config~~ #501
• @skidding ~~Rename react-cosmos-webpack to react-cosmos~~ #501

Please post any feedback or update in this thread. I will keep it open until we make v3 official. Thanks!

What's up?

There is no documentation on how to load multiple fixture inside a group when using react-cosmos-loader's mount() method

Mkay, tell me more...

I'm using react-cosmos with Fusebox and have a custom implementation so I have to use the mount() method inside the react-cosmos-loader package.

Considering the following code

const { mount } = require("react-cosmos-loader");
const someFixture = require("./some-fixture.fixture");

mount({
  proxies: [],
  fixtures: {
    "test": someFixture
  }
});

Generate this:

But how can I have multiple fixture under that group using the API from mount() ???

Fixes #445

This PR adds the ability to:

• change locally the Apollo cache to mocks responses and re-run queries / mutations based on this cache
• pass your own link (ex: HttpLink) to connect to a GraphQL API and get real responses

The Apollo Proxy listens to cache changes (thanks to the Apollo DevTools hook provided in Apollo Client 😇) and sends it to the fixture editor under the key apollo.

This makes the playground reloads and the Apollo Proxy re-instantiate a client with a restored cache from the fixture: this means you can also add the result of cache.extract() manually to your fixture. I'm using a method as similar as the one recommended for server-side rendering 💃

It may not be the optimal solution to mock components fetching data through React Apollo, but that's a first step forward!

If people really want to mock with a specific result, we may provide a client like the one shown in this article?

What are your thoughts? cc @maxsalven @dan-weaver

Remaining:

• [x] update README if we believe it's a valid step forward 🌮
• [x] test it in a way that makes sense (not like now)

Component page

• [X] Allow component to be selectable in nav
• [X] Display a component page
• [ ] Create frameset for each fixture
• [ ] Insert different components into framesets
• [ ] Display legend

partially closes: https://github.com/react-cosmos/react-cosmos/issues/314

What's wrong?

When trying to get started I get this error:

ERROR in ./app/expenses/components/Category/index.fixture.tsx 3:16
Module parse failed: Unexpected token (3:16)
File was processed with these loaders:
 * ./node_modules/ts-loader/index.js
You may need an additional loader to handle the result of these loaders.
| import Category from '.';
| import ReduxStub from "../../../../tests/ReduxStub";
> export default (<ReduxStub>
|     <Category />
|   </ReduxStub>);
 @ ./node_modules/react-cosmos/dist/plugins/webpack/client/userDeps.js 7:56-150
 @ ./node_modules/react-cosmos/dist/plugins/webpack/client/index.js
 @ multi ./node_modules/react-cosmos/dist/domRenderer/reactDevtoolsHook.js ./node_modules/@skidding/webpack-hot-middleware/client.js?reload=true&overlay=false ./node_modules/react-cosmos/dist/plugins/webpack/client/index.js

This seems to be because the added ts-loader is incorrectly configured — or perhaps the include path of the loader.

Steps to reproduce

1. Create a tsx file in ./app/.../here, and a redux stub provider outside of the ./app in ./tests
2. Reference the stubbed redux provider from the component.fixture.tsx
3. See the above error

Screenshots

I'm going to bed, but this should get you started.

If you'd like, you can tell me what adjustments to make and I'll see what I can do. 😄

I'm not familiar with react-cosmos, so I added build and runtime error reporting to where I felt it made most sense.

http://g.recordit.co/LGb1qX9yJw.gif

Enables all react-error-overlay features: runtime errors, click-to-open source, and build time errors.

Issue: https://github.com/react-cosmos/react-cosmos/issues/217

With this PR, fixture props are expected to be attributes of fixture.props instead of the the root-level fixture.

Also in this PR: local-state example shows how to use props in a fixture.

To test backwards compatibility, I copied the local-state example and put props at the root-level, then added a FixFixturePropsProxy to cosmos config to confirm the props come through. Before merging, I imagine this example will be deleted and the proxy extracted into some kind of markdown documentation in the release notes.

Haven't looked into codemods yet, but figure that can come later.

About

Fix https://github.com/react-cosmos/rfcs/issues/13#issuecomment-598925864

Notes

Haven't tested this yet - looking to see if this is the way we want to go about adding sync support 👍

Issue #252

• [x] Create separate Component, component-playground.jsx has seen enough battles
• [x] Screen for no components, no fixtures
• [x] Screen for components & fixtures
• [x] Screen for components but no fixtures
• [x] Jest unit-tests
• [x] ComponentPlayground unit-tests

What's wrong?

• When adding a component to a fixture like Plate it will give me tons of undefined errors (likely for each render). I could only narrow it down to this specific component.

• It does not occur when running my normal cra setup (with craco), so I'm wondering if there is some injection taking place from react-cosmos. And it does not occur in Chrome, only Brave, probably because Brave is stricter in their CORS policy?

What I noticed that if I go to the fixture, and modify/toggle a property in the right sidebar first, before interacting with the editor, the errors don't occur!.

Summary / Steps to reproduce

1. Add basic Plate editor component

2. Click in the editable body / try typing

3. See the same error repeat

4. Change a prop on the right

5. Error changes into a CORS error, and seemingly has the same stacktrace, but more readable

Screenshot

react_devtools_backend.js TypeError: Cannot set properties of undefined (setting +'hook')

And I thought I couldn't debug this further because of the anonymity of the error, however, after toggling a property, the error happens only once, but in a different form, and I'm pretty sure it's the same, seeing the line: 4026 is the same:

react_devtools_backend.js:4026 DOMException: Blocked a frame with origin "http://localhost:5000" from accessing a cross-origin frame.
    at JSON.stringify (<anonymous>)
    at Object.parseData (<anonymous>:8:116)
    at <anonymous>:10:2186
    at Array.reduce (<anonymous>)
    at <anonymous>:10:2114
    at i (<anonymous>:10:2706)
    at t.onCommitFiberRoot.t.onCommitFiberRoot (<anonymous>:10:3098)

So from what I can gather this is definitely a react-cosmos problem, but why it only occurs with Plate I have no clue. (I tried it with a simple component with contentEditable but no)

User info

• Cosmos version 5.7.2
• Browser: Brave Version 1.45.127 Chromium: 107.0.5304.110 (Official Build) (64-bit)

See also #1287

I recently converted my webpack.config.js to an ESM version webpack.config.mjs only to discover I broken my react-cosmos setup.

I would be really nice if react-cosmos supported webpack.config.mjs natively. Failing that, it should at least document how to handle this case and present a suitable error message with a link to the documentation.

Looking at #1287 it looks like it should probably also handle TypeScript webpack.config.ts too.

Not putting up a PR just now because I believe it's unlikely to be accepted until after v6.0.0 is released.

For now I've just patched react-cosmos locally using patch-package based on the changes I made here: https://github.com/birtles/react-cosmos/commit/d2cf4e1a10630273b89c7928d72e46edc91dc108 which looks for webpack.config.mjs if it fails to find webpack.config.js. It also tries to load .mjs files using import() but using the esm package as suggested in #1287 might be a simpler solution.

(I also have a similar but less complete changeset that applies against main here https://github.com/birtles/react-cosmos/commit/2743c6b0d0ebc0ee00ebdadb2d6978889d772783)

What is the status of Gatsby support? React Cosmos looks fantastic, but I can't get it to work for components in Gatsby with the default configuration.

At first, big thanks for React Cosmos, I find it really helpful tool! 🥇 👍

What's wrong?

Fixtures with FetchMock stopped working (fetch-mock doesn't return the declared response anymore) after upgrading create-react-app from 4.0.3 to 5.0.1.

Steps to reproduce

I have created sample application for reproducing this problem.

• On this branch, with CRA 4, it works correctly: https://github.com/gcwiak/cra-vs-react-cosmos/tree/cra_4-react_cosmos_fetch

1. Start React Cosmos with npm run cosmos
2. Open App fixture
3. Fixture is rendered correctly, showing the FROM_Fixture text provided by FetchMock:

• On this branch, with CRA upgraded to 5, it fails to mock the fetch call https://github.com/gcwiak/cra-vs-react-cosmos/tree/cra_5-react_cosmos_fetch

1. Start React Cosmos with npm run cosmos
2. Open App fixture
3. Nothing is rendered, console shows the following errors

Uncaught TypeError: Cannot read properties of undefined (reading 'decode')
    at new URLStateMachine (url-state-machine.js:547:1)
    at module.exports.basicURLParse (url-state-machine.js:1260:1)
    at new URLImpl (URL-impl.js:13:1)
    at Object.setup (URL.js:376:1)
    at new URL (URL.js:31:1)
    at normalizeUrl (request-utils.js:70:1)
    at Object.normalizeRequest (request-utils.js:96:1)
    at FetchMock.fetchHandler (fetch-handler.js:119:1)
    at DataFetchingComponent.tsx:8:1
    at invokePassiveEffectCreate (react-dom.development.js:23487:1)
    at HTMLUnknownElement.callCallback (react-dom.development.js:3945:1)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:3994:1)
    at invokeGuardedCallback (react-dom.development.js:4056:1)
    at flushPassiveEffectsImpl (react-dom.development.js:23574:1)
    at unstable_runWithPriority (scheduler.development.js:468:1)
    at runWithPriority$1 (react-dom.development.js:11276:1)
    at flushPassiveEffects (react-dom.development.js:23447:1)
    at react-dom.development.js:23324:1
    at workLoop (scheduler.development.js:417:1)
    at flushWork (scheduler.development.js:390:1)
    at MessagePort.performWorkUntilDeadline (scheduler.development.js:157:1)
URLStateMachine @ url-state-machine.js:547
module.exports.basicURLParse @ url-state-machine.js:1260
URLImpl @ URL-impl.js:13
setup @ URL.js:376
URL @ URL.js:31
normalizeUrl @ request-utils.js:70
normalizeRequest @ request-utils.js:96
FetchMock.fetchHandler @ fetch-handler.js:119
(anonymous) @ DataFetchingComponent.tsx:8
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
(anonymous) @ react-dom.development.js:23324
workLoop @ scheduler.development.js:417
flushWork @ scheduler.development.js:390
performWorkUntilDeadline @ scheduler.development.js:157
index.js:1 The above error occurred in the <DataFetchingComponent> component:

    at DataFetchingComponent (http://localhost:4000/main.js:197:76)
    at p
    at header
    at div
    at App
    at FetchMock (http://localhost:4000/main.js:506:34)
    at __WEBPACK_DEFAULT_EXPORT__
    at FixtureElement (http://localhost:4000/main.js:56809:24)
    at FixtureCapture (http://localhost:4000/main.js:55239:23)
    at ErrorCatch (http://localhost:4000/main.js:59771:5)
    at FixtureProvider (http://localhost:4000/main.js:56607:24)
    at FixtureLoader (http://localhost:4000/main.js:56233:5)
    at DomFixtureLoader (http://localhost:4000/main.js:59586:23)

React will try to recreate this component tree from scratch using the error boundary you provided, ErrorCatch.

User info

• Server terminal output

$ npm run cosmos

> [email protected] cosmos
> cosmos

[Cosmos] Using cosmos config found at cosmos.config.json
[Cosmos] Serving static files from public
[Cosmos] See you at http://localhost:4000
[Cosmos] Using webpack config found at node_modules/react-scripts/config/webpack.config.js
[Cosmos] Building webpack...
webpack built 4178d5585cd9efc6250f in 4372ms
WARNING in ./node_modules/@base2/pretty-print-object/dist/index.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/Users/grzegorz/workspace/cra-vs-react-cosmos/node_modules/@base2/pretty-print-object/src/index.ts' file: Error: ENOENT: no such file or directory, open '/Users/grzegorz/workspace/cra-vs-react-cosmos/node_modules/@base2/pretty-print-object/src/index.ts'

WARNING in DefinePlugin
Conflicting values for 'process.env'

WARNING in [eslint] 
src/App.fixture.tsx
  Line 6:1:  Assign arrow function to a variable before exporting as module default  import/no-anonymous-default-export

1 WARNING in child compilations (Use 'stats.children: true' resp. '--stats-children' for more details)
webpack compiled with 4 warnings
No issues found.

• Cosmos version: 5.7.2
• react-mock/fetch version: 0.3.0
• Cosmos config

{
  "port": 4000,
  "staticPath": "public",
  "watchDirs": ["src"],
  "webpack": {
    "configPath": "react-scripts/config/webpack.config"
  }
}

First of all, I really appreciate you putting in the work of creating a component testing framework and making it bundler agnostic. It's what made me drop storybook ;)

Your docs say "how you compile your code is 100% your business" and that we can make it work with other bundlers. I don't see any guidance on how to do this though? What are the important steps? How does react-cosmos look for the renderer html? Where do I register my custom logic? Is there a `require('react-cosmos').listen(12345)' step?

I think it would be great if you could tell us how to integrate other bundlers. I'd be willing to write up a "how-to" guide with esbuild if you could point me in the right direction.