4 ms·
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. W
by 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 agoWow, 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 agoIs 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 agoMy guess is that it won't catch on in the long run. But, you never know.
- btown 9y agoPython “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.
- pault 9y agoIt's a very interesting technique; I will definitely be keeping an eye out for appropriate use cases.