5 ms·

So I am guessing if a prop is `instanceof Promise` or some other constructor then it must trigger this response . . . is that correct?

acemarke 9y ago
The key phrase is "thenable", which is a term for anything where `typeof variable.then === "function"` is true.
- wereHamster 9y ago
  But only when passed to HTML elements I hope. Because say I have my own type of the shape `{ then(): Whatever }` and try to pass that as a prop to one of my components I don't want React to invoke that function.
  - acemarke 9y ago
    It's not about passing props - the "thenable" detection comes into play if you throw a promise (or something shaped like a promise) from within `render()`.
    - wereHamster 9y ago
      Wait, can render functions now throw, legally?
      - timdorr 9y ago
        Yup. This builds on error boundaries and componentDidCatch: https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html https://reactjs.org/blog/2017/07/26/error-handling-in-react-...
      - danabramov 9y ago
        Yes. (For this use case.)
btown 9y ago
React isn't changing any logic of the types of props; if you actually pass a Promise as a prop, it will be treated 100% as it was in previous React versions. What's happening instead is that imageFetcher.read() either returns a string OR throws a promise; it never returns a Promise. So <Component foo={fooFetcher.read(...)} /> either gets instantiated with the fetched Foo, or throws so React.createElement(Component, ...) never gets called in the first place. Only if you physically throw a Promise (or "thenable") does the new logic apply: https://github.com/facebook/react/pull/12279/files#diff-1996f2b11f9c68c0a81652e32be88ddbR132 https://github.com/facebook/react/pull/12279/files#diff-1996... is called inside an exception handler.
- pault 9y ago
  Wow, I never would have considered throwing anything other than an Error. On the face of it, this seems like an incredibly powerful technique, but is it an abuse of a language feature?
  - riquito 9y ago
    Is a feature of the exceptions to let you handle exceptional cases far away from the caller, up in the stack. You should keep a distinction between exceptions that means "error" and exceptions that means "some kind of event happened", and handle them accordingly.
  - acjohnson55 9y ago
    My guess is that it won't catch on in the long run. But, you never know.
  - btown 9y ago
    Python “abuses” exceptions in a similar way every time you iterate over a generator: https://softwareengineering.stackexchange.com/questions/112463/why-do-iterators-in-python-raise-an-exception https://softwareengineering.stackexchange.com/questions/1124... At the end of the day it’s just a control flow mechanism. And theoretically, if you lack data needed to render, it’s an exceptional condition.

acemarke 9y ago

The key phrase is "thenable", which is a term for anything where `typeof variable.then === "function"` is true.

wereHamster 9y ago
But only when passed to HTML elements I hope. Because say I have my own type of the shape `{ then(): Whatever }` and try to pass that as a prop to one of my components I don't want React to invoke that function.
- acemarke 9y ago
  It's not about passing props - the "thenable" detection comes into play if you throw a promise (or something shaped like a promise) from within `render()`.
  - wereHamster 9y ago
    Wait, can render functions now throw, legally?
    - timdorr 9y ago
      Yup. This builds on error boundaries and componentDidCatch: https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html https://reactjs.org/blog/2017/07/26/error-handling-in-react-...
    - danabramov 9y ago
      Yes. (For this use case.)

btown 9y ago

React isn't changing any logic of the types of props; if you actually pass a Promise as a prop, it will be treated 100% as it was in previous React versions. What's happening instead is that imageFetcher.read() either returns a string OR throws a promise; it never returns a Promise. So <Component foo={fooFetcher.read(...)} /> either gets instantiated with the fetched Foo, or throws so React.createElement(Component, ...) never gets called in the first place. Only if you physically throw a Promise (or "thenable") does the new logic apply: https://github.com/facebook/react/pull/12279/files#diff-1996f2b11f9c68c0a81652e32be88ddbR132 https://github.com/facebook/react/pull/12279/files#diff-1996... is called inside an exception handler.

pault 9y ago
Wow, I never would have considered throwing anything other than an Error. On the face of it, this seems like an incredibly powerful technique, but is it an abuse of a language feature?
- riquito 9y ago
  Is a feature of the exceptions to let you handle exceptional cases far away from the caller, up in the stack. You should keep a distinction between exceptions that means "error" and exceptions that means "some kind of event happened", and handle them accordingly.
- acjohnson55 9y ago
  My guess is that it won't catch on in the long run. But, you never know.
- btown 9y ago
  Python “abuses” exceptions in a similar way every time you iterate over a generator: https://softwareengineering.stackexchange.com/questions/112463/why-do-iterators-in-python-raise-an-exception https://softwareengineering.stackexchange.com/questions/1124... At the end of the day it’s just a control flow mechanism. And theoretically, if you lack data needed to render, it’s an exceptional condition.