Use --vscode theme variables in default template

[lostintangent]

My only concern with this is that it's a very noticeable change, after CodeSwing has been out for a while. Additionally, if you open a CodePen that was exported to a gist, that was almost definitely authored with the assumption that the default background is white. So this change could also impact interop with other services.

[Sheraff]

@lostintangent I was actually looking to add a boolean option for this in the settings but I've never authored a vscode extension and i haven't found out how to do that yet.

[lostintangent]

That sounds good! We could add a new setting, that would leave the current behavior as-is, but let users opt-into the new theming.

Here's an example of how to add a new Boolean setting. Maybe we could call it something like codeswing.themePreview? And have it default to false?

Here's the code that reads the config settings, so you'd just need to add a new overload for themePreview, and then update your PR the check if that setting is true, and conditionally apply the background/foreground color.

[Sheraff]

@lostintangent I guess I was tired yesterday when I looked at it because it took me 5 minutes this morning to add it! Thanks for the pointers BTW.

[Sheraff]

I made a more exhaustive stylesheet that would go a little beyond just background and color

• GistPad link: vscode://vsls-contrib.gistfs/open?gist=775dcd0a046596279c0ed1befd362d1f
• GitHub link

While it's more extensive than my initial proposal, it still just overrides browser defaults with theme variables so it feels reasonable to me, but I didn't want to include it in my PR without checking whether you think it's okay to go this far.

And here's a preview:

[lostintangent]

@Sheraff That sounds great to me! Now that it's an opt-in behavior, I think we can be much more opinionated with the styling 👍🏼

Another thought is that it might be worth adding this "themePreview" setting to the codeswing.json file schema as well. That way, if a swing was authored in a way that depended on these styles, then the user could indicate that in the swing itself, so that when another user opened it, they've get the right styling, regardless what their VS Code setting was.

[Sheraff]

@lostintangent alright, everything should be in order as far as I can tell.

• code changes were kepts to a minimum
• the new styles were put inside a separate file
• README was updated (although, I didn't create a whole section about this setting like there are for the other ones)

Tell me if I'm missing anything!

[Sheraff]

@lostintangent all done ;-)

[lostintangent]

Awesome! Thanks so much for this contribution. Merging right now, and I'll try to release an update this afternoon :D

[Sheraff]

@lostintangent What does the release timeline look like from here? As in: what are the steps / delays before I can see this in VSCode for real?

[lostintangent]

I'm going to test out your changes right now and if everything goes well, then I'll ship an update in the next hour. That will also include support for importing JSX and TSX files.

[lostintangent]

This change how now been shipped! Thanks 🚀

[Sheraff]

Thank you for your help with this!