Dom-testing-library: screen.openTestingPlayground()? 🤔

[kentcdodds]

Ok ok, get here's my idea... Often I tell people: "Add a screen.debug() and copy/paste the HTML output into testing-playground.com"

What if...

screen.openTestingPlayground()

And it just opened a testing playground with all their HTML set in there automatically!??!? Thoughts on this idea? Good/bad? I'm sure it could be improved.... Just a random thought I had.

cc @smeijer

[marcosvega91]

I like. Approved !!!

[smeijer]

Sounds great. Testing-playground.com supports two ways of receiving state trough urls.

1. A get param. I need to document the details. But it's something like testing-playground.com?markup=.... The markup is compressed and encoded with lz-string

2. A post action that stores the code in the backend (github gists). The post action returns a shorter sharable url, based on the gist ID.

The first has as downside that urls have a max length. Depending on how large the debug info is, this can become a problem. (max ~2000 chars if I remember correctly).

The second has as downside that markup is stored on a server. Not everyone might like that.

[kentcdodds]

Let's start with option 1 (which I'm guessing would be simpler) and then we can build option 2 if people say they want it. I wonder whether it would be possible to determine whether something's too big for the encoded URL and if it is prompt the user to ask them whether they'd like it saved to a gist first 🤔

[smeijer]

That check would be easy as pie. We would only need to be sure about the max url length limit.

Edit, hardest part about the post option, would be to prevent spamming. We don't want that a jest watch or wallaby starts posting on every test run.

So yeah, option 1 is definitely easier to implement.

[alexkrolick]

I think you'd want to use #markup=... (hash params) rather than query strings (?markup=) to prevent the server from seeing the value at all

[alexkrolick]

Also, I just saw that the newest VSCode release has support for webviews in panels. It would be interesting to build an extension for debugging DOM tests using that. Not everyone uses VSCode, but a lot web devs do.

[smeijer]

I've updated testing-playground to iron out some kinks to make this possible.

I'll leave the final implementation up to someone else. But here's the snippet to make it work:

repl

const { compressToEncodedURIComponent } = require('lz-string');

function unindent(string) {
  return (string || '').replace(/[ \t]*[\n][ \t]*/g, '\n');
}

function encode(value) {
  return compressToEncodedURIComponent(unindent(value));
}

function getPlaygroundUrl(markup = '', query = '') {
  return `https://testing-playground.com/#markup=${encode(markup)}&query=${encode(query)}`;
}

getPlaygroundUrl('<!-- markup here -->', '// and query here');

This outputs the following url:

https://testing-playground.com/#markup=DwQgtGAEC2CGBOBrArgB0gCwKby5CAfEA&query=PTAEEMDsBNQRwK4FMBOBPUALVSg

The unindent is optional, but doing so shaves off a few bytes. Testing-Playground formats the code on page load. So the indentation will be lost any ways.

Both markup and query are optional. Feel free to leave one of them out. Although, it would be awesome to include the query when we know which one is making the test fail.

[balavishnuvj]

has anyone picked this up? If not, I can pick it up :)

[marcosvega91]

I think that you can go with this. Thanks for the help ❤️

[delca85]

I think the same! Please share any doubts if you have some. Thanks a lot!! 🔝

[marcosvega91]

We can close this issue :) thaaanksss