-
-
Notifications
You must be signed in to change notification settings - Fork 941
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
Add lazy loadable faker to our documentation #3129
Comments
Why is StackBlitz or pressing |
I can see that this would be more of a convenience thing. While stackblitz is great for full examples, it brings a lot of bloat as well. I usually have to wait for around 30 seconds until I see the first results in the stackblitz browser view. Additionally, when you only want to log the result of a script, you have to do some extra steps to view the console output (open in separate window, connect, then view console). Alternatively, you throw the result into the html. Then, you might run into problems with the format of the stringified result ( The github web editor works well for testing simple use cases on the type level where you don't have to run the actual code. Using terminals is not possible in the integrated GitHub web editor (without having to set up a codespace) which makes it impossible to run small scripts (like verifying that a workaround actually works). |
1 similar comment
I can see that this would be more of a convenience thing. While stackblitz is great for full examples, it brings a lot of bloat as well. I usually have to wait for around 30 seconds until I see the first results in the stackblitz browser view. Additionally, when you only want to log the result of a script, you have to do some extra steps to view the console output (open in separate window, connect, then view console). Alternatively, you throw the result into the html. Then, you might run into problems with the format of the stringified result ( The github web editor works well for testing simple use cases on the type level where you don't have to run the actual code. Using terminals is not possible in the integrated GitHub web editor (without having to set up a codespace) which makes it impossible to run small scripts (like verifying that a workaround actually works). |
Also in stackblitz working with the result is hard. Like when you want to explore the result of your statement to check for the next thing to call, you have to print it somewhere in order to look at it. In the console you can just expand the sections you are interested in. Also different security rules apply in browsers vs "node". |
While I think the idea is good I feel this is very undiscoverable. We could add a new page like |
Even if you add the instructions to a new link (which is a good idea by the way), the easiest instructions are:
Any other instructions are more complicated or have other restrictions. Aka:
We partially have these instructions already on the usage guide. |
Yea agreed. It should work on every page under fakerjs.dev Just for first time discovery it would be better to have a dedicated page explaining this. Because most people would never think to look in the console. |
I'm not sure if this is true. Otherwise, we wouldn't have gotten issue #2426 in the first place. 🤔 |
I tried to run VM1291:1 Refused to load the script 'https://cdn.jsdelivr.net/npm/@faker-js/faker@9.0.1/+esm' because it violates the following Content Security Policy directive: "script-src github.githubassets.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. So it this even possible? |
This script only works on our website, not on Github and other "secure" domains.
Of course you could just print |
Continuation of #2426
I sometimes like to test a few possibilities before suggesting them. However, I don't always have access to my main computer to launch my local playground, so I usually use my browser/our website to copy and use the browser usage to the console to run the scripts.
Since the playground embeds the output into the website, it feels more complicated than just using the browser console.
How about adding a console log to our website that explains how to test faker code from anywhere on the website?
Lazy loading faker like this would avoid issues caused by the large package size.
I'm not sure, where we would have to place this snippet for vitepress to pick it up, but I would like to hear your feedback first.
The text was updated successfully, but these errors were encountered: