Too much traffic, not enough value. Leaving stuff having to do with tips library/tutorial card navigation as well as hardware extension connectivity, as those help us find issues with Scratch.

Selenium loads the playground using the file:// protocol, where history.replaceState throws an error

This only shows when you are on a project that is SHOWING_WITHOUT_ID and has changes. This is only the case when logged out, or in the desktop editor.

responding to canSave without needing canSaveNew prop
removed canSaveNew
added default for onUpdateProjectId
removed conflict files erroneously added
don't pass down onError
got tests passing
better creating and saving logic and names

don't set redux project title directly from sb uploader; only extract title from .sb2 and .sb3 filenames

stripped title handling from sb file uploader
updated more projectState related names
simplified hash-parser-hoc logic slightly

load new project, both json and title; set title on file load; draft of code to fetch title from api

styling for title field; correct input target in tests; make download filename safer with default, max length; in playground index, correctly pass props through to gui container

Also include the hash of the project in load errors from the server so we can debug them

* Export initial states for each reducer
* combine all gui reducers (excludes scratchPaint and intl)
* combine all initial states to create default guiState for preloading in www
* expect all of the gui state to be accessible at `state.scratchGui`

It's a cleaner API IMO but ended up being a messy implementation...

These use a technique where the save/load functionality is passed from the component to its children via a function argument.  I opted for this rather than a higher order component because it is more readable and requires fewer intermediary components.

This could just as easily been done with a higher order component and would be happy to change it to that instead.

There is a performance implication since there is a function being defined in render. However the menu bar is not a highly re-rendered component, so I thought it would be ok in this case.