Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

screen.openTestingPlayground()? 馃 #780

Closed
kentcdodds opened this issue Oct 8, 2020 · 14 comments
Closed

screen.openTestingPlayground()? 馃 #780

kentcdodds opened this issue Oct 8, 2020 · 14 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@kentcdodds
Copy link
Member

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
Copy link
Member

I like. Approved !!!

@smeijer
Copy link
Member

smeijer commented Oct 8, 2020

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
Copy link
Member Author

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
Copy link
Member

smeijer commented Oct 8, 2020

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
Copy link
Collaborator

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
Copy link
Collaborator

alexkrolick commented Oct 8, 2020

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
Copy link
Member

smeijer commented Oct 9, 2020

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

statefull-url

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.

@marcosvega91 marcosvega91 added enhancement New feature or request help wanted Extra attention is needed labels Oct 9, 2020
@balavishnuvj
Copy link
Contributor

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

@marcosvega91
Copy link
Member

I think that you can go with this. Thanks for the help 鉂わ笍

@delca85
Copy link
Member

delca85 commented Oct 12, 2020

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

@marcosvega91
Copy link
Member

We can close this issue :) thaaanksss

@pavelloz
Copy link

I started to use logPlaygroundUrl and i quickly found that im copying and pasting the url to see whats what.
Immediately i tried to write a helper to open (npm package open) the url automatically in the browser.

Any chance of exposing the URL under some method, or maybe even better, passing { open: true } into screen.logTestingPlaygroundURL() to save a lot of time and clicks?

@MatanBobi
Copy link
Member

Hi @pavelloz!
We've just merged a pr to also return the value of the playground url, I think this serves your first request, doesn't it?

@pavelloz
Copy link

@MatanBobi Yes! Thank you, i missed that one.
This is such a great feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

8 participants