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

Markdown in OutcomeCards! #640

Merged
merged 24 commits into from
Jan 30, 2017
Merged

Markdown in OutcomeCards! #640

merged 24 commits into from
Jan 30, 2017

Conversation

ndey96
Copy link
Contributor

@ndey96 ndey96 commented Jan 15, 2017

This PR is meant to address #300

Opening it early. As of now, editing existing outcome cards is supported. Now just gotta work on editing new ones 💯

@jordanh
Copy link
Contributor

jordanh commented Jan 15, 2017

Huzzah!

@jordanh
Copy link
Contributor

jordanh commented Jan 22, 2017

Hey, you're really getting somewhere! Nice work so far!

image

image

There are a few things we'll need to work out, aesthetically and interaction-wise:

  • What padding should we use internally?
  • Should we get rid of pressing enter to submit? If so, how should cards be submitted?
  • Should we scale images that are too large? Or, should we clip them?
  • How shall we handle clicks on links? Should they open a new window? How shall we intermediate the click-to-edit?

What other things should we think about?

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 22, 2017

Everything should work properly now, just need to add the proper styles...

@jordanh
Copy link
Contributor

jordanh commented Jan 22, 2017

Jinx!

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 22, 2017

Styles:

  • I think we can reuse the padding that was used before
  • want to add hover -> backgroundColor = grey
  • work-break -> break-word

I think enter to submit should definitely stay and we should also add support for ctrl+enter (right now only shift+enter is supported)
I feel like clicking links should open new tabs, hopefully this markdown library makes that easy
Might also have to look at dealing with super large photos and setting a max width

@jordanh
Copy link
Contributor

jordanh commented Jan 22, 2017

Awesome! Keep going. Excellent work thus far.

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 23, 2017

@jordanh @ackernaut @mattkrick Most of the styling and logic should be done now :)

Just need to style any img tags within the markdown content to have max-width: 100% but I can't figure out the syntax :(

In other words how would you do this:

.markdown img: {
    max-width: 100%
}

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 23, 2017

testing with this markdown: ![image](https://exoticcars.enterprise.ca/etc/designs/exotics/clientlibs/dist/img/homepage/Homepage-Hero-Car.png)
Currently the image will overflow because it is too wide

@ackernaut
Copy link
Member

ackernaut commented Jan 23, 2017

@ndey96 this is looking good! Exciting!

A couple of notes on styling:

  1. With the original design I was going with a look where the formatting was essentially the same when just looking at the cards or interacting with them. This helped the cards have less wonky size changes just for interacting with them. I realize that with markdown, the content of the textarea now can be very different than the output so there will probably be some breathing, but overall I would like to try and retain similar padding and line-height etc.

  2. I noticed that some of the Action card styles (yellow cards during a meeting) were removed. Basically the hover/focus state is an extension of the theme of the card, so we need to work that back in considering any updates from point 1 above.

  3. I think the safest way to handle that image ATM is adding this to globalStyles.js but we will need to keep an eye out if that goofs up a style somewhere else (which should be easy to fix):

img: {
    maxWidth: '100%'
  }

@jordanh
Copy link
Contributor

jordanh commented Jan 23, 2017

@ndey96:

As I said before, great work on this so far. Before you move onto another issue, can you please offer a checklist of what you think needs to get done before you merge?

I'll respond with a check-listed test plan.

When we've checked off the items on both lists, we should be good to merge. Thank you!

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 24, 2017

Here is what I think needs to be done before a merge:

  • add styling for wide images
  • restore styles for yellow cards during meetings
  • fix any comments that Matt makes @mattkrick

Nice to haves:

  • clicking links opens new tab (no option in markdown library for this so I'm not sure how to implement without forking the markdown renderer and writing it myself)
  • supporting ctrl+enter being equivalent to shift+enter

@ackernaut
Copy link
Member

ackernaut commented Jan 24, 2017

Ooh I like your list @ndey96 ! I'll pull down and take a gander. And here is a note:

It occurred to me last night what the UI design spec is that I would like to see for card content:

If a user only uses text (no MD formatting) then the textarea and the content should look the same in terms of typography (line-height, font-size) and layout/gutters (padding). Hover states highlight the editable area, simply editing text results in no change of spacing. If a user does add formatting then we can expect the editing state to look different than the final state.

I'm going to test against this spec, and see how it holds up!

@ackernaut
Copy link
Member

Ok @ndey96 got 4 demos coming atcha!

Action card, production
Action card, with MD

Project card, production
Project card, with MD

You will notice a difference in hover states and text formatting. I would like to retain the seamless feel of the production state for cards, meaning only cards with formatting would have a different output than when editing.

I would also like to retain the same hover states (with the borders, etc.) unless we iterate on that styling. I believe we were using transparent top and bottom borders in order to keep the height the same as when hovering.

@ackernaut
Copy link
Member

Also, note that the highlight (hover state) coloring is different for action and project cards.

@jordanh
Copy link
Contributor

jordanh commented Jan 25, 2017

Test plan

It should:

  • autofocus when new cards are created
  • render markdown onSubmit (when tab is pressed, or click to blur)
  • render links that open a new tab when clicked
  • allow for embedded images, but size them to the card (i.e. not overflow the container)
  • disallow the pasting of raw html

@jordanh
Copy link
Contributor

jordanh commented Jan 25, 2017

@ackernaut would you mind giving this a test and some feedback today?

@ackernaut
Copy link
Member

Taking a gander now.

@ackernaut
Copy link
Member

ackernaut commented Jan 25, 2017

This is coming along very nicely!

I checked off a few tests: 1) autofocus new cards 2) render on tab, on blur 3) links open in new tab 4) images do not overflow

