Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add React Server Component support #502

Merged
merged 1 commit into from
Jun 4, 2024

Conversation

EvanBacon
Copy link
Contributor

Summary

  • Add support for React Server Components.
  • This is very basic support which bails everything out of being run on the server.
  • We can circle back when it's easier to test, and make more of the module run server-side.

Test Plan

@jacobp100
Copy link
Collaborator

Assume if we change this to use server later down the line, that wouldn’t be a breaking change?

I’d love for the web version to use calc and env vars, which would work server side - even without hydration

@jacobp100
Copy link
Collaborator

I think our SafeAreaView component could (almost) be as simple as:-

const SafeAreaView = (props) => {
  const style = { ...StyleSheet.flatten(props.style) }
  if (props.edges.includes('top')) {
    style.paddingTop = `calc(env(safe-area-top, 0px) + ${style.paddingTop ?? style.paddingVertical ?? style.padding ?? 0}px)`
  }
  // ...
  return <View style={style}>{props.children}</View>
}

Copy link
Member

@janicduplessis janicduplessis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, sounds good. If someone wants to contribute a server component version later it would be great.

@EvanBacon
Copy link
Contributor Author

@jacobp100 "use server" defines functions that run in the server, essentially API routes. In an RSC world, the default is react-server and you opt-out of the tree with "use client". Today's behavior is that everything in the module runs in the server and you get errors when values like __fbBatchedBridgeConfig are accessed, as they only exist in native JS runtimes. To "solve" this, we mark code paths that use unavailable globals with "use client". Behind the scenes, this directive basically erases the contents of the file and turns it into a boundary that must be split out and fetch/eval'd on the client.

In the future, we'll want to shift more binding code to the native side and expose the globals directly so native apps can tree-shake as much JS as possible. Here's a little more about how I see that working 0kb React Native components.

@jacobp100
Copy link
Collaborator

@EvanBacon I was more meaning that the user might have some components behind a SAV that aren't marked as 'use client', and it would only not be an issue because SAV is client only, so won't render them. If we then change it so something is rendered, their code could break. I'm not sure how much of a breaking change that would be considered

@EvanBacon EvanBacon deleted the @evanbacon/add-rsc branch June 4, 2024 15:11
@janicduplessis
Copy link
Member

Released as 4.10.4

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants