This simply moves the codeEditor folder to the components directory. `codeEditor.jsx` simply builds a component which is then used elsewhere, and isn't shared between client and server, so it should be in the client directory.
Arguably it could go in `client/homebrew/editor` but I think the `/homebrew/` folder should be eliminated down the line and it's contents just re-sorted.
When working on the editor right now it's a pain to switch between `shared` and `client` hunting for the right file.
Move the SVGs out of the `shared` directory, closer to where they are actually used. They are svg jsx files, setup as components, so i've moved them to the components directory.
Deleted `combat.svg.jsx` because we don't use it anywhere.
renamed the remaining two to be more descriptive of the image for additional clarity.
Moving this component to the component folder so it's closer to where it is actually used. Not moving to the `homebrew` folder because ultimately i think pretty much everything in that folder should move to the components as well (`homebrew` isn't a helpful folder distinction).
Deletes a directory, moves 2 files.
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.
When the page is zoomed in very close, such that <30% of the page is in view, it doesn't register changes to the 'current page'. This fixes that, passing in the 'centerPage' if 'visiblePages' is empty.
I don't love this fix, i think the visiblePages should always have *something* in it, but I can't quite figure out how to set that (since the normal update to visiblePages is happening in an observer that doesn't fire if nothing is in view).
the `safe` keyword for `justify-content`, in combo with `center`, means that the content will be centered in the viewport unless there is not enough space for it. If there is not enough space, it aligns it to the *start*/left edge, rather than keeping it centered and clipping the left edge of the page.
The memoization of the renderPages() method prevents a re-render when something like pageShadows is updated, so displayOptions are added to the dependency array in the memo method.
Prior to fix, the "next page" button in the toolbar wouldn't work well if there were multiple pages in view that were in a single 'row'. This is because the logic is to take the pages that are "visible", take the max of those pages, and then scroll to that page. But the issue is that if the 'max' page is in the same row as other pages, the range of visible pages doesn't change....the max will always be the same.
So the change here basically runs the scroll function twice-- if the first run results in the same 'max' page as before the scroll, it runs it again but with the target page being "max + 1", which will bump the target to the next row.
Reduce the visual prominence of the page input by using a darker background and a text color that matches the rest of the toolbar icons. Darker background still indicates this is an interactive item (is an input), hopefully.
Bad commit here with too much stuff. I apologize.
This sets up two Intersection Observers: the first captures every page that is at least 30% visible inside the `.pages` container, and the second captures every page that has at least one pixel on the horizontal center line of `.pages`. Both can be arrays of integers (page index).
The "visiblePages" array is duplicated and formatted into a "formattedPages" state, which gets displayed in the toolbar.
The toolbar displays that, unless the user clicks into the page input and enters their own integer (only a single integer, no range), which can then jump the preview to that page on Enter or blur().
The Arrow 'change page' buttons jump the preview back and forth by a 'full set'.
If one page is viewed at a time, this is moved on page a time, and if 10 pages are viewed at a time it jumps the pages by 10.
Left to do: adapt the "jump editor to match preview" divider button to work with new "centerPage".
This commit only renames things, changes no logic. Any mention of "book", "view", or "mode" is renamed in relation to "spreads".
The AnchoredBox.jsx file is renamed to Anchored.jsx
Extra icons are deleted, and the remaining ones are renamed.
Big change to how the AnchoredBox component is structured so that it can be used in more than just one spot. Now composed of the wrapper Anchored, with two children AnchoredTrigger and AnchoredBox, each of which can have their own arbitrary children.
Next steps will involve renaming the component file to Anchored.jsx, moving most styling out of the attached stylesheet (and into brewRenderer.less), and adding props to pass in Anchor Positioning properties.
If there were two inputs sending styles to the same target (ie row and column gap), they would override each other.
This change fixes that by deepening the merges. Admittedly, I turned to cGPT to help me with this as the nesting was throwing me for a loop. It works, though, and I understand it now that I can read it.
defaultValue matches the normal styled values of the gap property on the .pages element.
removed the "tooltip" that showed the current value from the range sliders inside the anchoredbox (the gap sliders).
Refactoring the AnchoredBox component because I wanted to set focus on the trigger button when the expanded box was closed. Wrapping the trigger into it's own component, with forwardRef, allows for passing the `ref` to the actual DOM node. Then the `.focus()` method will work on it.
Rather than a single button with three states, it is three buttons. Went with buttons with `role='radio'` rather than true radios mostly because that is what Radix does.
the `-alt` icons have better sizing/readability than the originals. The originals likely will be removed.
Also adds back in 'fit-width' icon which was mistakenly overwritten earlier.
Adds a new AnchoredBox component that is functionally a clone of the "saving error" notifications, but drops a lot of the JS in favor of the new (chrome-only!) CSS Anchor Positioning API. In subsequent commits, either alternate styling or a polyfill will be added non-supported browsers.
The box contains a few inputs that modify the CSS applied to `.pages`, most critically a "start on right" toggle for the Facing Pages mode.
The range slider should only display a tooltip for the value if the value attribute exists. For example, the difference between controlled and uncontrolled inputs.
Update toolBar.less
Adding class name so that it can be toggled between 'recto' and 'verso'. Verso being the normal left/right configuration, no styling is needed. With recto, the first page is shifted to the second slot, or right side.
Adding the margin resets back in because otherwise each .page margin is set to "auto" on the sides, and that makes them zoom awkwardly when in facing and flow modes.
Fixes an issue where tags with duplicate values would all update to the same value after editing just one.
Also an adjustment to the parameters that are passed to handleInputKeyDown-- they are now one object. This helps handle an "options" object where more optional features can be turned on and off.
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.
New button that triggers `submitTag()` method directly (rather than throw onKeyDown event) and passes `null` as the newValue. New `if` condition checks for null on newValue and if true, removes the tag that matches the originalValue.
This *does* currently delete all duplicate tags if they match the one you are deleting. Not sure when you'd ever want duplicate tags, but regardless i'll likely switch this to work via Index, not value.
Component now accepts new tags entered in the always-present input field. Entering a value and hitting Enter submits the tag, and it appears as a new tag.
Updated the tag list keys to be unique (via `index`).
To-Do: empty 'new tag' input after submitting.
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).
Currently uses uncontrolled inputs with a `defaultValue` attribute set to the values passed in via props. The input can then be edited, and when `Enter` is pressed, it updates the stored value state. Later, this can be updated to be trigger with `Tab` or clicking outside the active input element.
Clicking on a readTag now converts that tag to a text input, and maintains the tag value. It also closes any other open text inputs amongst the tags (but leaves the "new tag" input open).
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.
Toggles a state variable to either visible or hidden which is used to set a related class on the toolbar. The hiding is done with CSS, just reducing the width of the toolbar and the opacity of the tools.
Gazook89