4 ms·

> I'd honestly prefer a runtime error, just like you get if you try to render a JS object The React framework strives for catching everything at compile-time.

> I'd honestly prefer a runtime error, just like you get if you try to render a JS object The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. If I recall correctly, rendering null is behaviorally equivalent to not rendering, in React.

tshaddox 5y ago
> The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. I don't know whether that principle is generally true or ought to be generally true, but React does throw a runtime error if you render a plain JS object as a React child. This can probably also be prevented at compile time with linters or TypeScript, but given that React has to do something at runtime if it encounters an invalid child, I think throwing an error is preferable to just rendering nothing or having some undefined behavior. In my opinion, rendering `null` is a pretty clear and explicit way to indicate you don't want to render anything. But rendering `false` (or `true`, for that matter) is not at all so clear to me. I think throwing a runtime error would be better, and would largely make the `thing && <Component />` idiom go away.
- 9wzYQbTYsAIc 5y ago
  I get what you are saying. In my experience, it ends up being moot when you are explicitly trying to avoid runtime errors, because you’ll need something along the lines of “guard() && <Component />” or you could simply have “<Component />” and then within Component render have “if (!guarded) return <Fragment />”, etc. At that point, you’ll probably need to worry about component collections containing empty elements, though. That pulls you back into the parent scope, anyways. There’s probably a nicer way to handle it with custom hooks, though. > I don't know whether that principle is generally true or ought to be generally true They sure do go out of their way to make misuse of hooks a compile-time error. I think that those useful error messages go a long way to rectifying the archaic semicolon error messages of the C days.

tshaddox 5y ago

> The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. I don't know whether that principle is generally true or ought to be generally true, but React does throw a runtime error if you render a plain JS object as a React child. This can probably also be prevented at compile time with linters or TypeScript, but given that React has to do something at runtime if it encounters an invalid child, I think throwing an error is preferable to just rendering nothing or having some undefined behavior. In my opinion, rendering `null` is a pretty clear and explicit way to indicate you don't want to render anything. But rendering `false` (or `true`, for that matter) is not at all so clear to me. I think throwing a runtime error would be better, and would largely make the `thing && <Component />` idiom go away.

9wzYQbTYsAIc 5y ago
I get what you are saying. In my experience, it ends up being moot when you are explicitly trying to avoid runtime errors, because you’ll need something along the lines of “guard() && <Component />” or you could simply have “<Component />” and then within Component render have “if (!guarded) return <Fragment />”, etc. At that point, you’ll probably need to worry about component collections containing empty elements, though. That pulls you back into the parent scope, anyways. There’s probably a nicer way to handle it with custom hooks, though. > I don't know whether that principle is generally true or ought to be generally true They sure do go out of their way to make misuse of hooks a compile-time error. I think that those useful error messages go a long way to rectifying the archaic semicolon error messages of the C days.