-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Use WebContainer API #351
Comments
I think there are probably other things we need to discuss.
|
FYI. I'm not sure, but a similar solution is out from CodeSandbox: |
Excellent! Thanks again for rustling up a PoC demo, @ota-meshi.
👍
Vite SGTM. Both SandPack and WebContainers have first-class support for it.
It'd be good to go as vanilla as possible so that we align with our reorientation to web languages in
It'd be great to have parity with the existing demo site:
This would be nice to have as people sometimes create issues using YAML for their configs.
This is very interesting as people could include plugins and custom syntaxes in their examples.
We can keep the input on the left and output on the right. body {
grid:
"input"
"output"
"problems"
"config"
}
@media (width > 40em) {
body {
grid:
"input output"
"config problems"
/ 1fr 1fr
}
} So, autofix output goes top right.
Which looks more appropriate for our needs? Sandpack supports Safari, but that's not necessarily a deciding factor. |
Using vanilla is no issue for me.
I think I made a mistake in the way the question was asked. What do you think about us using something like tabs as well? I'm not a designer, so I don't know which one is better. |
The announcement of Sandpack 2.0 mentions "Difference with WebContainers". While Sandpack supports browsers more widely, WebContainer uses modern browser technologies. I believe Safari would support such technologies in the near future, so adopting WebContainer seems better to me. |
I took a glance at the PoC code. Because I feel it's a small app and code touching DOM isn't so many, vanilla seems more maintainable to most people. Updating dependencies would be an additional task if we used some framework. About the UI design, I'm not particular. I'd like to let your decision. Let me ask a question. We're using |
As far as I understand, However, we need to set some headers. |
The ESLint TypeScript playground is nice. I hadn't seen it before. As you said, if we use tabs we'll be able to able to display the chosen input at a larger size. However, the other input will be hidden behind a tab. If we use the current design (but with an extra output panel in the top right), we'll continue to see both inputs at a glance but they will be smaller. Both approaches have their advantages and disadvantages. As we:
We should probably keep the existing design so that we can see everything at a glance. If |
If we don’t need to use |
Lit could be a good fit for UI. It's close to the platform as a light touch abstraction over Web Components. It encourages using:
So that we can use Stylelint on all the CSS of the UI. |
Not two inputs. |
Oh, I see. Let's go with tabs then. Shall we use defaults that mimic our getting started docs and demonstrate some of the examples on the home page? For example: Input: a {
grid-template-areas:
"a a"
"b b b";
colr: hsla(20deg, 10% 30%, 5%);
}
a {
--Foo: 1rem;
} Config: {
"extends": ["stylelint-config-standard"]
} Dependencies: {
"devDependencies": {
"stylelint": "~15.3.0",
"stylelint-config-standard": "^31.0.1"
}
} That should produce problems for 5 of the examples on the home page. |
Having delved into the PoC demo some more, it feels like the vanilla approach used there works well as the monaco-editor does a lot of the UI heavy lifting. |
I opened a PR. #352 |
In componentizing, it might be a good idea for us to use lit, however I have never published anything using lit, so it might take time for me to implement it. |
@ota-meshi Thanks for the questions. As you comment, we need to consider some points, especially deployments. It might be the most simple without using However, this will heavily depend on the Docusaurus build system, so adopting a new build tool or framework may take time and effort. On the other hand, if we continue using There may be other better ways. Please let us know if you have more information. |
Yeah. I think using an iframe is reasonable at the moment. However, GitHub Pages doesn't let we specify the header, so we'll need to hack it using something like coi-serviceworker. In my opinion, if we are using Netlify's Open Source Plan, it would be nice if we could publish a demo page on netlify. |
Continuing to use an I've created a new deployment under the Stylelint org on Netlify: If we add a |
I added the
|
I pushed a commit to do it. Deploy preview at: It's looking fantastic, btw! Thank you so much for all the work you've put into it already! I'll hopefully have time this weekend to delve into your pull request. I hope to bring the design in line with the website. |
Thank you! I didn't know that |
@ybiquitous @kristerkari |
What is the problem you're trying to solve?
Get the demo working without Heroku.
What solution would you like to see?
I think we can use the WebContainer API that allows us to run Node.js on the browser.
https://blog.stackblitz.com/posts/webcontainer-api-is-here/
I did a simple PoC. At least you can check that stylelint can work without a server.
https://github.com/ota-meshi/stylelint-demo-poc
The text was updated successfully, but these errors were encountered: