Document white-space behavior?

[syranide]

The white-space behavior of JSX is quite important to React and probably makes a lot of sense from a JS-perspective where the content of strings are tightly controlled. Encoding all white-space as-is would add significant useless overhead to generated output and the way you structure your code would affect the output (which is really bad IMHO).

Do we have to document it? Not really, but it could make sense (especially for inter-op).

Another thing worth considering is what we want to do with intentional leading/tailing whitespace, currently you have to do ( (or {' '} if you don't care about split children), it is not actually supported by JSX at the moment, but it will be. Perhaps there are better solutions? Something like {+' '}, {+' '+}, etc?

Feel free to glance at facebook/react#480 for my research/decisions for the current white-space rules (my "dense language" may not make it easy though, but I'd gladly explain it all if necessary).

PS. I feel like dropping the "tabs to spaces" I decided on for JSX, it makes some sense, but it's also kind arbitrary (what about vertical tabs, etc, etc).

[sebmarkbage]

I think that these whitespace rules are very specific to React because it's more common to reason about individual children. For HTML generation it might not be important or even wanted. For example you may rely on CSS pre whitespace or rely on CSS doing the collapsing of white space before presentation. If you want to use JSX to generate strict XML, you may have other whitespace requirements.

[syranide]

@sebmarkbage My entirely person opinion on this is that HTML white-space rules sucks, badly. It's a nice idea, but it's rediculous to have to remove newlines and make weirdly long lines to avoid white-space from seeping in and it leaves irrelevant data in the final code that cannot be minified away.

white-space: pre etc is a good thought and the only valid use-case for keeping white-space intact I think, but it's very very uncommon and also horribly ugly as it requires you to disobey all indentation and generally write horrible code. In HTML it's just the way it is, in JSX you can and should use regular strings (or templates even?) for such use-cases.

  return (
    <div>no<span>space</span>please
      <span style={{whiteSpace: 'pre'}}>some
aligned
text and such</span>
    </div>
  );

No... just no :)

That is my entirely person opinion, but I honestly believe there isn't a single valid use-case for copying white-space as-is for JSX. That said it doesn't have to be included in the specification still, but I imagine it could be very beneficial for other implementers, as deciding on the "right solution" is quite a tricky thing. Being able to copy code from React-JSX to other JSX-based frameworks (and vice-versa) could also be a big benefit, no framework is ever going to be best at everything.

So it makes sense to me to do it, but I "don't really care" if you don't. :)

[sebmarkbage]

This spec is kind of a minimal viable product. The only thing that kills standardization is taking on too large of a scope not agreeing on details. I'm afraid on taking on too large of a scope. Minimalism is what made JSON a successful spec.

I'm not saying that preserving all whitespace is necessary a valid use case but different rules, such as preserving all whitespace except the indentation used at the element might be legitimate.

[syranide]

@sebmarkbage

This spec is kind of a minimal viable product.

In that context, I definitely agree. Closing.

...such as preserving all whitespace except the indentation used at the element might be legitimate.

I see your point and while I don't think it would ever make sense for JavaScript, it could however for CoffeScript or whichever it is that is indentation-aware. 👍 (not sure if I'd call it good practice, but w/e :))