A couple of questions:

1. When the editor is empty, should the button be disabled?
2. Should hashes be set once /compile returns a response? Talking about window.location.hash and window.deployHash.

Thanks for the questions.

1. I think if the button appears or disappears when you type, it would be too jarring. Let's not do that. But let's check for that case when it is pressed, and if the editor is empty (or even if it just contains whitespace), don't actually offer to share.
2. Yeah, this is a tough choice. I would NOT change the hash in the location. Just build the URL and put it in the Share alert box. I think window.location should always contain the currently running code. Updating the hash to the most recent Share click would add invisible state to the UI, and confuse users.

I think if the button appears or disappears when you type, it would be too jarring.

Visibility doesn't have to be toggled. We can always display the button (isn't that the ultimate goal?), just when the editor is empty we can disable it to prevent dispatching a click event while applying 'inactive' styling.

Sure, that's fine. We haven't really used disabled styles in the UI today, except for in the editor toolbar. But if it looks okay, go for it. That's a minor tweak, and I can always adjust to taste after the major functionality is there.

1. What if the current code has been modified since the program was run? Currently, we show a warning, and offer to re-run the program (which will then cause Share to share the latest code as well). Instead, if users shouldn't think of sharing as connected to running, maybe we should just ask them which they intended to share.

I'm not sure I understand what we are trying to achieve here. Why would we offer two versions to share? Wouldn't it be more straightforward to always share current code?

2. If this might cause more shares of incomplete code, should we stop users from accidentally sharing code that hasn't been run without source access? My sense is probably no... but it's worth considering if this would be confusing. The risk is that students will share something that they think works without testing, and then the person they are sharing with only sees a white box, and the student is frustrated because they never saw the error message.

To avoid this kind of confusion, we can display a warning saying that the code contains errors and disable the option to share the project without code.

My only thought was that in the first case, a student might have a working program, choose to share it, and end up sharing modified code that doesn't actually work. I think they should at least be reminded that the code they are sharing is different from what's running. (We already know that, and use it to show a warning at the top of the running program.)

I agree with the second point. It does mean that you need to wait on at least a /errorCheck endpoint before displaying the Share dialog. That is unfortunate, but those are usually pretty quick.

I went ahead and added a simple warning about detected errors (without actually showing those) to the message while keeping all sharing options available. Let me know if you'd like to handle the situation differently.