Reintroducing handlePageChange() method to handle the page input separately from the scroll function. It tests the regex pattern on the string, parses to integer, and sets pageNum state.
scrollToPage also now sets the pageNum state after performing the scroll so the input box matches the new current page.
This was previously in the .pageInfo widget, probably not for any good reason, but I'm moving it to the popups div for probably not a good reason.
It's used to get the parent .pane div, and pull its `height` value which is then passed to the `.brewRenderer` div to set the height.
I tried alternate methods that would make this obsolete (CSS methods mostly), but due to some complexity am just ditching those alternatives and popping this sucker into `.popups` for now.
stylelint has a problem with the `:horizontal` pseudo selector in brewRenderer.jsx, which is being used to apply some styling to the custom scrollbars. As far as i can tell, the selector is not standards-track, so that is probably why. Not sure if we want to adjsut our stylelint config to allow it?
Moved the single-line handler to operate directly in the onChange handler of the input that is calling it.
Considered doing the same with handleZoomChange, but that handler is used by two buttons rather than just one.
handleScroll is replaced by getCurrentPage(), which effectively does the same thing. The math is slightly different, though very similar, and result seems to be the same.
Treat each input and button as a direct child of the `.group` class, removing the intermediate div and reassign the `tool` classname to those inputs and buttons. One item, the current / total page "set", is wrapped in a .tool div because they should be considered one item (even within the .group container).
And then a bunch of CSS adjustments to match the new structure.
Make it so that if a user enters a page number higher than the total page count, it jumps them to last page. if lower than 1, it jumps them to first page.
Displaying the total page count near the current page number means we can lose the bottom right toolbar entirely (the renderer could be added to top toolbar, or just left for the metadata info in title bar).
putting the `pageInput - 1` modifier in the `scrollToPage` method allows for more understandable button function ('back button' is `- 1` and 'forward button' is `+ 1`).
Changing input type to text removes the "spinner" controls from within the text box. The spinner buttons are an accessibility issue (the tiny buttons are tiny), and we already have better buttons for incrementing/decrementing page number.
Text box only accepts numbers.
Moved onChange handler function to a component method and simplified it a smidge.
Must use parseInt now because the input type will change to 'text' rather than 'number'
totalPages shouldn't need to be in state, since this component won't be changing it.
renamed pageNumberInput to just pageInput. Was just something that happened in the course of working on it.
currentPage doesn't need to have it's own state separate from pageInput, they should always be the same *value*.
Set as relative position, the toolbar (and mysteriously, the pageInfo box) would jump up 29px (toolbar height) when the "next page" button was clicked. absolute pos fixes this.
The website UI should stay out of the iframe if possible. Otherwise, users can style the UI on their brew which may or may not be a pain, and it's simple enough to avoid it.
Moved the zoomLevel state assignment to a newer useState hook function, making it easier (and shorter) to update that state within event handlers.
The slider onChange is a single easy line, and the buttons handlers are two lines for clarity.
Remove the 'in'/'out' parameter of the function and just have the buttons send postive or negative integers equal to the desired change in the zoom. No need for if/else statements using strings.
