I didn't include the sidebar icon here on purpose. I thought it would be better if we didn't render a CommIcon component and instead just increased the paddingLeft in dummySidebar to accommodate for the icon.

I attempted to use a react fragment here; however, it always resulted in a white box appearing on the screen for a few seconds. When I used a View, I did not encounter this issue

Since the inline engagement is already included in the contentHeight we don't need to do this check anymore

Since we don't really care about colors for the dummy nodes. I thought it would be a good idea to skip the const styles = useStyles(unboundStyles); step.

This follow a similar pattern used in other places where we measure nodes:

• https://github.com/CommE2E/comm/blob/master/native/calendar/entry.react.js#L99-L101C11
• https://github.com/CommE2E/comm/blob/master/native/chat/inner-robotext-message.react.js#L27-L28

InnerTextMessage does not follow this exact pattern; however, its style sheet does not use any colors so we do not need to have an unboundStyles object:
https://github.com/CommE2E/comm/blob/master/native/chat/inner-text-message.react.js#L162-L176

We should avoid duplicating styles as much as possible to avoid bugs caused by them getting out of sync.

This is a good point. I think the best way to go about this is to separate out the color style from the object and have it used in other object. For example:

messageLabel: {
  paddingHorizontal: 3,
  fontSize: 13,
  top: inlineEngagementLabelStyle.topOffset,
  height: inlineEngagementLabelStyle.height,
  marginTop: inlineEngagementStyle.marginTop,
},
dummyMessageLabel: {
  marginLeft: 9,
  marginRight: 4,
}
messageLabelColor: {
   color: 'messageLabel',
}

Then we can use messageLabel in both the actual node and the dummy node (which should address this concern), we still don't need to introduce useStyle hook in the DummyInlineEngagementNode component, and if we need specific styles for the dummy node we still have a style object for it.

Not super related to this diff, but when I was addressing the duplicated styles concern, this seemed like a good opportunity to memoize the editedLabelStyle separately from editedLabel