Feature/sc 27328/options popover component2 #2172
Conversation
…etContentMetaDataBox
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…nto feature/sc-27328/options-popover-component
…into feature/sc-27328/options-popover-component2
…into feature/sc-27328/options-popover-component2
…into feature/sc-27328/options-popover-component2
…into feature/sc-27328/options-popover-component2
…into feature/sc-27328/options-popover-component2
There was a problem hiding this comment.
Overall looks great, and everything worked wonderfully locally!
Most of the comments are very very very minor and nitpicky comments about spacing to improve code readability. It could very well be we have different conventions, in which case feel free to ignore!
One thing that goes beyond that though is just a question about the default lorem ipsum text passed into DropdownMenuItemWithIcon. I'm wondering if we should reverse the logic of that / discuss more together, otherwise it could interfere with some pre-existing implementations.
| @@ -1045,6 +1045,31 @@ div.interfaceLinks-row a { | |||
| position: fixed; | |||
| z-index: 1001; | |||
| } | |||
| .overlayDialogModal { | |||
There was a problem hiding this comment.
Probably worth adding a new line between each class to enhance readability?
| @@ -23,6 +23,9 @@ import {EditTextInfo} from "./BookPage"; | |||
| import ReactMarkdown from 'react-markdown'; | |||
| import TrackG4 from "./sefaria/trackG4"; | |||
| import { ReaderApp } from './ReaderApp'; | |||
| import {ToolsButton} from "./ConnectionsPanel"; | |||
There was a problem hiding this comment.
Maybe worth adding spaces around the imports? i.e. import { ToolsButton } from "./ConnectionsPanel";
| @@ -10,31 +10,39 @@ const DropdownMenuSeparator = () => { | |||
| } | |||
|
|
|||
| const DropdownMenuItem = ({url, children, newTab}) => { | |||
There was a problem hiding this comment.
Does this all work with our merge of rtl with modularization-main? Given the CSS tweaks?
| } | ||
|
|
||
| const DropdownMenuItemWithIcon = ({icon, textEn, textHe}) => { | ||
| const DropdownMenuItemWithIcon = ({icon, textEn, textHe, onClick, descEn='Lorem ipsum dolor sit amet, lorem dolor.', |
| } | ||
|
|
||
| const DropdownMenuItemWithIcon = ({icon, textEn, textHe}) => { | ||
| const DropdownMenuItemWithIcon = ({icon, textEn, textHe, onClick, descEn='Lorem ipsum dolor sit amet, lorem dolor.', | ||
| descHe='לורם איפסום דולור סיט אמט'}) => { |
There was a problem hiding this comment.
Should the descEn and descHe have lorem ipsum defaults set here? Perhaps the default values should be empty, and then if empty (after a quick check) we render lorem-ipsum in your specific use case. In most of my use cases we don't ever have a need for lorem ipsum...
|
|
||
| return await Sefaria.apiRequestWithBody("/api/sheets/", null, newSheet); | ||
| } | ||
| useEffect( () => { |
| newSheet.viaOwner = newSheet.owner; | ||
| newSheet.owner = Sefaria._uid | ||
| } | ||
| delete newSheet.id; |
There was a problem hiding this comment.
Why did you choose to delete this way?
Two other possibilities (but this way might still be the best way):
- Create a new object with only the fields you need, to avoid risks of deleting?
- Iterate through a list of delete fields? See code below as an automated example:
const fieldsToRemove = [
"id", "ownerName", "views", "dateCreated", "dateModified",
"displayedCollection", "collectionName", "collectionImage",
"likes", "promptedToPublish", "_id"
];
fieldsToRemove.forEach(field => delete newSheet[field]);
Curious to learn more about the pros/cons here :)
| }) | ||
| } | ||
| }) | ||
| const getCopySuccessMessage = () => { |
| } | ||
| }) | ||
| const getCopySuccessMessage = () => { | ||
| return <><InterfaceText>Success!</InterfaceText> |
There was a problem hiding this comment.
Is the the best way to do this, versus in CSS? What are our general conventions for this type of thing?
|
|
||
| } | ||
|
|
||
| export {SheetOptions}; |
There was a problem hiding this comment.
Spacing for the export - { SheetOptions }
Description
The 'options popover component' is a menu providing sheet viewers with the ability to save/remove the sheet (saved texts and sheets can be seen at /texts/saved), make a copy of the sheet, export the sheet to google docs, add the sheet to a collection, or share the sheet. Most of this functionality used to exist in AboutSheet.jsx which would show in the Connections Panel. It is now possible to open a dropdown menu and choose one of these options from the main panel of the sheets viewer. Depending on what option was chosen, the user is then shown a modal either showing the status of the action chosen or allowing the user to choose what to do next. For example, if the user copies the sheet, they will see a modal that says "Copying..." and once copied, will show a link to the copied sheet. Exporting to google docs and saving the sheet is similar and show the status of the exported/saved sheet. On the other hand, for adding to a collection, the user is presented with a modal allowing them to choose what collection(s) to add the sheet to, and allowing them to create a new collection. Likewise, for sharing the sheet, the user is presented with a modal allowing them to choose different ways of sharing the sheet (through different social media).
Code Changes
The core of the code for this set of features is in SheetOptions.jsx, which has two stages: (1) First, the user clicks on an ellipse to show a DropdownMenu with all of the options listed above. (2) Second, a modal appears showing the status of the action chosen or a menu, making heavy usage of a few new generic components, such as Modal and GenericSheetModal. The Modal I placed in the /common directory while the GenericSheetModal I implemented in SheetOptions. I had to make a few relatively minor changes to DropdownMenu to be able to pass down callback functions, for example. I also modified the generic sefaria.js apiRequestWithBody so that I could handle the errors directly instead of apiRequestWithBody handling the errors for me. This was necessary to implement Google Export as the API generates a 401 authentication error if the user hasn't setup their gauth credentials with Sefaria.