I’ve used (and wrote) https://mockaton.com for this. It has a browser extension, which downloads all API responses in your flow.
then you can run mockaton with those mocks. you’ll manually have to anonymize sensitive parts though.
also, you can compile your Frontend(s) and copy their assets, so yo can deploy a standalone demo server.
see the last section of: https://mockaton.com/motivation
mocks don’t have to be fully static, it supports function mocks, which are http handlers.
for demoing, the dashboard has a feature for bulk selecting mocks by a comment tag.
Thanks for the Mockaton suggestion! I like the API mocking approach - that handles the backend data cleanly.
The challenge I kept running into was the frontend side during live screen shares. Even with mocked APIs, I'd have credentials visible in browser tabs, notifications popping up with client names, or sidebar elements showing sensitive info.
Did you find Mockaton solved the full screen-share exposure problem, or did you combine it with other approaches?
2b. If it doesn't set a cookie (some SSO providers set it in `sessionStorage`), and assuming it’s a React app with an <AuthProvider>, you might need to refactor the entry component (<App/>) so you can bypass it. e.g.:
SKIP_AUTH // env var
? <MyApp/>
: <AuthProvider><MyApp/></AuthProvider>
Then, instead of using the 3rd party hook directly (e.g., useAuth). Create a custom hook, that fallbacks to a mocked obj when there's no AuthContext. Something like:
Rendering the whole DOM tree (instead of VDOMs) is a fast process. The slow part is attaching (committing) elements to the doc. For example, I have a test of 20,000 elements which takes <30ms to render, while attaching them takes 120ms.
Since the performance is mainly bound to the commit phase, with a DOM merging library, or hopefully, if we get a native API such as `document.replaceChildren(...App(), { merge: true })`, this approach could be better.
Caveats:
Although it restores focus, that's not the only thing we need to preserve, we also need to preserve scroll position and cursor position.
So to work around that, I still have to step out fully declarative, by just replacing the part that changed. For example, here I had to do manually mutate the DOM:
I don't think the issue is lack of features, because audio context and canvas2d are pretty good for making things shiny and nice. The issue is pretty much the rest of the DOM that has quirks everywhere if you want to use it that way. CSS3D as a scene graph is also kind of half baked, and not really integrated well with animations, and well, also too painful when it comes to scheduling and timing and chaining any transition.
SVG animations are also only half-ass implemented among browsers, so that's not really a reliable alternative.
What I liked about the Macromedia suite was the integration cross-IDE, where dreamweaver worked really great together with Flash and vice versa, and where flash was able to load HTML content, just in a more animated manner.
I mean, this was when XHR and AJAX was the "modern" thing in web browsers. Adobe could have dominated the mobile market if they would have decided to make it an open standard. Flash was really a decade ahead of its time.
https://github.com/ericfortis/mockaton/commit/acf21803480412...
…and it deduplicated autocomplete suggestions in WebStorm
reply