feat: calc support by paradowstack · Pull Request #56162 · facebook/react-native

paradowstack · 2026-03-19T19:10:05Z

Why?

calc() is a core CSS primitive and a common expectation for developers. Adding it to React Native enables more expressive and maintainable styles without JS-side manual calculations. It improves parity across web and native worlds, reducing friction when switching from another platform.

My tweet about this potential feature in React Native was really well received and many people expressed excitement about it.

Yoga PR link

Summary:

Bring Yoga dynamic value resolution into React Native and wire calc()-driven values.

Yoga resolves dynamic values during layout by calling back into React Native with layout context and dynamic id, allowing mixed-unit expressions to be evaluated just-in-time.

Changelog:

[GENERAL] [ADDED] - CSS calc() support

This PR includes RN-side integration needed to make Yoga dynamic values usable in renderer layout paths.

Wire Yoga dynamic callback resolution to RN calc expression storage and lookup.
Apply dynamic calc resolution for layout properties: dimensions, min/max, flex-basis, gap, position, margin, and padding.
Add viewport-aware resolution flow for vw/vh-based expressions.

Missing:

To keep this PR focused, some areas are intentionally out of scope and will follow in separate work.

Missing calc support for other CSS properties areas:
- borders & outlines
- transforms
- typography
Missing calc support for transform-related layout properties.
Missing full JNI/Java/JS API surface completion.

Test Plan:

Added focused C++ tests for calc parsing/evaluation.

Broader platform and API-level testing will be expanded in follow-up PRs.

cc @NickGerleman

NickGerleman · 2026-03-24T00:42:04Z

packages/react-native/ReactCommon/react/renderer/components/view/YogaStylableProps.cpp

  REBUILD_YG_FIELD_SWITCH_CASE_INDEXED(                              \
      position, setPosition, yoga::Edge::All, "inset");

+#define APPLY_CALC_COMMON(fieldName, setPoints, setPercent, setDynamic)    \


nit: why does this need to be a macro?

It does not - I wrote it as macros because this file already achieve similar functionality using macros (REBUILD_FIELD_YG_* stuff) and I got the feeling it would be more consistent.
Would you like me to rewrite it using template functions?

NickGerleman · 2026-03-24T00:42:43Z

packages/react-native/ReactCommon/react/renderer/core/LayoutContext.h

+  /*
+   * Viewport size is size of the React Native's root view.
+   */
+  Size viewportSize{};


Ooh, this may be helpful in more places in the future 👍. If you had a PR for just the plumbing for e.g. this part of the change, would be quick to import and accept.

I extracted it to the separated PR: #56209

NickGerleman · 2026-03-24T00:49:24Z

packages/react-native/ReactCommon/react/renderer/css/tests/CSSCalcTest.cpp

