Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate chat #85

Open
Noam-Bendelac opened this issue May 17, 2021 · 0 comments
Open

Separate chat #85

Noam-Bendelac opened this issue May 17, 2021 · 0 comments
Assignees
Labels
enhancement New feature or request frontend Frontend functionality implementation Possible implementation idea to keep in mind
Milestone

Comments

@Noam-Bendelac
Copy link
Collaborator

Noam-Bendelac commented May 17, 2021

Work on the separate-chat branch. (However I need to merge in some changes and push it first.)

TODO (we can talk about what order to do these in):

  • Implement SeparateMessageEditor.
    • It will look similar to SituatedMessageEditor in terms of taking an onSubmit and onCancel.
    • Remove the createSubmitHandler call; the URL, HTTP method, and JSON body used there will eventually be moved to the onSubmit in SeparateChat.
    • I don't think it will need a SongActionConfirm like SituatedMessageEditor has.
  • Create a SeparateChatMessage component similar to SituatedChatMessage. This can probably go in the same file.
    • Check dbTypes.ts for the SeparateChatEvent type.
    • Need to decide how to render the two variants of SeparateChatEvent; two different components? Or just render each optional property conditionally?
    • There might be a name clash on SeparateChatMessage if you need to import the type; talk to me if this happens, but you might not need to import the type at all.
  • Implement SeparateChat.
    • It will have similar UI (JSX output) to SituatedChat, but it will create onSubmit and onCancel callbacks for SeparateMessageEditor similar to SavedSongRow or DraftAdditionSongRow.
    • The chat property ("prop") is currently any[] type and needs to be changed to the type of the PlaylistDocument's chat. Check dbTypes.ts.
    • Look at the old createSubmitHandler call in SeparateMessageEditor for some guidance on what API request to make.
    • Remove the reloadPlaylist prop and instead get the loadPlaylist function from useContext like in SavedSongRow.
  • Figure out some CSS styles for SeparateChat and SeparateMessageEditor's button.
    • The CSS in this project is written as Javascript objects in the .tsx files (this may not have been the best decision in hindsight, see Migrate to CSS modules #53, but it is what it is).
    • Need to decide on how the SeparateChat will look, like the padding, background color, and most importantly vertical positioning of elements:
      • The SeparateMessageEditor will likely be at the very bottom.
      • When the chat is half empty, do messages float to the top or bottom?
  • Eventually, if needed, add some code to make the scroll position automatically scroll to show the newest chat message (similar to DraftAdditionSongRow)

The API is minimally documented/typed in apiTypes.ts, however I don't think you will need to worry about that for the API request you make to post a message. The existing code in SituatedMessageEditor and SavedSongRow/DraftAdditionSongRow are enough for that. The types in dbTypes.ts like SeparateChatEvent and its variants will be useful.

@Noam-Bendelac Noam-Bendelac added enhancement New feature or request implementation Possible implementation idea to keep in mind frontend Frontend functionality labels May 17, 2021
@Noam-Bendelac Noam-Bendelac added this to the Milestone 2 milestone May 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request frontend Frontend functionality implementation Possible implementation idea to keep in mind
Projects
None yet
Development

No branches or pull requests

2 participants