+1 for this

I think we can slim this down a bit without losing much functionality, but inlining the property name and skipping one of the conditionals:

if (attrs && attrs.dangerouslySetInnerHTML) {
    s += attrs.dangerouslySetInnerHTML.__html;
}

Good call on dropping the extra check, no need for __html to be valid to add it. I didn't inline the property because that seems to cost 1B more than declaring let setInnerHTMLAttr = 'dangerouslySetInnerHTML'.

However I did find 4B that can be cut out regardless (b8199d3) which should helps a little.

Aha, whoops maybe I should've looked here before implementing #17…

#17 does pass one test that this doesn't, though I'm not sure whether it "should" according to the spec. The test is:

it('should support dangerouslySetInnerHTML (without __html)', () => {
  expect(
    <div dangerouslySetInnerHTML>foo</div>
  ).to.equal(
    '<div></div>'
  );
});

In this case, this PR returns <div>undefined</div>.

@ithinkihaveacat - I'm going to merge Peter's here, since it's substantially smaller. I personally don't care what we return for the case of a boolean dangerouslySetInnerHTML value - since that actually throws in React most folks wouldn't be using it.