+}
+
+TEST(CSSCalc, simple_pixel_value) {
+  auto result = parseCalc("calc(10px)");


I'm trying to figure out how CSSCalc works, more generically.

Ideally, any place where we use a specific CSS type, valid calc expression should work. So e.g. if we are parsing the result of a box-shadow, which expects a <length> in the middle, that length should be able to be some arbitrary calc() expression.

Like 0 calc(16px - 2px) should be valid, for reading something that requires two lengths.

Can we make that sort of scenario work? If we can do this sort of more generic substitution, it also gives us a way later to introduce variables.

NickGerleman · 2026-03-24T00:51:19Z

packages/react-native/ReactCommon/react/renderer/css/CSSCalc.h

+    auto opResult =
+        parser.syntaxParser().consumeComponentValue<std::optional<char>>(
+          CSSDelimiter::None, [](const CSSPreservedToken &token) {
+              if (token.type() == CSSTokenType::Delim) {
+                auto sv = token.stringValue();
+                if (!sv.empty() && (sv[0] == '+' || sv[0] == '-')) {
+                  return std::optional<char>{sv[0]};
+                }
+              }
+              return std::optional<char>{};
+            });


IIRC these aren't actually Delim tokens in the spec, but CSSTokenizer, didn't add any of the tokens for calc(), calc-constants, etc. This change will need to update tokenizer layer a bit. Adding tokenizer awareness of calc tokens, could be its own change, that would be easy to merge independently.

Please take a look at my attempt to do that: #56234

I am just getting familiar with CSS spec, so let me know if things should land in different files or shape, I was a little confused. I explored a few potential solution and thought that this would be the most correct - but I am happy to revisit and adjust it.

Summary: Add viewport size to `LayoutContext` and wire it through Android and iOS layout setup so viewport dimensions are available during layout. This was extracted from the larger `calc()` work in PR #56162. ## Changelog: [GENERAL] [ADDED] - Add viewport size to LayoutContext Pull Request resolved: #56209 Test Plan: - This change is limited to internal layout plumbing in React Native core and does not alter external behavior on its own. - Validation for the actual `calc()` use cases will be covered in the follow-up work that consumes this plumbing. Reviewed By: christophpurrer Differential Revision: D98004758 Pulled By: NickGerleman fbshipit-source-id: 3fd6257b2c280442a41308af3e6eff30b51a3397

paradowstack · 2026-04-01T18:39:02Z

Hello @NickGerleman,

I am working right now on adding the support for calc() for all style properties. The goal is to be able to use calc() expressions in every place that expects value of type <length>, <number>, <percentage>, etc.

For expressions that can be evaluated in the parse time during Render phase that should be pretty straightforward and borderRadius: "calc(10px)" will be directly transformed to borderRadius: 10px. However, parse time evaluation cannot be achieved for properties with relative units (vw and vh for now, but later also em, rem, ex, etc), and for properties mixing percentage and dimensions (<type-percentage>, e.g. backgroundPosition: "calc(10px + 25%) calc(25% + 10vw)").

After the investigation I came up to some conclusions and below is my implementation plan. I would appreciate your feedback on it.

Absolute value calc() expression should be simply evaluated in the parse time.
- This requires changes mostly in conversion area, such as:
  - process<Property>.js* files
    - Pass calc() string equation to C++ layer, not only number | '${number}%' format as it is now
  - conversion.h files
    - Add auto calc() -> ValueUnit conversion
  - BoxShadowPropsConversions.h and similar conversion files
    - Modify all places that expects Float type
Mixed/Combined calc() expressions cannot be evaluated at this stage due to lack of information about reference values. Therefore, calc() expression has to be stored. Potential solutions I considered:
- Extend existing types, such as ValueUnit, to support new dynamic calculation.
  - Can be achieved similarly to yoga::StyleLength, by:
    - Holding a calc() ID (and store equation coefficients in separated place), or
    - Holding a full calc() equation.
  - Later on during props diffing and mounting these values has to be obtained using dedicated convenience resolve methods (e.g. BaseViewProps::resolveTransform(...) method and new ones)
  - This requires:
    - Introducing new type and use it everywhere currently Float or ValueUnit types are used in property classes.
    - Provide resolve<Property>() convenience functions
- Add a "post-process" operation (when required information are available) on Props that replaces all unresolved calc() properties with resolved values.
  - During parsing property values that cannot be evaluated has to be marked as Undefined/Unresolved, calc() equation has to be stored and connected with property.

Please let me know if you agree with conclusions on point 1, maybe I am missing something here?
How do you see implementation and solution of problem 2? Perhaps there is another, better solution.

Thanks in advance!

meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Mar 19, 2026

facebook-github-tools bot added p: Callstack Partner: Callstack Partner labels Mar 19, 2026

paradowstack mentioned this pull request Mar 19, 2026

Add core Yoga support for calc() facebook/yoga#1874

Open

2 tasks

paradowstack marked this pull request as ready for review March 19, 2026 19:15

facebook-github-tools bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Mar 19, 2026

paradowstack force-pushed the feat/calc branch from 5aa79b9 to 1fc83cf Compare March 20, 2026 16:32

efoken mentioned this pull request Mar 21, 2026

Adds initial support for calc() facebook/react-strict-dom#466

Open

NickGerleman reviewed Mar 24, 2026

View reviewed changes

paradowstack added 5 commits March 24, 2026 10:44

feat: add viewport size to LayoutContext class

81a65d2

feat: calc support

12696b2

refactor: adjust CSSCalc formatting

4c733b9

refactor: use FNV-1a hashing for calc expression property identification

61455ea

refactor: fix return type syntax leftover in CSSCalc operator+

3cda37b

paradowstack force-pushed the feat/calc branch from 1fc83cf to 3cda37b Compare March 24, 2026 14:11

This was referenced Mar 24, 2026

feat: add viewport size to LayoutContext class #56209

Closed

Add CSS calc constants and operators support #56234

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: calc support#56162

feat: calc support#56162
paradowstack wants to merge 5 commits intofacebook:mainfrom
paradowstack:feat/calc

paradowstack commented Mar 19, 2026

Uh oh!

NickGerleman Mar 24, 2026

Uh oh!

paradowstack Mar 24, 2026

Uh oh!

NickGerleman Mar 24, 2026

Uh oh!

paradowstack Mar 24, 2026

Uh oh!

NickGerleman Mar 24, 2026 •

edited

Loading

Uh oh!

NickGerleman Mar 24, 2026 •

edited

Loading

Uh oh!

paradowstack Mar 26, 2026

Uh oh!

paradowstack commented Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

paradowstack commented Mar 19, 2026

Why?

Summary:

Changelog:

Missing:

Test Plan:

Uh oh!

NickGerleman Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

paradowstack Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

NickGerleman Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

paradowstack Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

NickGerleman Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NickGerleman Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paradowstack Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

paradowstack commented Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

NickGerleman Mar 24, 2026 •

edited

Loading

NickGerleman Mar 24, 2026 •

edited

Loading