Adds an Inline Edit component

[tweettypography]

Fixes #153

@jamin-hall / @minevskiy Still working on some cleanup here, but I'm opening a PR so you can take a look and let me know your feedback on the component.

[minevskiy]

Looks good. Will it be keyboard accessible?

[tweettypography]

@minevskiy It's current accessible with the following behavior: you can tab to the edit button, and hitting enter will take you to the input. Hitting tab when you finish typing will return the input to read-only state. Hitting enter will not currently end editing mode, not sure if it should or not.

Maybe @SiTaggart would have some feedback on additional accessibility needs? FYI to anyone looking into this, you can get to the live example here.

[minevskiy]

@tweettypography , We have the following requirement from @jhausler1266 :
When inline editing a field: ESC key should cancel out of inline edit for the input in focus.

[tweettypography]

@minevskiy Updated to return to read-only mode on hitting escape, but it'd be to the consuming application to not save the changes if that's what you mean by cancel. Is the requirement that you have that this component should revert to original state when hitting escape? In that case should there be a close button (like an "x" icon) in the input while it's active to indicate it's cancellable?

[tweettypography]

Note: merge #337 first as this one will likely need to be updated slightly once that goes in.

[minevskiy]

Yes, on ESC, the input should revert to original state. And, according to W-2807690, there should also be a cancel button somewhere.

[jamin-hall]

@minevskiy is there a place where we can learn more about W-2807690? Is that a documented accessibility standard?

Would adding a "close" icon to the input appropriately address this issue?

[minevskiy]

@jamin-hall , for more information on accessibility standard for inline input, please reach out to @jhausler1266 or @SiTaggart

[tweettypography]

@minevskiy / @jamin-hall: This should be ready for final review now. The close button itself isn't reachable via keyboard, but that's an accessibility bug with Input and when #315 is fixed it should fix this component too.

[jamin-hall]

@tweettypography looks good.

[minevskiy]

How would a consuming application determine that an edit was cancelled?

[minevskiy]

Currently, the click is handled not just on text or icon, but to the right of the field.

Is this by design? How would the consuming application restrict the click to just text and icon?

[tweettypography]

@minevskiy Actually, cancelling is an unresolved issue - it sounds like based on our previous conversation I should rework this to not send the updated value until the edit ends (but is not cancelled). Is that correct?

[tweettypography]

As for click locations -- current SLDS behavior is that inputs are set to 100% of their container width. So if you wanted a smaller hit area you would out the input in a smaller container. I'm not sure exactly how we would change that without adding additional markup or changing the SLDS markup. Thoughts?

[minevskiy]

@tweettypography , yes, ideally, it should not send the updated value until the edit ends.
For click locations, is it possible to keep input width at 100%, but listen for clicks on the inner span only?
<span class="slds-form-element__static">

[tweettypography]

@minevskiy Updated to follow this pattern

[tweettypography]

Actually, looks like with the latest updates the onBlur takes precedence over the onIconClick so clicking on the cancel icon saves rather than cancels. Will have to investigate further to squash that pesky bug. Everything else should be working as expected

[minevskiy]

looks good to me otherwise

[jwilcurt-salesforce-com]

I was given this design to reproduce. The example shown in this thread does not visually match this. Will there be a visually matching implementation of this?

[tweettypography]

@jwilcurt-salesforce-com what happens when you click add?

[jwilcurt-salesforce-com]

@tweettypography

Pop-over shows up for Description, for campaigns it will be a multi selection.

[tweettypography]

@jwilcurt-salesforce-com Looks that is a different pattern than the one covered by this component. You should be able to implement it already with the Popover component though.

[jwilcurt-salesforce-com]

@tweettypography

I was not referring to that, I was just answering your question.

I am refering to the underline with the pencil and the large font

"2016 Outdoors Rewards M..."

"Untitled Audiences"

Currently I have no means to create this without custom markup, css, and js.

[tweettypography]

@jwilcurt-salesforce-com Sorry! I was looking at on my phone and the line / icon were low enough contrast that I didn't even see them. I wonder if that's an accessibility issue. Anyway, the line is actually a default part of input and I intentionally disabled it because it wasn't in the the designs I received. Can you have the designer who gave you that reach out to me? As for size - you can add the class slds-text-heading--large which works before clicking edit but I'm not sure what you would do increase the size after clicking edit. You might have your designer investigate that as well

[tweettypography]

@minevskiy This should be ready for review now with the cancel button working properly

[minevskiy]

Where is handleIconMouseDown defined?

[tweettypography]

It's not, good catch. That was left over from testing alternative methods to work around the onBlur / onClick issues.

[minevskiy]

looks good. Thanks @tweettypography !