Needs:
- [ ] opinions on UI placement
- [ ] opinions on best choice for displaying a write-in based User Brew ( flip to writin box? Add to drop-down list? )
Making some changes to the reset.less so that some default UA button styling is removed.
Then, changing core.less so that the classic "HB" button styling is scoped to a certain class `.colorButton`. This will make it easier to use the button element in other places.
Simplified and unified some font-size declarations, adjusted the "descriptions" for various inputs to be similar structure and appearance, change the components h1 label from "Brew" to "Properties Editor", updated the comment about Publishing.
Now brew metadata is actually updated and preserved across reloads to match updated tag values. useEffect calls the props.onChange event from the parent component on every change to the valueContext state of this component (right now, after hitting Enter in a tag input).
Tags are now either "readTag" or "writeTag", with the former being a div with the tag value and the latter a text input with the value.
Minor class name change in LESS.
Take an array of values from props, load it into valueContext state with an "editing" boolean for each value. Then, when rendering the component, take each value in the valueContext array and create a div for each --
at this point, if the value is "being edited", it returns a div with text "editing". If not being edited, it returns a div with the value as text.
Nothing is being edited at this point since that functionality doesn't exist yet.
No actual functionality implemented yet, just renames the component from "StringArrayEditor" to "TagInput", for brevity at the possible cost of clarity. For now, the original StringArrayEditor is kept and named "TagInput-class.jsx" so that I can reference it as I work on the functional component.
Themes contain both CSS and Snippets. The brewRenderer only cares about the CSS, but other components need the Snippets. Better to have the parent "editPage", etc. load the theme bundles and pass them down to each child that needs it, rather than trying to pass from the child up.
This also fixes the `metadataEditor.jsx` not being able to change themes live; A new theme bundle is now loaded when a new theme is selected, instead of only the first time the BrewRenderer mounts.
Also renamed to "fetchThemeBundle"
Each theme in the theme chain, including user brews, must use the same renderer. When moving to V4 or future versions, it will be important to distinguish which themes are compatible with each other
Ended up being a fairly straightforward change. A few ternaries got smooshed or inverted. Passes builtin and local tests. Need to compare on the test instance.
This adds the User Brew themes, where applicible, to the /new path.
This adds a semi-graceful failure to the metadata panel when a Brew Theme is declared as used but is not present.
More gracefully handles loading with themes not present.
