Skip to content
This repository was archived by the owner on Oct 11, 2022. It is now read-only.

Move thread editor to plaintext #4564

Merged
merged 66 commits into from
Feb 12, 2019
Merged

Move thread editor to plaintext #4564

merged 66 commits into from
Feb 12, 2019

Conversation

mxstbr
Copy link
Contributor

@mxstbr mxstbr commented Jan 23, 2019

Status

  • WIP
  • Ready for review
  • Needs testing

Deploy after merge (delete what needn't be deployed)

  • api
  • hyperion (frontend)

After reassessing the importance of this change due to customer feedback I decided to investigate this after all. From the first exploration it seems doable, with some caveats.

Todo

  • Move to client-side image uploads
  • Automatic embeds
  • Make sure editing works
    • Make sure users can remove automatic embeds
  • Add preview tab to see generated markdown/thread
    • Fix linkifycation in preview
  • Fix syntax highlighting in code blocks
  • Add mention suggestions based on Add mention suggestions to chat input #4550
  • Styling
    • Add markdown hints from chat input
    • Add overlay when dragging image
    • Fix code block styling
    • Add visible "Upload image" button like the chat input
    • Add note that drag and drop uploading is supported?
    • Add note about automatic embeds?
    • Make sure composer looks right in all instances:
      • Inbox
      • /new/thread
  • Merge src/components/composer with src/components/threadComposer/composer (done by @ThomasRoest in WIP: combine / refactor threadcomposer #4575)
  • Make sure the merged composers look right
    • Community view
    • Channel view

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 23, 2019

The hardest bits to figure out here are going to be images and embeds.

I think images we have to do GitHub-style "upload from client then input markdown link". /cc @brianlovin how would we best accomplish that? New uploadImage mutation?

I have no idea how to do the embeds, I think the choice is either to remove that functionality (while keeping existing embeds around, of course) or automatically "unfurling" a list of supported links into embeds (youtube, simplecast, soundcloud, etc) on the backend. Any thoughts?

@spectrum-bot
Copy link

spectrum-bot bot commented Jan 23, 2019

Warnings
⚠️

These modified files do not have Flow enabled:

  • src/components/composer/style.js
  • src/components/globals/index.js
  • src/components/threadComposer/index.js
  • src/components/threadComposer/style.js

Generated by 🚫 dangerJS

@ThomasRoest
Copy link
Contributor

What are the problems with the current editor?

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 24, 2019

It is very buggy, lots of users constantly complain about it (see my recent blog post). We want to replace the WYSIWYG part with a plaintext markdown editor, which is then converted on the backend! (this should be mostly irrelevant for your work in #4575 I think?)

@brianlovin
Copy link
Contributor

I think images we have to do GitHub-style "upload from client then input markdown link". /cc @brianlovin how would we best accomplish that? New uploadImage mutation?

Yeah, it might be worth poking around to see if other libs exist for this yet, otherwise we could try and figure out how GitHub handles this by just inserting placeholder markdown while waiting for the upload to return a url. The downside here would be that you create an upload every time, regardless of if the resulting url actually gets posted. But storage is cheap, so not a problem really right now.

I have no idea how to do the embeds, I think the choice is either to remove that functionality (while keeping existing embeds around, of course) or automatically "unfurling" a list of supported links into embeds (youtube, simplecast, soundcloud, etc) on the backend. Any thoughts?

I'm fine with removing functionality and getting really smart with link unfurling for popular services. I'd add Figma embeds and code sandbox urls to your list. I don't know how that would look in the backend (just inserting an iframe into the draftjs body?) but this feels like the best user experience to me personally.

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 24, 2019

The latest commit starts working on the client-side image uploads by adding an uploadImage mutation—doesn't quite work yet, but it'll get there I think.

The embed stuff sounds good to me too, inserting an embed into the DraftJS content seems simple enough to be feasible. I'll try making that happen after making sure the image uploads will work.

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 25, 2019

I have been battling around for hours with this image uploads stuff now, and can't seem to get it to work. When dropping an image on the new composer, (await file).stream always results in an undefined error on the server. Have you ever seen that @brianlovin, any hunches why that could be happening?

@brianlovin
Copy link
Contributor

@mxstbr could you push up your latest work? Not sure what could be going on there. Do you have FILE_STORAGE=s3 set in your env? e.g. yarn run dev:api:s3 to ensure that uploads are hitting s3 and not your local directory?

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 27, 2019

That is not the issue, the image argument to the uploadImage mutation is just null even though it is provided from the frontend 😕 Latest commits are up!

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 30, 2019

Oh my god are you kidding me, did that fix it @brianlovin? 🤦‍♂️🤦‍♂️🤦‍♂️ I am such a dummy, sorry about all the struggles here. Cannot believe I spent three days messing around with this.

@mxstbr
Copy link
Contributor Author

mxstbr commented Jan 30, 2019

😍😍😍😍😍😍

editor-image-uploads

Max Stoiber added 6 commits January 30, 2019 10:04
A quite well unit tested util that parses supported URLs from text and
returns their embed URLs.

Currently supported services are Figma, Framer, Youtube, Vimeo, Codepen
and Codesandbox, as well as support for generic <iframe>s
@mxstbr
Copy link
Contributor Author

mxstbr commented Feb 8, 2019

Todos

  • Fix overflow on /new/thread on desktop
  • Fix styling issues on /new/thread on mobile
  • Fix flow
  • Fix tests

@ThomasRoest
Copy link
Contributor

ThomasRoest commented Feb 8, 2019

this looks great!

composer

@brianlovin
Copy link
Contributor

@mxstbr @ThomasRoest this PR seriously makes me so happy. What a huge, massive, seriously big quality of life improvement to composition on Spectrum. I'm running this locally and just so stoked to ship this. Going to do a bunch of testing and make sure we can't suss out some lingering bugs.

@brianlovin
Copy link
Contributor

brianlovin commented Feb 8, 2019

@mxstbr found some bugs + notes:

  • links don't actually work. type [link](https://google.com) and it renders as a link, but the element isn't receiving the href attribute
  • how would you feel about also moving the edit experience to this modal? might reduce a ton of complexity from the edit screen/thread view; i'm a bit worried that the edit view has the old draftjs rich preview editor, which might introduce bugs cc @ThomasRoest
  • in the preview sometimes images have this draftjs focused state:

screenshot 2019-02-08 14 04 20

  • if you publish a thread with an image in this focused state, the final rendered thread will keep the focused styling

@mxstbr
Copy link
Contributor Author

mxstbr commented Feb 9, 2019

how would you guys feel about also moving the edit experience to this modal?

The "convert draftjs to markdown for editing" thing that we do for messages won't work for the complex styling of threads. For example, what do we do with automatic embeds?

If we do move editing to plain text we would need to store the raw markdown body on the server and send that down the wire.

I think that is more work than necessary for this v1, I would rather ship this and then tackle plaintext thread editing in a followup?


Noted on your other points, good catches! Will investigate on Monday

@ThomasRoest
Copy link
Contributor

see components/rich-text-editor/Image.js for styling the image overlay / focus state in ImageContainer and ActiveOverlay

@mxstbr
Copy link
Contributor Author

mxstbr commented Feb 9, 2019

Yeah I think we can just entirely get rid of those focus states since they were only relevant during WYSIWYG editing. Want to submit a PR against this branch @ThomasRoest?

remove active overlay / focus state from image in composer
@mxstbr
Copy link
Contributor Author

mxstbr commented Feb 11, 2019

After thinking about this more, really the only thing the plaintext input does not account for is the automatic embeds. If we are fine with users not being able to remove them, we can move the editing experience to plaintext too.

That being said, it would require a lot more work to make plaintext editing work on both the back- and the frontend, so I would much rather ship this for now and then work on that afterwards if we are cool with that @brianlovin?

@brianlovin
Copy link
Contributor

That being said, it would require a lot more work to make plaintext editing work on both the back- and the frontend, so I would much rather ship this for now and then work on that afterwards if we are cool with that @brianlovin?

Okay, I understand that's challenging. Since this is still a huge incremental improvement, let's 🚢 and figure out editing down the road. My 2 cents though is that I'm not worried about the user being able to edit the embeds after the fact.

@mxstbr
Copy link
Contributor Author

mxstbr commented Feb 12, 2019

Merging!!!!! 😱 🎉 🎉 🎉

Will get this live on alpha.

@mxstbr mxstbr merged commit 8e903bc into alpha Feb 12, 2019
@mxstbr mxstbr deleted the plaintext-thread-editor branch February 12, 2019 09:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants