Restores 'border' when 'borderColor' is removed

[igorklopov]

STYLE: 'border' already contains color component. So, after 'borderColor' removal, the style should fall back to color value taken from 'border'. Here is the fiddle of malfunction: http://jsfiddle.net/a4grcdtw/

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[syranide]

Not sure what the devs feel, but it's technically invalid to have both border and border-color at same time (in the style object). This also affects performance as one style update has now become two. Invariant/warning may be preferable here. The only case I can make for this is animating foreign style objects, but I'm not sure why you would do that.

[igorklopov]

There are no additional DOM updates. When you remove 'borderColor' leaving 'border', the real DOM removal is suppressed (line 436 of my ReactDOMComponent.js) and only 'border' is reintroduced.

[sophiebits]

@syranide Is it really invalid? I often write something like

border: 1px solid #000;
border-style: solid none;

to get borders on only top and bottom.

[syranide]

@spicyj That's why I added "in the style object" :). border is an alias/shorthand for all the other properties, you cannot set both and then unset only one of them. However, that being said, supporting this is not bad in itself (it's the most intuitive solution to ambiguity), although I would be careful to compare it to CSS as there you can do:

border-style: solid none;
border: 1px solid #000;

... and only the last line would end up being used, this is not something we can offer (because: map) and there's no reason to either. There's no harm in supporting this I imagine, but it does add bytes, it adds redundant bytes to the generated HTML too and it does have a non-obvious performance implication (apart from actually adding more styles to be set initially too):

border: 1px solid #000;
border-top-color: #ff0000;
...

... adding/modyfing/removing only border will require all additional border properties to be restored (and this applies to border-style and friends as well). Is it a real-life performance issue? Probably not, but it is a consideration. I think the biggest danger here is laziness, given that this performance issue is rather unintuitive/unexpected in some sense, it could come to bite a number of people (especially if inline styles become more common).

So there's no doubt to me that this would be the best/correct solution, if for example we would parse border and border-style and merge it into only a single border style update. However, considering that this is a hot path and it always will be, I don't see that happening (for other reasons too) and perhaps it's better left to a user "style callback"/"border helper".

So I wonder, is there any "valid" use-case that would require this, that would offset the hidden danger?

EDIT: As spicyj mentioned, being able to set all borders and remove one is a pretty common pattern in CSS, so there's that...

[sebmarkbage]

The test shouldn't mutate.

This pattern currently relies on enumeration order. This might not be possible in the future (e.g. using ES7 value types). We might need to rely on alphabetic order. We should consider not allowing conflicting style rules at all.

[gaearon]

Thank you for sending the PR! It has not been updated in response to the feedback for quite a while, so I am closing. For an up-to-date issue about this with a summary and the discussion of the desired behavior, please see #6348. We hope to see you contributing again!