![]() Wrap the TranslatedText object in a component before passing it in as a prop. Having seen this: The fix was super simple. The expected use is that this object is passed to a component that knows how to use it and a library of strings to render text in the correct language for the current user. The caller was passing it instead a TranslatedText object, which is a class we use in our system to handle internationalization. Using the file and line numbers to track down more, I could see that the object in question was a prop called description with the following type definition: description: string | React.ReactNode Interpretation: React was trying to render something that it could not render. Next was to fire up a developer environment so I could get a useful backtrace, and the error was extremely clear: My first check was to see if I could reproduce it in the production application. This feature is vital for a demo I have tomorrow. It started with a simple bug report: When I click on "Boost nudges" and attempt to select a filter group, I get an error saying something went wrong. UPDATE: This bug has been fixed in React 18! The Situation Click here to listen in on that part of the conversation! □Ĭome along as I share the exploration, why this bug has lingered in the wild for more than 3 (!) years since it was originally reported, and how we worked around it in our codebase to get ourselves protected again. We discussed this at a high level during the TIL segment of JS Party #213, but I thought it deserved a more rigorous treatment. How did this happen? At a high level it is because the React.ReactNode type included in DefinitelyTyped, used in hundreds of thousands of codebases around the world, is so weakly defined as to be practically meaningless. This is exactly the sort of bug we would expect TypeScript to catch at compile time! The source of the issue was a recent refactor done when internationalizing this area of our application, where a prop expecting a renderable React.ReactNode was accidentally getting passed an object of class TranslatedText which could not render. I recently handled a bug where a React component was throwing an exception at runtime. It’s that last reason that leads to the purpose for this post. But to me, the most important reason to use a strongly typed system is to eliminate an entire class of runtime bugs, where a function gets passed an object it doesn’t know how to handle and fails at runtime. The added tooling features, with IntelliSense and its ilk, are also a big help for productivity. ![]() The self-documentation aspects are huge – being able to step into an unfamiliar function and know the shape of the objects it’s expecting is a massive boon when working on a large project. As developers, we use TypeScript for a few different reasons.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |