Great video! We'll continue to improve every aspect of these new tools. Every function exported from a file are React Server Functions, not a React Server Component. You can only use inline React Server Functions ("use server" in async functions) when those functions are defined in a react-server environment, but the app/functions.tsx file runs in the client environment. To get around this, you can define the function in a file and mark it with "use server" at the top. If you return JSX from a React Server Action, you can pass a function with "use server" inside of it to make an inline React Server Action.
server side components/functions scares me a lot. They can be "packaged" but how distributed? With api you have much control over the tech stack and the infrastructure (load balancing, performance, etc), with this you have to add an additional component on the infrastructure, idk, i'm an old guy. Dom components, on the other hand, are amazing. Thanks for this
Normally when you build the app, the bundler gathers all the modules into a giant JS bundle that is put in the client. With the Server Functions flag enabled, the bundler does the same, but it converts all "use server" modules into relative fetch requests to a server (/_flight/foobar.tsx). The bundler does another pass to make the Node.js server. It does this by bundling all the "use server" files as entry points. Finally, we add a virtual API route at `app/_flight/[...rsc]+api.ts` which redirects the generated requests to the associated server functions. There are a bunch of other minor things wrapping this system to enable serializing arguments, error handling, and streaming, but mostly the magic is just in this little bundling maneuver. The result is two JS dist folders (just like the web)-one for client, and another for the server. The bundling operation is actually identical across web and native (this was hard to do both worth it) so it's not especially more complicated than web dev-which is objectively the easiest way to build frontends. I'm confident that we can automate this so much that you don't even notice the server part. As I've been using it over the last year, my fear has shifted from servers/unknown to the idea of just how much code I was packaging offline and exposing to the client. It's freeing to just fetch data and authenticate with secrets without worrying about having to do crazy things like hiding secrets in secure store on-device or setup short-lived implicit auth to circumvent a proxy server. But a healthy amount of skepticism is encouraged, try it yourself before taking my word for it!
Mind-blowing! Do you know what the PHP community has in common with React Native's? We love to improve and contribute! Expo is just what React Native always needed!
@@sanketgawande3667word. I’ll have to take some time to read about this. It makes sense with nextjs since you are pushing up a whole server to run the app. This is a mobile app so I don’t get it. Is the mobile device the server? Loo
You can read Evan Bacon's explanation in the comments but ultimately the server files generated (in a dedicated folder) can be hosted on any backend platform or infrastructure that supports Node.js. I guess that if the code is updated, both the application (client) and server components would need to be updated to remain in sync, otherwise the client may make requests to server functions (/_flight/foobar.tsx) that no longer exist or behave differently, leading to errors.
Interested to see how Expo will deal with the hosting side of things. It would be nice to see this better integrated with Vercel, in the same way Next.js is: just a single click, and you have everything hosted for your web/mobile app.
so all this stuff is used just in a web app created using react-native, if im just building a mobile application only, i dont need to use those features, am i right?
So if i understood correctly, i could have a node backend which is hosted separately and provides react native UI. Lets say we have an endpoint /products/xyz. On the Mobile Side of things we could just call the endpoint and the server (my hosted backend) would give me the UI. so whenever i want to change the UI i could just update the backend endpoint styling for example and it would be instantly rolled out ?
now if we generate for example an apk, how the server component will be compiled, or the SRCs will be extracted how a bakend which must be hosted separately please,
![ROSÉ (로제) - number one girl [더 시즌즈-이영지의 레인보우] | KBS 241129 방송](http://i.ytimg.com/vi/A9oByH9Ci24/mqdefault.jpg)
Great video! We'll continue to improve every aspect of these new tools.
Every function exported from a file are React Server Functions, not a React Server Component. You can only use inline React Server Functions ("use server" in async functions) when those functions are defined in a react-server environment, but the app/functions.tsx file runs in the client environment. To get around this, you can define the function in a file and mark it with "use server" at the top. If you return JSX from a React Server Action, you can pass a function with "use server" inside of it to make an inline React Server Action.
server side components/functions scares me a lot. They can be "packaged" but how distributed? With api you have much control over the tech stack and the infrastructure (load balancing, performance, etc), with this you have to add an additional component on the infrastructure, idk, i'm an old guy. Dom components, on the other hand, are amazing. Thanks for this
Normally when you build the app, the bundler gathers all the modules into a giant JS bundle that is put in the client. With the Server Functions flag enabled, the bundler does the same, but it converts all "use server" modules into relative fetch requests to a server (/_flight/foobar.tsx). The bundler does another pass to make the Node.js server. It does this by bundling all the "use server" files as entry points. Finally, we add a virtual API route at `app/_flight/[...rsc]+api.ts` which redirects the generated requests to the associated server functions.
There are a bunch of other minor things wrapping this system to enable serializing arguments, error handling, and streaming, but mostly the magic is just in this little bundling maneuver.
The result is two JS dist folders (just like the web)-one for client, and another for the server. The bundling operation is actually identical across web and native (this was hard to do both worth it) so it's not especially more complicated than web dev-which is objectively the easiest way to build frontends.
I'm confident that we can automate this so much that you don't even notice the server part. As I've been using it over the last year, my fear has shifted from servers/unknown to the idea of just how much code I was packaging offline and exposing to the client. It's freeing to just fetch data and authenticate with secrets without worrying about having to do crazy things like hiding secrets in secure store on-device or setup short-lived implicit auth to circumvent a proxy server. But a healthy amount of skepticism is encouraged, try it yourself before taking my word for it!
@@Baconbrixnice
If server components are not bundled in app package, this will be a game changer for securing API keys. Also the dom components are amazing 🤩
Expo should focus on mobile. Mobile doesn't need Server Rendering at all. For web, Next is doing great.
Nice, how is the process to deploy that ? With server functions and so on ?
Mind-blowing! Do you know what the PHP community has in common with React Native's? We love to improve and contribute! Expo is just what React Native always needed!
i saw PHP and i thought you were about to make a joke, glad to be wrong lol
The client, server, dom folders inside the components folder makes sense.
This is amazing but I have a question, where in the world is the server? Isn’t this a mobile device? Are we calling back to an expo cloud server?
Exactly, I've the same question. Is it like a full stack thing like Nextjs does on top of react?
@@sanketgawande3667word. I’ll have to take some time to read about this. It makes sense with nextjs since you are pushing up a whole server to run the app. This is a mobile app so I don’t get it. Is the mobile device the server? Loo
Where does it get hosted at? I can't understand where is the "server"
You can read Evan Bacon's explanation in the comments but ultimately the server files generated (in a dedicated folder) can be hosted on any backend platform or infrastructure that supports Node.js.
I guess that if the code is updated, both the application (client) and server components would need to be updated to remain in sync, otherwise the client may make requests to server functions (/_flight/foobar.tsx) that no longer exist or behave differently, leading to errors.
Interested to see how Expo will deal with the hosting side of things. It would be nice to see this better integrated with Vercel, in the same way Next.js is: just a single click, and you have everything hosted for your web/mobile app.
Where is the server hosted?
so all this stuff is used just in a web app created using react-native, if im just building a mobile application only, i dont need to use those features, am i right?
what's the name of theme you use on VS-code?
So if i understood correctly, i could have a node backend which is hosted separately and provides react native UI. Lets say we have an endpoint /products/xyz. On the Mobile Side of things we could just call the endpoint and the server (my hosted backend) would give me the UI.
so whenever i want to change the UI i could just update the backend endpoint styling for example and it would be instantly rolled out ?
What about using something as prisma or drizzle? Would that be possible?
it will be nice!
now if we generate for example an apk, how the server component will be compiled, or the SRCs will be extracted how a bakend which must be hosted separately please,
Can anyone explain me in simple terms, what is the use of server components in expo?
Is expo good for production in play store or use RN ???
Can expo just stick to Mobile?
Day 1 asking for how to create an npm package for Expo, test it locally, and then publish it on npm?
Can we update app from server
It’s called expo-updates and yes. But with RSC you can do that without any real update process
Is it works in web
hey, is this guy who was taking he was not a huge fun of react native?)