As for 5) disallowing the pasting of raw html—when I paste HTML it just renders as text, so it allows pasting, but has no effect. Does that pass?

A few other notes:

  • I expected the new line to break (I had to press enter twice to get the break), kind of awkward:
  • Action card editing styles are not the same as Action card hover styles (and they should be, should be simple fix):
  • Hard to reproduce, but sometimes the editing styles stick on blur, and not hovering. Not sure what we can do here, but it seems to be a sticky hover state.

Overall, impressed with the quick progress on this!! 👾

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 26, 2017

@ackernaut I believe html should be escaped and render as plain text so we don't use dangerouslySetInnerHTML which could open us up to XSS. right @jordanh ?

Also new checklist:

  • SQUASH newline bug
  • fix action card editing styles

@jordanh
Copy link
Contributor

jordanh commented Jan 26, 2017

Yes, html should be escaped. I believe it's working correctly the way you've got it configured now.

I like you're new checklist! Once you made your updates, I'll test again!

@ndey96
Copy link
Contributor Author

ndey96 commented Jan 26, 2017

@jordanh @ackernaut Updates made :) Thanks again for the feedback!

@ackernaut
Copy link
Member

@ndey96 looking good! 1) hover/editing styles are in place 2) newline 🐛 is bye bye!

YES!

@jordanh
Copy link
Contributor

jordanh commented Jan 26, 2017

This comment

has many newlines

and a link

@ackernaut
Copy link
Member

ackernaut commented Jan 26, 2017

line

line

The Action list form feels funny with out being able to submit on enter.
@@ -60,7 +59,7 @@ class UserActionListItem extends Component {
<Field
name={actionId}
component={OutcomeCardTextarea}
doFocus={!content}
doSubmitOnEnter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Action list felt funny without being able to submit on enter:

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the pro user will shift enter to break new lines?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that’ll work!

import React, {PropTypes} from 'react';

const LinkNewTab = (props) => {
const { children, href, title } = props;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ndey96 I removed the URL-helping here. It didn't sit well with me web-standards wise, and also, GitHub doesn't do any helping so I don't think we should either.

Let's use this is a starting point and if we need to grow something more ornate because our users are struggling, we will.

@jordanh
Copy link
Contributor

jordanh commented Jan 27, 2017

@mattkrick I think this is good to go, at least well enough for some testing on staging. Would you give the code a once over and also execute the following tests?

Test plan

It should:

  • Outcome cards on dashboard or meeting:
    • autofocus when new cards are created
    • render markdown onBlur (when tab is pressed, or click elsewhere)
  • Action list items:
    • autofocus when new cards are created
    • render markdown onBlur (when tab is pressed, or click elsewhere)
    • render markdown onEnter
  • rendered links open a new tab when clicked
  • allow for embedded images, but size them to the card (i.e. not overflow the container)
  • disallow the pasting of raw html

@ackernaut
Copy link
Member

So I can still reproduce, at random, cards where the hover state gets stuck. Sometimes it happens with I copy the contents of one card and go to paste into another card or action item. Working on a screen capture, and reliable steps. However I think this can be captured as bug and not necessarily block merge (unless there is an easy fix!).

@ackernaut
Copy link
Member

ackernaut commented Jan 27, 2017

So many times it will happen on a first interaction (since I've left the tab and returned) but when I turn on the screen recording the bug decides to hide from me! Haha.

So look at :24 of :30 in this screen recording:
screen recording

I select the content of the card then go to add it to an action item. The hover state sticks and persists. I have to finally go hover on and off after having created an action item. Is this some type of race condition on mouse movement and rendering life cycle?

Shows stuck hover state

@ackernaut
Copy link
Member

PS. I realize that I need a space between the # and heading to actually format the heading, doh!

@jordanh
Copy link
Contributor

jordanh commented Jan 28, 2017

@ackernaut yeah, the hover state business is odd.

Looking into the code, the interaction is driven in places above these changes. OutputCard communicates with OutputCardContainer via onMouseEnter and onMouseLeave events. This causes OutputCardContainer to update a state var called hasHover which then will cause the container's component tree to re-render. Why it appears that the onMouseLeave event isn't always being called is unclear.

I think it's possible this bug was pre-existing.

@mattkrick is it ok if I merge this PR? Or, would you like me to delay until you've had a chance to look? I'd like to put it up on staging...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants