Why is ^|\s+ used instead of just \s+ in .split()?

[ChALkeR]

On the following lines, ^|\s+ is used:

d3-dispatch/src/dispatch.js

Lines 15 to 17 in 893b6f4

	function parseTypenames(typenames, types) {
	return typenames.trim().split(/^|\s+/).map(function(t) {
	var name = "", i = t.indexOf(".");

Does that do anything different from what just \s+ would do?

It causes problems when trying to use this library in QML environment (V4 JS engine from Qt).
Ref: QTBUG-62471.

[mbostock]

I think the only difference is when typenames is the empty string or entirely whitespace.

"".split(/^|\s+/) // []
"".split(/\s+/) // [""]

[ChALkeR]

@mbostock Ah, thanks, I totally missed that.

Perhaps that could be solved with .filter(function(t) { return t; }) instead?
Or, a length check after .trim().

[ChALkeR]

I'm not even sure though that this would make things work under Qt QML, I checked pretty long ago.
Perhaps that needs a recheck before anything is done here.

[mbostock]

I’m not planning on taking any action. Thank you for the question.

[localpcguy]

I think I've found a (browser?) bug related to this regex and the question asked by @ChALkeR here. In Internet Explorer (v11 is where I saw this), the regex /^|\s+/ splits a string into it's individual characters. So something like "end".trim().split(/^|\s+/) in IE11 outputs ["e", "n", "d"]. In modern browsers, it outputs [ "end" ] as expected.

The issues seems to be the pipe, it looks like it causes IE to split not on the whitespace but on nothing, effectively.

I'm not sure what the expected browser support is, but as suggested above, using .split(/\s+/).filter(function(t) { return t; }) would achieve the same result, work in IE9+ (when .filter was added), and eliminate the regex bug.

Let me know if this should be a new bug.