Yep good point this was an easy win adding to the session history service and storing the latest project state on an editor dirty event that can be retrieved with #snippetId#local and will immediately jump back into the last state in the editor for that snippet.
I took some more passes at the session history dialog realizing it had another use case - a lot of times I will spread out an idea over multiple Playground snippets or have recently visited PG I thought was neat but then completely forget the snippet hash and it gets buried in my history. The dialog has context awareness and will remember all the PG’s that had been run and store the most recent run states to load in on demand.
I see some Playwright failures and should make short work of getting those cleaned up, all look like selector paths that need to be changed.
For fun here’s one of the latest I’ve been working in to prove pulling in the React npm package and writing custom React as an overlay, might pique your interest @brianzinn
Dude! This PR is magic. You can really be proud. I GENUINELY appreciate your willingness to stick with our standards. Your code is great. We should merge it asap (As soon as the build errors are fixed)
Wow - that is highly cool how you did that! It looks easy to work with - the Monaco editor supports JSX highlighting, too. Highlighting gets a bit interesting when you support light/dark themes. Really like all of the changes you have made.
Hey thanks for trying this out, good candidate with the ocean demo that is a beast… Good news and bad news, that bug was just stack exhaustion from a spread operation which is different across engines so I put in a safe chunking method and that part should be fixed.
Bad news is this Was wondering if/what sort of limits there are for storage in the backend - the string payload is clocking in a little over 200kb. With the extra wrapping with JSON stringify this must’ve bumped it over the edge but it might be pretty close as is now.
I checked with the built in compression in the window (pako through JSZip) it can get the size down to about 33kb so that gets us a win but I don’t know the implications of storing compressed vs clear data for metrics/static searches. That could be swapped out with a fallback pretty quick with a magic byte check for compressed.
I will stick with this PG for a bit and use it as the guinea pig for a big project and how to optimize. I also have some basic code highlighting in for WGSL and GLSL shaders but it’s not super sophisticated.
I don’t think it’s a size problem, we have some PG which are pretty big because a base64 picture is encoded inside it.
For eg:
This one has a .hdr file of over 2Mb encoded, and the whole PG is around 2.7Mb.
I think we reenabled CORS on our server, so maybe the error you see is because saving doesn’t work anymore from your own server? If that is so, you should use the link from the PR (Babylon.js Playground) to access the Playground with your changes.
[…] Wait, this link can’t save either, let’s see how to fix it… Using the PR link now works.
Aha I was surprised when I deployed that the CDN was working without proxying in the backend, so that is intended to be CORS restricted, good to know I think I will still have to add COOP/COEP headers to my deployed app to get this to save correctly moving forward. Can save locally now and still load in the deployed URL but not re-save yet.
Here is the ocean PG with the shaders extracted to .wgsl files which are also supported as text exports in the editor
Was wondering if/what sort of limits there are for storage in the backend - the string payload is clocking in a little over 200kb. With the extra wrapping with JSON stringify this must’ve bumped it over the edge but it might be pretty close as is now.
I think I will still have to add COOP/COEP headers to my deployed app to get this to save correctly moving forward. Can save locally now and still load in the deployed URL but not re-save yet.