4 ms·

How can null be implicitly cast to a string? I wasn't able to reproduce with: https://flow.org/try/#0PTAEAEDMBsHsHcBQiDGsB2BnALqAhgFyg4BOAlugOagC8o6ArtNANyoY6gB

How can null be implicitly cast to a string? I wasn't able to reproduce with: https://flow.org/try/#0PTAEAEDMBsHsHcBQiDGsB2BnALqAhgFyg4BOAlugOagC8o6ArtNANyoY6gBGRpF1dAOSRYsQaADU9JqyA https://flow.org/try/#0PTAEAEDMBsHsHcBQiDGsB2BnALqAhgFyg4BOA... Flow has built in support for the Language Server Protocol. tsserver doesn't even support LSP. I agree ts has better IDE support but that's in part because they don't use LSP. odd they expect others to follow it when they don't.

lhorie 7y ago
GP is saying they would like for flow to offer some leeway for things like this: https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNAE4owAGAJAN7YB0cAlmACYAUrUApgFsUAPhi9BKZKiyIMASgC+1fEA https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNA... (i.e. not nag on a "technically-it-could-be-non-string-but-I-know-for-a-fact-that-this-is-fine") LSP is kinda irrelevant to the argument that they feel that TS+VSCode is geared towards real-world productivity, vs the feeling that Flow prioritizes academic goals over devexp.
- _bxg1 7y ago
  Correct. JavaScript is fundamentally flexible on certain things, and while it's very helpful to have some assistance with taming that wilderness, it will fundamentally never be perfect, and by fighting the language tooth and nail on things that don't matter, one only creates developer pain.
_bxg1 7y ago
In plain JavaScript, 'foo' + null == 'foonull'. This isn't always what you want, but in the vast majority of cases if you're creating a string, it's: 1) For displaying to the user 2) Generating a CSS class or something to that effect In both of these cases the above is quite a reasonable behavior, and will never cause a runtime exception, and very rarely even a business-logic error. But if I'm working with the result of a .find() or a maybe-property on an object type, I now have to add null checks (or at best || '' fallbacks) everywhere, muddling up my code and making it harder to follow.
- lonelappde 7y ago
  Can you define an alternative to '+' that explicitly accepts null?

lhorie 7y ago

GP is saying they would like for flow to offer some leeway for things like this: https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNAE4owAGAJAN7YB0cAlmACYAUrUApgFsUAPhi9BKZKiyIMASgC+1fEA https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNA... (i.e. not nag on a "technically-it-could-be-non-string-but-I-know-for-a-fact-that-this-is-fine") LSP is kinda irrelevant to the argument that they feel that TS+VSCode is geared towards real-world productivity, vs the feeling that Flow prioritizes academic goals over devexp.

_bxg1 7y ago
Correct. JavaScript is fundamentally flexible on certain things, and while it's very helpful to have some assistance with taming that wilderness, it will fundamentally never be perfect, and by fighting the language tooth and nail on things that don't matter, one only creates developer pain.

_bxg1 7y ago

In plain JavaScript, 'foo' + null == 'foonull'. This isn't always what you want, but in the vast majority of cases if you're creating a string, it's: 1) For displaying to the user 2) Generating a CSS class or something to that effect In both of these cases the above is quite a reasonable behavior, and will never cause a runtime exception, and very rarely even a business-logic error. But if I'm working with the result of a .find() or a maybe-property on an object type, I now have to add null checks (or at best || '' fallbacks) everywhere, muddling up my code and making it harder to follow.

lonelappde 7y ago
Can you define an alternative to '+' that explicitly accepts null?