mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Nick Gerleman
69f761f1ac
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/48718 This diff looks a bit scary, but it's mostly just structural changes of existing code and some deletion, on a well tested path 😅. The current parser implementation tries to special case "basic" data types. When I was looking at how to add in support for more complex values, such as lists, function notations, and more compounded types, this distinction ends up not making much sense. Instead of treating some types as basic, this diff instead moves to a model where a user can declare any structure as a `CSSDataType`, so long as they also supply a parser, which may be visited when iterating through CSS syntax blocks (preserved tokens, function blocks, or simple blocks, which probably won't be used). The user then specifies a list of supported CSS data types to parse, which invokes said parser, calling any defined methods for specific syntax. E.g. ```cpp struct CSSNumber { float value{}; }; template <> struct CSSDataTypeParser<CSSNumber> { static constexpr auto consumePreservedToken(const CSSPreservedToken& token) -> std::optional<CSSNumber> { if (token.type() == CSSTokenType::Number) { return CSSNumber{token.numericValue()}; } return {}; } // Could also accept function block here as well (e.g. for future math // expressions) }; static_assert(CSSDataType<CSSNumber>); ``` ```cpp // Can be one of std::monostate (variant null-type), CSSWideKeyword, // CSSNumber, CSSLength, or CSSPercentage. In this case, a CSSLength. auto value = parseCSSProperty<CSSNumber, CSSLength, CSSPercentage>("5px"); ``` This breaks a whole lot of assumptions I made a year ago, especially around `CSSValueVariant` which must now be able to handle arbitrary values. For now, for the sake of simplicity, I threw this out, and migrated parser code to use plain-old `std::variant`, which has a downside of being a bit less optimized in terms of storage. I also ended up completely throwing out `CSSDeclaredStyle`, since it would majorly need to change, and we're not going to be migrating style storage quite yet. This change also broke the `CSSProperties.h` property definitions and parsing shorthand a bit, which we will need for value processing later. I also opted to delete this for now (a big centralized list is the wrong structure anyways), but will likely copy bits from its source history later. Another particular hairy bit, that likely won't bite us in practice, is that some strings may be parseable under different data types. This just adds caller requirement to order the types correctly, instead of precedence being implemented as part of the parser. Changelog: [Internal] Reviewed By: lenaic Differential Revision: D68245734 fbshipit-source-id: 132b11053cf41f57483c89176a9a6dceebb69fad