Definitely a little cleaner -- maybe some css changes we could make to the widget could help as well?
@G-Ambatte I merged naturalcrit/homebrewery#1777 but found an error shortly after. I reverted the changes, but we can't reopen PRs so we will need to open a new one and keep tinkering on it.
I reverted your PR.... there should be a difference.
My revert then applied another commit on top, but your old commits are still in the history.
Sorry this is all my bad.
Sounds good.
The issue with the thumbnail was that it's pretty easy to hit the size limit for Google Drive properties (124 characters including the property name). I also foresee a similar issue when we start adding custom tags and things. We probably need to get around this by adding a new field into the document itself, similar to our
The issue with the thumbnail was that it's pretty easy to hit the size limit for Google Drive properties (124 characters including the property name). I also foresee a similar issue when we start adding custom tags and things. We probably need to get around this by adding a new field into the document itself, similar to our
css block for the style tab, but for metadata. Probably needs a whole separate PR just to set that up.
Or just mark it to be added after the metadata codefence
The meta tags will wait - anyone who wants it desperately has already been waiting for years.
Lets mark it to be added after the metadata codefence. If we implement it as a Google Drive property now, it will only make the transition to the codefence stickier because then we have to handle the case of Google brews that were saved to store the date in a property and then never updated to use the new method. We would have to handle both cases which is something we can avoid otherwise.
Okay so I've narrowed down the thing causing the folded code blocks to unfold on any change, but I'm now getting into react lifecycle stuff and admittedly I'm very proficient with angular but react's lifecycle stuff is entirely unknown to me. Something about how the component is updating between
editPage.handleTextChange setting the state (which updates the CodeEditor's props) and codeEditor.componentDidUpdateis causing the CodeMirror instance to seemingly lose all its state wrt code marks
I'm not sure how it would work, exactly, but that might eliminate the need to save
/new to local storage, or to save the brew before printing to make sure that the last set of changes are still in there.
Random thought, might be worth chasing at some as-yet-undefined future point.
@G-Ambatte Posted some rambling comments on naturalcrit/homebrewery#1801 . It just addresses one issue, but I think it will clean the PR up a lot, and then I'll give it a more detailed look-over in a couple days. (Outside-the-house date night with my wife after 2 years of pandemic!)
Our lockdown has been over for a while, but restaurants have still been closed, people aren't getting vaccinated which has made us hesitant to go out much, and getting a babysitter, etc. when everyone else has their own problems to deal with... It just has just not worked out.
Thanks though. We're excited!
On the InitialState stuff: if we create a perfect blank/default brew in
homebrew.jsx (or wherever), then _.merge that with the result of getBrewById() (probably this.props.brew in homebrew.jsx), then every Brew, passed to any Route, should be guaranteed to have all of the default Brew properties.
I think.
Probably a decent sized PR to put it into practice... I think it would modify more or less every single Page.
Could probably do some funky work around, to generate page backgrounds on the fly... Lot of work though, for something that Chrome will hopefully fix Soon(TM).