Last time we tried to use React Server Component libraries (npm packages) they didn’t work. So probably still don’t.
are you setting the react-server condition anywhere? i think i had an issue where i was applying the condition to user code but not external packages or my react overrides. that was in webpack though
(easiest way to check is npm i server-only and then import 'server-only'; in RSC code. if that works you’re good)
idk your setup, but if you’re running Vite over RSC code (from a quick look, I think I saw a rscIndexPlugin() somewhere?) then you probably need to tell Vite to use that condition too – that obv affects how it’ll resolve imports of things like server-only
@lubieowoce You were right all along. There’s a bug with Vite where it doesn’t care about the conditions (like react-server) that you pass into it when SSR loading modules
Some exciting new developments! Redwood now supports React Server Functions aka React Server Actions
Server Functions is a way for client components to directly call functions on the server. For this to work the server function needs to be placed in a separate file with a 'use server' directive at the top.
It can look like this
'use server'
// module state on server
let counter = 0
export const getCounter = () => counter
export const increment = () => {
counter += 1
}
Note that this is just a simple example - not best-practice. counter will be shared by everyone!
Pressing “Increment server counter” in the client component will update counter on the server and re-render the page.
I’ve you’ve tried Server Actions in Next you should know that the RW implementation is still very limited. For example you can’t yet add use server inside a function to make it a server action. You can only make an entire file a “React Server Functions-file”.
Redwood’s RSC implementation now supports using React Server Functions/Server Actions as form actions. I.e. <form action={onSendServerAction()}>. I’ve also made it support importing npm packages that have react components that uses the 'use client' directive.
Here’s a video demonstrating both those features by calling ChatGTP to build an AI chatbot:
I’ve created a bunch of demo repos for RSCs, including the AI chatbot one from the post above (do note that you need to add your own OpenAI API key to .env for that one to work)
Here’s a nice temporary workaround for using Tailwind. You get it from their CDN, but can still extend it and even use @apply to create your own composite classes. This goes into the <head> of web/src/index.html:
The downside is that you’re downloading 110KB of CSS, essentially all of the Tailwind classes and definitions, even though your site may only use a very small subset of those (Spoke’s index.css is 21KB).
But, the index.js file alone for our current build is 600KB, so in the grand scheme of things it’s not so bad!
Not quite as simple as just pointing to a CDN, but a better way to do this would be to use the Tailwind CLI to generate a minified build just for your project and use that build instead of the huge generic one.
npx tailwindcss -o tw-build.css --minify
And then you can just include that like any other css file in your index.html file
Hmm I thought you needed an input file and then it digested that to create the output. Do I just need the tailwind.config.js to let it know where to search for class names then?
And we’ve created a new section of the Forum for all ongoing conversation about the Bighorn development epoch. (Read more about what Bighorn means in the blog post linked above.)
After reading the blog post I’m wondering, how refetching will work - if there’s a plan for that (as we traditionally use query for that, but they are gone now
I guess that might be part of the server action milestone?
Good question. Since Redwood “Classic” (aka Redwood with GraphQL) relied on Apollo Client to do lots (fetching, refetching, error handling, state management, caching) I expect one will have to find some similar solutions for each in the new sever-cell world.