first, you can't return multiple sibling elements as jsx without a parent container, unless you put them into an array (though you can't return arrays from render methods until react adds support for returning fragments).

this is invalid:

return (
  <div>first sibling</div>
  <div>second sibling</div>
);

these are both valid:

return (
  <div>
      <div>first sibling</div>
      <div>second sibling</div>
  <div>
);

// vs.
// (notice this requires adding keys)

return ([
  <div key={1}>first sibling</div>,
  <div key={2}>second sibling</div>
]);

second, if you want to use a conditional statement to render components, you have to do it like this:

{(index % 2 === 0) &&
  <div>this will render when index % 2 === 0</div>
}

the reason this works is that the && operator in javascript evaluates to the second operand (your jsx in this case) if the first operand is truthy. you can also use ternary statements, like this:

{(index % 2 === 0) ?
  <div>this will render when index % 2 === 0</div>
:
  <div>this will render when index % 2 !== 0</div>
}

putting this all together

var items = ['abc', '123', 'doe', 'rae', 'me'];
return (
  <div>

       {items.map((item, index) => (
            <div>
                <span dangerouslysetinnerhtml={{ __html: item }}></span>

                {(index % 2 === 0) &&
                    <h1>test output/h1>
                }
            </div>

        ))}

  </div>
}

[edit] important note

i should mention that whenever you're rendering an array of elements using something like items.map(...), you should really be assigning a unique key to each element in the list that you're rendering:

{items.map((item, index) => (
  <div key={item.get('id')}>item #{index}</div>
))}

the reason is that react does some optimizations here to make rendering (and re-rendering) lists less costly. if it sees a list that used to be composed of keys 0, 1, 2 and you've done some operation to reorder the items in your state, so that now the keys are passed to your map function in the order 0, 2, 1, it won't rebuild the dom to reflect the changed order, but rather will just swap the dom nodes (which is faster).

this leads to why you don't want to use index as a key for your elements, unless you know that their order won't change. let's say you used the iteration index as your keys:

{items.map((item, index) => (
  <div key={index}>item #{index}</div>
))}

now, if your items change order, they'll be output with the keys in the same order (index 0 will always be the first index, index 1 will always be the second index, and so on) but with different text inside each div. react will do a diff with the real dom, notice that the value of each div has changed, and rebuild that entire chunk of the dom from scratch.

this gets even worse if your list elements include something with state that isn't reflected in the dom, like an <input>. in that case, react will rebuild the dom, but any text the user has input in those fields will remain exactly where it was! here's an example from robin pokorny that demonstrates what can go wrong (sourced from this article):

https://jsbin.com/wohima/edit?js,output