00:00:02.960
all right recording is started perfect H hi everyone thanks so much for coming so as Matt said this is something that uh
00:00:09.360
it's been almost a year in the making uh was an idea that yeah that was sparked
00:00:15.360
uh almost a year ago we did the little demo at the hackathon and since then I've still been toying with it and
00:00:21.119
trying to make it uh more and more usable and and trying to understand better as well everything that's
00:00:26.480
happening under the hood so the presentation today is sort of the culmination of all that and trying to
00:00:31.880
share this knowledge with all of you because I think there's something in there that could be really interesting for the future of development in
00:00:37.760
rails uh so let's start first with a quick survey of the room trying to get an idea of who I'm talking to here so
00:00:45.160
what who of you uh are using rails on a regular basis all right big number cool what
00:00:53.399
about react also a huge number all right so there's a lot of companies that are
00:00:58.600
using uh rea I think that shows that's good react and rails work well today uh
00:01:05.119
but there's also this new kit on the Block hot wire the new uh oneperson framework approach that rails is pushing
00:01:10.680
forwards are any of you using hot wire also on a regular basis one two and a half all right H
00:01:19.000
good well if you're one of those people you might feel something like this and hopefully my clicker is
00:01:28.720
working no
00:01:37.680
uh I'll try to get it working but uh yeah you might feel something like this so this is a a quick meme I found um and
00:01:45.719
uh and yeah like reactor so 2022 right then 2023 rails released a rail 7 I
00:01:52.200
thought hot water came out to 202 oh my God maybe uh kind of like that means
00:01:58.039
though yeah it was set as the default ra 7 I think if I remember correctly and so it gained a lot of adoption at least in
00:02:04.640
last year and and a bit more and yeah clearly like uh there's a lot of uh interest in this right because you
00:02:11.680
there's a lot of benefits right you don't need to know react um you can develop faster you don't need um a new
00:02:19.280
data fetching layer but I'll get into that but I want to talk about I think my clicker isn't working so what I want to
00:02:26.599
talk about is um that I think there's still a place for react in the development world right yes you maybe
00:02:32.440
you can go faster with Hotwire but Hotwire isn't Hotwire and similar Solutions right like HDMX and things
00:02:38.519
like that there aren't they aren't particularly well suited to um like what I would call front-end applications
00:02:45.319
right not just a web page but an application that has a ton of state and UI management and that has a just a
00:02:51.840
complicated set of features that um uh that it needs to support and for those
00:02:57.959
purposes I still still think that react is King so some of the the pros that I think still makes react a winner in some
00:03:05.239
cases I think it's a sort of a decision you have to take on a pro project basis
00:03:11.159
is uh well first of all that it might just be already built into your company and your code base you might have a team
00:03:16.760
that's already proficient that react and is using it daily you don't want to refactor all your code refactor Your
00:03:23.519
Design system to something completely different that would be way too big of an undertaking and then what I mentioned is
00:03:30.360
that react is still king of ux uh you can do everything through Hotwire but you might need to put a little more
00:03:36.640
effort when you want to just get the experience just the way you want it and
00:03:41.799
finally arguably it's also an easier development mental model especially if you have a complicated UI H then uh this
00:03:49.599
notion of UI is a function of state where the whole UI is defined from the state is something that's very
00:03:54.680
convenient yes Andy I agree with the arguably because e is way simpler than we actually
00:04:00.239
yeah and like hot wire idea wire other thing I wanted to say king of ux is
00:04:05.519
becoming disputed now I presented last month GL DSL for web which lets you use Ruby in the front end and half the code
00:04:12.120
you to react in Ruby instead check it out guys yeah so interesting H and yeah
00:04:19.120
like I think you know uh every technology has a specific like there's going to be pros and cons to everything
00:04:25.360
and I don't think there's one king for all projects I think at the end of the day you need to take the right right decision for whatever you're building
00:04:31.680
and react I still believe is one of the the good options today um but it comes
00:04:36.840
with some downsides so you if you've been working with rails as many of sorry react on Rails as many of you have been
00:04:42.639
uh as said have said that you do then you might have noticed that you know yeah there's slower development you need
00:04:48.800
this extra data fetching API often graph sometimes rest and on top of that you
00:04:54.840
also have slower page loads right so you need um there's this extra round trip
00:05:00.280
request that needs to go from the client to the server to fetch the data and so you might get into this sort of uh
00:05:06.600
spinner hell that you might have noticed on some react Pages where you start loading the page and then there's a
00:05:12.320
bunch of spinners that are waiting for data to fetch and then once that's fetched maybe it loads components that
00:05:17.520
also themselves need to go fetch more data and you get into this U what they call data fetching waterfall problem and
00:05:24.960
finally of course it's larger JavaScript bundles which might lead to also a slower uh page load time so just to
00:05:33.800
exemplify the the waterfall problem I'm gonna use this type of diagram a lot today to to go over um the pros and cons
00:05:40.680
of different approaches so the server sends the client the initial web page
00:05:46.360
and JavaScript bundle the the then the JavaScript bundle once it's loaded that means react
00:05:52.080
is loaded and it's able to render the page and then there's that roundtrip request to go fetch the data and then
00:05:57.400
render that finally so that's the situation today and the this presentation what I want to go over with
00:06:03.720
you is like just try to figure out how we could make this better how could we make this closer to uh Hotwire HDMX
00:06:11.639
while keeping the developer experience also great and uh and Isa fuse
00:06:17.639
yeah so when I see this the first thing I think about is you know let's try to
00:06:23.599
remove the round trip right why not just fetch the data directly at the start and send that straight to the to the the
00:06:29.759
front end on the first request and we can do that oh I hope
00:06:34.840
you're sitting close enough for the small code I apologize um and we can do that and today this is already supported
00:06:41.199
in in most uh react Integrations in rails so what I'm showing at the top here is the Erb file the template where
00:06:47.840
there's a helper method in this case called react component where you can specify the react component you want to
00:06:53.599
render on the front end so from the back end you can already specify what you want to render and pass it the props
00:07:00.319
that it needs so you can already pass it all the data it needs technically and um just to give you an
00:07:06.720
idea of how this might be implemented under the hood usually you'd use a gem for this but under the hood it might
00:07:12.080
look something like this where the helper gets replaced by this sort of template div that contains you know data
00:07:20.000
attributes that specify what's the react component you want to render what are its props and then there's a little
00:07:26.280
JavaScript piece of code that can run and dynamically load the right react class and pass it to props and render
00:07:33.840
that all right so just quickly go over this pseudo code completely untested by the way but um you know you get the this
00:07:42.440
element you'd get the class that you need to load and import that dynamically
00:07:47.599
and then parse the props and create the component and render that in the root that you uh that you've
00:07:55.639
instantiated okay and now great we've already solved the problem there's no more
00:08:01.080
waterfall but there's a key cost here that's kind of hidden and not shown in this diagram uh the talked earlier that
00:08:08.080
we still want to maintain the developer experience and speed of development well there's something here that's going to
00:08:13.800
be very annoying and so if I show you for example what the entry point component might look like that kind of
00:08:20.199
that can give you an idea a better idea of where that problem lies so here's a an example page and the
00:08:27.400
entry point component I might use a card from your design system some HTML elements like the header and then have
00:08:34.560
some sub react components used as well in this case I just use the body and
00:08:40.039
footer um and keep in mind you know those body and footer components are themselves going to have many children
00:08:46.080
of other react components and you're going to quickly get into uh a very huge tree of components that need to be
00:08:52.720
rendered but the problem here comes from the fact that the props that you're passing from the server well they need
00:08:58.680
to be distributed around to all of the specific react components on the front end that need specific data points for
00:09:05.120
them to render the correct thing and so you run into this situation where from the back end you need to know not just
00:09:13.519
all the data you need to render but also format it in a way that the front end can distribute it to all the right
00:09:18.880
components and then on the front end you get stuck with this problem of Distributing all of that so you end up
00:09:24.760
with a prop drilling problem commonly called where you know you keep having having to redistribute the props and
00:09:30.920
then pass them down to their children with themselves who themselves have to also pass it down to their children yeah
00:09:37.680
curious are you a fan of using react context to solve this problem uh or part of the
00:09:44.959
problem I personally I don't know if I'm a fan it depends on the situation here
00:09:50.120
it's I don't think it would solve the problem right like You' still need to
00:09:55.519
come up with the common structure of the data that the front end and the back would agree on to as to where you go and
00:10:02.440
get that I the problem pass like having pull it from the
00:10:09.079
context yeah it would it would definitely solve the problem of like having to explicitly pass it but then
00:10:14.360
you still need to know where to go look for that data so the components aren't as reusable anymore because they need to
00:10:20.640
know exactly at what key they need to go yeah um but yeah I mean at least you can
00:10:28.320
clean up the code a little bit let's say yeah um yeah so so this is what this might
00:10:34.880
look like and so is there a way that we could make this better is there a way you know we want each component to be
00:10:41.279
able to know to to to have all of its data that it's need that it needs but the back end would like to maybe
00:10:49.200
directly pass the props to what to the comp sorry to the front end components that need them and so we can come up
00:10:56.320
with a sort of pseudo code that could look something like this maybe we could you know in our view instead of
00:11:02.079
rendering one entry point component start thinking about rendering a whole tree of react components and so here I'm
00:11:09.279
reproducing the entry point but in the view and the react component helper now
00:11:14.360
I'm I'm uh kind of imagining that it can support a block argument where you can
00:11:20.160
pass children that is not the case of any reacton rail gems that I know of today but theoretically that's possible
00:11:28.279
and you could so this way specify a whole structure of the the the page you
00:11:33.720
want to render like the whole react Tre that you want to render and now your props well you can specify directly the
00:11:40.519
props that each component needs right and you could even you know think about
00:11:46.320
making a backend notion of a component as a model that knows exactly the react component it's rendering the props it
00:11:52.600
needs and it could take care of data fetching for that you could come up with a whole framework around
00:11:57.680
that and so just to show you that this could work we could do uh let me show you what the the what this um template
00:12:06.200
might render down to so we have the similar template like divs used this template at the at the top here so we
00:12:13.639
have the react card with the same children and here notice we're using other like templates within that or
00:12:20.560
specifying the body and the photo components and then the only difference in the code is that now we can iterate
00:12:26.560
over the children of the component we're looking at and for any of those uh import the right react component pass
00:12:33.160
this props and basically we're rebuilding the jsx tree in this little bit of JavaScript so again skip some
00:12:40.680
Corners here not handling correctly the like uh the Dom node for H1 but you can imagine how this could
00:12:49.639
work all right and so we have this great situation now where the there's no more
00:12:57.120
um extra roundtrip the database queries are all done at the start all the data is sent to the client and uh you try it
00:13:04.800
in production and you well you get users that are a bit like this I'm going to take this moment to
00:13:11.240
take a sip of
00:13:17.720
water so what happened well we didn't really think
00:13:23.600
about this scenario right like what happens if your props like all the database queries that need to happen to
00:13:29.440
fetch all the data take a while and even if they don't take a while now your client your users still have to wait for
00:13:36.480
the entire time that all the data needs to be fetched before they see something on the page so the first content full
00:13:42.519
paint is happening much later than before right and just to show you let's compare that to what the situation was U
00:13:49.800
with the traditional react on Rails approach right so the first content full paint happened as soon as we had uh
00:13:57.519
react starting to render on the front end we didn't need the all the database queries because that happened in a
00:14:03.279
separate API column so at least the user had some initial feedback and knew that something was going on they didn't have
00:14:09.680
to you know wonder if the page was even working at
00:14:14.759
all so um let's think about how to solve that problem but first I want to take a
00:14:20.959
step back and uh revisit the format that we've been using to pass down this this
00:14:26.839
jsx template that we want to render on the front end so right now like the lat latest version
00:14:32.360
we had was something like this where we were using HTML to Nest a bunch of
00:14:38.079
placeholders to to to be used to identify which of those are react components and how they should be
00:14:43.759
rendered but we could just as well use Jason for this and it's going to make our data parsing or the parsing of this
00:14:49.920
structure much easier in the future and so let's switch over to Jason just for the the sake of this
00:14:55.920
demo so we can have the same uh component represent the same jsx tree as a Json where you have a root component
00:15:02.839
the card it has some children and each children can have you know is also a
00:15:08.199
component in itself and has some props optionally so we have the same data
00:15:14.240
definition we can do the same thing and send that you know through our Erb
00:15:19.399
template for example we could just send that as Json that we store in a little JavaScript variable we process this
00:15:26.040
thing the same way as before or the same way without the the Dom uh manipulation or the Dom
00:15:32.319
lookups and but basically it could be a just a different approach to passing the
00:15:37.560
data from the back end all right so let's Circle back to
00:15:42.600
the the slowness problem of the data fetching let's say that in our example it's the body component the props sorry
00:15:49.399
for the body component that are very slow to load what we could do is instead just
00:15:54.959
maybe not show the body component right maybe we wait we wait until we have the right data so we could put a placeholder
00:16:02.079
instead and just say look look front end wait for it I will get you what ever
00:16:07.399
needs to go there but for now just keep in mind there will be something that goes there and then the second key idea
00:16:13.959
is that we could change this format into something that's streamed from the
00:16:19.360
server so our server would initially send this but then as soon as the data
00:16:24.680
is ready as soon as the placeholder is ready to be replaced then we keep adding some more lines to the stream uh that
00:16:31.360
contain whatever needs to go and replace that placeholder so it might look something like this so first we get the first
00:16:38.240
block and then a few seconds later we send out another block containing what needs to be rendered with the ID that
00:16:44.160
references where that needs to
00:16:49.399
go and so now the only question is how do we actually render that on the front end and that's a a tricky one so let me
00:16:56.560
actually go back um the first part we've done right that that that works and the
00:17:01.800
placeholder we can just skip or put a a a empty div if we want to but how do we
00:17:09.079
after react has rendered something how do we go and hook into the render process to add something that was
00:17:15.319
initially missing that's actually very tricky to do in react right like that having this interaction with react from
00:17:21.559
outside react World is pretty tricky it's possible but not uh super
00:17:26.799
convenient to do but fortunately with react's next release of server components um they have an API to do
00:17:34.080
just that and it's called create from readable stream with create from readable stream
00:17:40.520
you can pass a data stream directly to that function it expects a specific format which we'll get into but it can
00:17:47.960
then render that content directly in the jsx and uh even do some nice things for
00:17:53.640
us like it will actually be integrated with the react renderer and we'll see uh in a few slides like some some of the
00:17:59.080
benefits of them um but the only thing we need to get this working is basically to use uh
00:18:05.960
so to pass the data stream in the right format so react expects a specific format as you can expect to know how it
00:18:12.039
needs to render the react components using this method and so we had our Json format
00:18:19.559
this is the actual react format well actually it's the sorry the one of the previous versions of what this wire
00:18:26.039
format looked like since I built those slides the the for the the format that slain slightly but is still very
00:18:32.760
similar um and so this is very close to our Json approach uh you'll notice that
00:18:38.120
our block here of line zero is the main content that we're that we're trying to send so uh with a few different a few
00:18:46.960
differences right so first of all the first two lines are indicating where to
00:18:52.400
load certain uh react components and what files are they and what chunks are they if you're using Webb and it's
00:18:58.880
chunking your JavaScript and at what import name are they this is something that I kind of skipped over in the
00:19:05.080
previous implementations but it would have also been required to be able to to implement any of the previous uh little
00:19:11.320
scripts that I showed uh and so this zero block being our main uh body or main uh sorry page
00:19:18.520
that we're trying to render is first referencing line one uh and it's so it's
00:19:24.400
saying okay this is a first of all a card component that has props here the props would
00:19:31.320
actually be expanded we can imagine that you might have you might be passing some data here and then it has children and
00:19:38.400
in the children same as before we have our H1 header with its title we have our placeholder same as
00:19:46.120
before we just put a an ID reference and finally we have our footer which itself is also a frontend
00:19:52.840
component so it needs to refer to the line where we defined that and it has its own props and then This is highly
00:19:59.240
streamable right the idea behind using this and not Json is basically just that it's a little more compact so you're
00:20:05.240
going to send a little less data over the wire um and you can stream this the
00:20:11.200
same way as we talked before where after a few seconds you you know keep the connection open from the server and once
00:20:16.880
your data is ready stream the final part so in this case the uh last body
00:20:22.120
component and its props and this will work directly with this create from readable stream react
00:20:30.240
API and now well now their picture is looking much better so now that means
00:20:36.039
you can have your front end which right from the start is getting
00:20:41.960
this initial payload with the placeholders so it renders really quickly and you get a first contentful pane that gets uh quickly into the the
00:20:49.520
eyes of the users while in the background your server has already started doing all the database all the data fetching from the
00:20:55.840
database all those slow queries are already running and only once they're ready they get streamed to the the front
00:21:01.679
end and you get to render um and and they render as soon as as soon as that's
00:21:08.640
ready oh yes sorry so you have two reg
00:21:15.159
Parts cont the sh aeton layout yeah in
00:21:20.240
this case the naming is a bit confusing but imagine the shell being like the the jsx tree we sent with the placeholders
00:21:27.400
and then content is once we have everything Final in practice though with this structure you can actually send data in
00:21:35.679
in pieces right you can have many placeholders and each of them can be streamed as soon as they're ready so you
00:21:40.919
might have like multiple different arrows that come in from the data from the from the back end as soon as that's
00:21:46.320
ready you keep rendering a bit more when you're rering the
00:21:52.559
sh um is there Reflow that's produced once uh the content loads in
00:22:00.120
uh yeah exactly yeah so that's one of the challenges we'll tackle in a minute but yes definitely like that uh
00:22:06.039
placeholder that we put right now is nothing so once you add the thing in is going to make everything jump in the
00:22:11.799
page and that might lead to a bad user experience I think that's actually my next slide yeah so what do we show while
00:22:18.440
the elements load right um because again we would have that jumping
00:22:25.320
problem well react has an aply named suspense API just for this uh you can
00:22:31.679
wrap your elements in suspense provide a fallback the fallback is what's going to
00:22:36.799
be rendered until every children of this has done loading and uh now you can specify for
00:22:43.480
example a skeleton so that your page doesn't jump right or just a big loading spinner
00:22:49.760
yeah yes correct but the nice thing about using Creed from readable stream
00:22:55.000
is that since it integrates directly in the react renderer while it supports suspense as well so all those placeholders are directly supported and
00:23:02.120
will be able to make use of suspense and show the fall back until the the placeholder has been replaced by the
00:23:08.080
actual content you want and uh yeah so just to show you an
00:23:14.320
example of how suspense might be used in jsx so in the our entry point component you would put it just to wrap uh
00:23:20.600
whatever you want to to show a fallback instead so in our case maybe just a body but note that we could also hide the
00:23:27.279
entire page if we wanted to until the the body is loaded and in our case we can show like a spinner from our design
00:23:34.000
system component let's say and uh that will be the placeholder until the data
00:23:39.360
is loaded and all we need to do now is specify the suspense as part of our our
00:23:46.520
tree so we just need to adjust so that this change is reflected as well in the data we sent from the back end and so
00:23:53.559
our wire format is changed slightly uh our children of the main block now have
00:23:59.120
a the the L3 reference to suspense here suspense being just a sort of constant
00:24:04.799
string I don't know exactly why they pick that in the format and uh it specifies the fallback as a prop right
00:24:11.120
here which is itself a reference to another uh front end component called spinner and it sells and the children is
00:24:18.440
where we put the placeholder for what we want to um to load
00:24:23.840
later and so basically the the whole conclusion of this is that you know to make react server components work in
00:24:30.200
rails all we need to do is replicate their Warrior format replicate that streaming format that I just showed so
00:24:36.120
we need a way to go from a definition of the components on the back end render that down to this format support
00:24:43.159
streaming so that we can add lines as soon as the data is all loaded and Bob's
00:24:48.640
your uncle you plug that in to create from a readable stream on the front end and you got a A working version of this
00:24:55.640
yeah yes Andy question format that just showed us for theable
00:25:01.320
data yeah so that comes from the react server component standard exactly yeah
00:25:06.760
unfortunately they have very very little documentation about this format which is um a bit sad because I it kind of feels
00:25:14.440
like they're they're locking this into just a nodejs backend World um but there
00:25:20.640
is starting to be more and more documentation more people digging in of course the source the source code is also open source um so it is possible to
00:25:28.320
replicate this and I'm hoping to see more efforts from the community as well in the future for that uh so I went ahead and tried it out
00:25:37.640
and that's like what we started at the hackathon last year over the last uh over the last year I've been refining the code a little bit just show you uh
00:25:45.159
something working in this so I'll jump over to the demo and uh yeah just show you an idea of like what this might look
00:25:51.440
like from a user perspective but also from a software developer perspective
00:26:23.720
all right one second your life
00:26:36.960
all right I think we're good to go all right so this is the um the react note demo actually this is a demo that the
00:26:43.440
react team themselves built for showcasing uh server components and what
00:26:48.520
I did is I took the demo and reimplemented all the backend and rails but the front end is basically the
00:26:55.799
same so if I refresh the page you'll see uh well okay that was a bit
00:27:02.360
too quick I think a lot of stuff was cached but it's also running on my Local Host uh so there's not too much to see
00:27:08.520
but just to show you some functionalities of the app it's a note taking app you can click on the notes to see what's happening but the contents
00:27:16.399
you can edit and uh change what you want you get a preview on the right that updates in
00:27:22.760
real time and when you're done you can save everything you can also search
00:27:29.159
and you can create new notes but I'll skip that for now so this is basically the the simple app and uh just to show
00:27:35.360
you the so this is all running with in with a a rails backend but just to show you the streaming aspect of this I'm
00:27:41.600
going to slow down artificially what happens when we load a a single note I'm
00:27:46.919
going to go back in the code and just put a sleep of two seconds in here and
00:27:52.880
uh me refresh the page just in case and now if I click this note you'll see the
00:27:58.360
than I was talking about so we're using the suspense to show a fallback and uh
00:28:03.799
and yeah and I can show you in the uh in
00:28:08.840
the inspect tab the network what's happening
00:28:13.960
here and so you'll
00:28:20.000
see just move this so it's a bit more
00:28:25.240
convenient well this is not working well at all on my laptop okay um sorry about that you're
00:28:32.799
not going to see much of the the stuff on the left Ah that's why I probably was
00:28:38.480
on a bigger screen right before okay um there we go so there's the initial
00:28:45.640
page load in this demo I'm cheating a little bit um the streaming format isn't
00:28:51.159
sent with the first page load it's actually a separate API call that the front end makes to get the data so we
00:28:57.600
are back to the the round trip problem I swear this is just temporary and this is
00:29:02.640
actually to match the server components demo that reacted they also do the same thing uh it makes this much easier if
00:29:09.200
you want to stream the data D directly with the first page load you have to embed that into the HTML um and so you
00:29:15.600
might have to use a like a an open-ended HTML that at the HTML page that at the
00:29:22.200
end you keep adding like script tags that keep pushing data into an array or something like that a little more
00:29:27.399
complicated this makes it just a bit easier but it is possible to also send it with the first page Lo and so this uh
00:29:34.720
first page uses the wire format so you can see here the the response I hope this is visible sorry for the small
00:29:41.840
screen yeah how about that yeah perfect so uh so our our API
00:29:51.000
that Returns the streaming format you can see it's working and if I click on a
00:29:56.080
note here
00:30:01.720
uh I do not see it there we go uh so it streamed the
00:30:08.720
data what I'll do is I'll go over and copy this to curl just so you can see the streaming
00:30:17.200
happening and so if I launch the same query you'll see uh we kind of stopped
00:30:23.440
here around this line this was the the main like block starting with z
00:30:31.600
and uh and then the final content loaded so after after this stuff here it took a
00:30:36.760
couple seconds and then we finally got the rest uh the rest being in this case the the content that would replace the
00:30:44.279
the Skeleton on the right and um yeah to show you a little
00:30:50.360
bit more about how this looks like from a developer perspective let me show you a bit of the code uh so to render this
00:30:59.080
wiio format we first need to define the the tree of react components and HTML
00:31:04.840
elements that we want to render um so I decided to go with an approach for this
00:31:10.760
based on Flex uh it's not the Erb like we've been doing since the started this
00:31:15.799
presentation just because I would have needed to parse HTML to then render it this wire format not as straightforward
00:31:22.720
using Flex is a bit easier it's all ruby and I can hook into the the methods to render it exactly how I want
00:31:29.240
to um so just to show you the main app so with flex you have a template method
00:31:34.919
in which you define uh like all the HTML elements you want to render and um and
00:31:41.080
in this case the only key difference is that you can render as well front end component so here you'll notice the
00:31:47.720
search field and the edit button are actually front end components yes Andy I just wanted to mention Flex is about two
00:31:53.679
years old but it's component structure and uh um API is almost exactly lifted
00:32:00.639
from glimmer originally glimmer it was created in 2007 the desktop version of
00:32:05.760
glimmer and glimmer copied something else it copied shoes and Mer copy uh so
00:32:11.440
Flex kind of copied almost exactly the same DSL glimmer so what you're showing
00:32:16.600
us here is very similar to glimmer DSL awesome great to know so yeah it could
00:32:21.720
make even an implementation of this with the glimmer DSL that renders down to this wi format um
00:32:28.480
and so the developer experience is pretty much the same as um as a regular Erb template but on top of that you now
00:32:35.000
get an easier way to specify front end components and um and the second new thing is this
00:32:43.120
suspense notion right so you can wrap some certain parts of your code in
00:32:48.240
suspense specify a fallback and then you can render um some
00:32:54.519
components that might take a while to do data loading in this case the noteless comp component I can show you which is which we specify as an
00:33:02.039
async render type of component this is just the little flag that we use to identify that and um and with this async
00:33:10.039
render what's what that's going to do is Once We Run The render method for this
00:33:15.120
component we're going to spin that off into a new fiber render the code asynchronously and only when it's ready
00:33:22.159
stream back the data to the through the uh the stream that's been open
00:33:28.000
but yeah um any questions about the code before I go back to the final points of the presentation is there anything specific you'd like to see uh or
00:33:35.320
something you think I forgot to demo also
00:33:43.679
possible yeah I'm confused though when should we use R like uh react components
00:33:51.360
pure of R foral and when should use for example sections and include like style
00:33:57.559
stuff because looking at first for me I'm confused of uh where we are separating
00:34:03.799
the layers of what would be like in the rugby what should be only react yeah
00:34:09.399
that's a really good question actually um this might be a new problem and a new
00:34:16.079
question that like needs some standards and conventions in our code bases but it's a good problem to have because now
00:34:21.560
you can decide how much of the rendering do you want to happen on the back end versus on the front end and you can do
00:34:27.960
do this on a per component level right I can turn this section into a a frontend
00:34:34.280
component and nothing's changed in my code right uh like I um H like you want
00:34:40.919
to add interactivity somewhere okay just move that component to the front end and you're good to go of course the react
00:34:47.159
implementation is a little nicer there in the sense that you don't need to rewrite your Ruby code into JavaScript
00:34:53.200
you it's still the JavaScript with react and if you move it to the front end you get access to
00:34:58.359
State and hooks right um but transferring from this format to uh to
00:35:04.079
the front end is also not that bad and you can still do a split of like having a a back end that is that takes care of
00:35:10.480
all the data fetching like a component for data fetching and then a component for rendering and user interactivity and
00:35:16.400
that would still work within this framework like you're on the on the on this definition here right you can have
00:35:22.359
your section that fetches the data and passes it down to the front end component to render it there is a super
00:35:28.640
flexibility side um all right so let me jump back to
00:35:34.320
the presentation real quick I'm GNA just share my screen once
00:35:39.760
more I think it's GNA be
00:35:54.079
easier okay all right uh so what is this react
00:35:59.800
server components feature then right so we've seen today that it's pretty much just this specification of the streaming
00:36:06.119
format that we saw and on top of that it's an API on the front end to take that definition to take that stream and
00:36:12.680
render that to the jsx tree it's also on the back end an API to
00:36:19.520
render um so backend react components or components that don't use state in
00:36:25.800
certain other hooks down to this wire format down to this streaming format um so in this sense it's
00:36:34.839
technically support for rendering JavaScript react components either on the server or on the client or both
00:36:41.119
right uh there's a few catches like so the the use States stuff like that and on this on the server you can use async
00:36:47.920
components and do data fetching directly from your database so there's maybe even an argument that like having them in
00:36:54.119
separate languages is a bit clearer you don't risk trying to do database fetching from the front end which
00:36:59.400
wouldn't work anyway but you know you don't risk uh injecting a secret key uh
00:37:04.520
in in a front end component for example Andy I disagree with that I think it developers would be a lot more
00:37:10.280
productive if it was one language on the server and the client because I used to program apps that were client server
00:37:16.680
before the internet started and that was a lot more Collective than the waste of time that
00:37:22.200
we have nowadays with four or five different languages but but what you're showing is very interested keep
00:37:28.359
sorry yeah know it's super interesting I think actually you know the like most of
00:37:33.640
the logic you're going to have is going to be around data fetching or around uh like frontend State and interactivity so
00:37:40.560
these are already things that have to be either on the front end or the back end right they can't like you can't do the
00:37:46.480
data fetching on the front end you can't do the uh user interactivity on the back end as much and so given that the stuff
00:37:54.079
that actually needs to transfer between front end and back end component for me is just this simple definition of like
00:38:00.520
hierarchy of components and that is easy to transfer there's a bit more logic obviously but I think it's a it might be
00:38:07.760
a worthwhile tradeoff and then my final Point here is that it's also pretty Bare Bones right
00:38:13.560
it leaves a lot of choice for framework creators and we had to dig pretty deep into the internals to figure out all
00:38:19.720
that stuff right and that's because actually react has decided to position themselves now as a what they call a
00:38:25.599
meta framework uh on official documentation for the next release they don't recommend you use react directly
00:38:32.720
they don't recommend you use the LI directly they recommend you use a framework that is set up to use react
00:38:38.240
and set up all the stuff around server components for you because there's a lot of stuff to worry about and this demo
00:38:44.160
like it was the simple part of that but then there's a bunch more about race conditions what happens if your stream
00:38:50.400
doesn't load in the right order and then we'll get into SSR in a second of server side rendering there's a lot of
00:38:55.960
complexities around that and it react is arguing that you're better off just leaving that to a full-fledged framework
00:39:02.480
that has already handled all all these edge cases for you the one thing it is not though uh so
00:39:10.480
server components are not server s side rendering and react makes this very clear distinction between the two for me
00:39:17.160
at first I was like what what do you mean they're both they both have like server in the name they for me server
00:39:22.319
components are rendered on the server like you're rendering down this this tree to the streaming format but the
00:39:29.200
distinction that reacts make that react makes is that the um rendering to the
00:39:34.440
streaming format is different than rendering to HTML and that's what they call service side rendering but they
00:39:40.599
also have an API to render the um all the jsx components including the front
00:39:46.960
end ones directly to HTML from the server so that way you're able to send a
00:39:52.960
a first payload to your users that already contains the built HTML so they don't even have have to wait for the
00:39:58.960
initial like uh react rendering on the front end they don't even have to wait for the JavaScript bundle to load and in
00:40:04.839
fact you can combine these two into something like this right now your
00:40:10.160
server can do the server side rendering that's my first step here so send the
00:40:15.599
HTML down to the client directly the client already has uh something visible
00:40:20.680
at that point and then can start downloading the JavaScript and do a process they call hydrating which is
00:40:26.800
just attaching your JavaScript code to the already existing HTML as opposed to rendering it from scratch and in
00:40:34.119
parallel you still have the same process of fetching all your data and streaming that to the front end through react
00:40:40.400
server components and now you get the best of everything where your first content full
00:40:45.720
paint happens really early the page becomes interactive as soon as the JavaScript is loaded and then your final
00:40:51.680
content paints uh it streams in and and keeps painting um as soon as it's ready
00:40:59.680
and so just to Circle back to to the first one of the first slides I had on reacting rails today well what would it
00:41:06.520
look like tomorrow now if we um take into consideration everything I've just presented so the pros stay the same but
00:41:12.800
the cons now well the slow development well now you don't need this data fetching anymore right this graphql API
00:41:20.240
was only used for the front end to have a way to go and query what it needs but now we're passing all that down directly
00:41:26.560
from the back end so we get rid of that and then the slower page load as we saw with the combination of SSR and react
00:41:33.839
server components well you don't need the round trip at all in fact you can even render stuff from the back end
00:41:39.119
directly down to HTML and it's going to be even faster than before and uh the final point the larger
00:41:46.560
about JavaScript bundles that still holds if you want to use react in the front end because you need interactivity
00:41:52.280
you need like all the the the nice methods behind this it is a little smaller though because now you can pick
00:41:58.359
and choose what you render on the front end and on the back end so you might decide to offload some of the stuff to
00:42:03.440
the back end which might also mean you don't need to use uh this specific npm Library anymore and you can just use a
00:42:09.960
ruby gem equivalent or something that's already built into rails yes um I don't
00:42:16.319
remember which Library did this but uh there was one um that I had
00:42:23.520
the being six months a year ago which
00:42:29.079
essentially didn't download any of the um event handler code oh I think I know
00:42:38.160
are you talking about quick is it possible you're talking about quick
00:42:45.200
lar yeah uh so this is a
00:42:50.559
like yeah I that's a good point so so what I've talked today right is about react specifically because react is the
00:42:56.839
first of the big front-end libraries to start implementing this kind of stuff
00:43:02.040
but if this picks up and people like it then I expect a lot more front end libraries to support this kind of thing
00:43:08.720
I think that the library you're talking about is quick I don't know it super well so I don't know if it's really compatible with this this sort of
00:43:15.119
development model that uh um definitely like other libraries and they're also
00:43:20.559
building Frameworks like a solid JS a solid start for example right they might
00:43:25.680
start looking at something like and I used react today but really you
00:43:30.760
could substitute that for anything else if uh if in the future they also add support for you yeah I had a question so
00:43:37.319
you mentioned that we're minimizing or eliminating data fetching API calls that's because now you're relying on
00:43:43.680
streaming for rendering the parts that are not rendered right away correct whereas in the past they got they ended
00:43:49.960
up fetching extra data later Y correct and I believe that was my last
00:44:03.440
everyone just a I guess final words like um I put a slide in there I'll share the
00:44:09.760
slides with everyone in the in the Meetup um I put a slide with references if you're curious about like where I
00:44:15.480
learned about this kind of stuff and um I also put a link to the demo code it's
00:44:21.440
all open source for like the version I built in rails uh if you're looking at interested at contributing go ahead and
00:44:27.599
and reach out I'm not sure how much of how much time I'll have to actually turn this into a framework it's something I'd
00:44:32.720
love to do but we'll see what happens but if you're also interested reach out and we can talk yeah so the problem that
00:44:40.000
you presented we we have it solved in our codebase at my company lexo by basically
00:44:48.400
um we usually pass any uh data that is available right away when we render a
00:44:54.680
page immediately to the react components and then we defer any data that is that
00:45:00.480
needs to be fetched later into the components themselves um and we don't have a problem where like basically the
00:45:08.800
patient will render right away and the components that need extra data will make extra API calls and we haven't had
00:45:14.440
any issues with that to be honest um I mean Vic what do you think do we have any problems with that believe so we
00:45:21.480
have it solved just by simply making the components responsible for whether they
00:45:26.680
want data to be received right away in the params or arguments or whether to make the call inside the component and
00:45:32.720
not render anything as soon as the data comes in it pops up uh so I'm curious is
00:45:38.280
that a solution is that a problem for you guys was that a problem is that is that part of the reason this was
00:45:44.480
created uh initially the app was built as a single page application with a a
00:45:49.520
single page application and uh relying on the design system uh heavily so
00:45:56.119
everything was buil with a basically a placeholder a div fruit and you're done so there wasn't any mixture of some Erv
00:46:04.280
code and some border BL that you could do in rails and then Plug and Play react
00:46:10.319
uh we needed that interface to be I don't know I guess an example would be
00:46:16.079
uh if you're building Gmail right pretty much there's no like individual comp
00:46:22.079
components that you would then later attach together it's the full thing and GMA will have a single spinner on the
00:46:29.200
entire interface our app is build the same way uh five six years ago it was
00:46:35.480
the train but also it fit the use case that we had uh so yeah there's a way
00:46:40.720
that you can build the app and you can have Dynamic components this way and you won't be facing this but if you need the
00:46:47.280
UI interaction to have this extra and you are in a
00:46:53.200
single page ification Paradigm then yeah you kind of SC because you don't have
00:46:58.800
that that possibility uh the the other thing is really the design system that
00:47:05.240
we had we're not CSS based we're like CSS and GS and material UI and other
00:47:11.200
things like this so are we
00:47:17.800
so um so basically anything that you're building needs to be JavaScript based
00:47:24.440
because otherwise there's no design in there's no color there's no nothing and so
00:47:30.280
that's CSS CSS can be apps something else yeah it's where you
00:47:38.920
you're basically the planing the CSS as you know Javas perance so it's two different paradigms
00:47:45.720
you join both of them together and yeah you're not in a world where you can devop a front page uh sorry a front V
00:47:54.559
appication that can with a mix scenario of some
00:48:01.319
backu so you're saying your has like one view
00:48:06.839
which everything there why you make it like
00:48:15.599
AP what you mean AP API it's pretty much it is yeah just
00:48:27.640
and other things
00:48:34.640
are for each entry point yeah okay that's a different I mean we do it
00:48:41.480
different obviously many different ways of doing this the paradig we had in the day we
00:48:49.040
still have today is a user experience that requires this sort of uh of
00:48:54.400
rendering and also that's how we build the design system meaning that the frontend developers had everything
00:49:01.000
available to them in JavaScript um without getting into coding but from a
00:49:06.640
uh hiring perspective it's quite hard to hire Ry devs of the certain seniority
00:49:12.599
that no full stack entirely uh so being able to hire JavaScript typescript
00:49:18.599
developers to concentrate on the front end was also kind of so you you have
00:49:23.799
like a mixture of many decision stats yeah end up costing you 200% the cost
00:49:28.920
you would have built it with Ruby you would have it would have cost you if few used Ruby that's my experience or even
00:49:35.480
400% is Javascript is a
00:49:41.599
disase yeah I mean I really like your back end part that was similar to the glimmer DSL it's a shame you didn't
00:49:47.720
attend my talk last month sorry I online on YouTube it's called frontend Ruby
00:49:53.319
glimmer DSL for web because it has the you have the back end piece of the puzzle solved uh glimmer glimmer has the
00:50:00.960
front end piece solved it would be great to you integrate the two together so I definitely discussed that with you after
00:50:07.520
the talk the front end part of in my opinion nothing intriguing or interesting comes out of react and I
00:50:13.839
didn't think server components were interesting at all in my opinion it was extreme over engineering from what I saw
00:50:21.359
and a lot of the front end code that you showed us is extremely ugly compared to what I showed last month so I mean to me
00:50:27.359
that's like you showed me PHP in 2005 I showed you be on Rails 2005 sorry like
00:50:33.200
that's what I me yeah yeah but what also it's kind of like somebody showing me the first car but I showed them the first rocket the car is nothing you know
00:50:40.119
like compared to it so definitely check out my talk with this is Thinking Inside
00:50:46.160
the Box react or what's common in JS uh what was demonstrated last month was
00:50:51.880
completely outside the box like we complete like a much much simpler solution that ends up shrinking the code
00:50:58.319
half so anyway sounds super cool I'll try to check it out uh just the the the
00:51:04.760
front end actually I didn't really show any front end today right what I showed was like what would be hidden behind a
00:51:10.599
framework or a library uh the front end stays the same old react so if you don't like that you're not going to like that
00:51:15.920
today but um it doesn't change your front end it means that your existing design system can still work and you
00:51:21.720
don't have to change anything about that um and you asked earlier about like uh what problem this solves I think
00:51:30.200
um I think it it's depending on your use case you
00:51:36.799
might actually be running into bottlenecks of performance or um uh like
00:51:42.160
scaling problems that make this kind of solution interesting um I think overall
00:51:48.680
though the main purpose of react server components is more around developer experience it's it is about building
00:51:54.559
this kind of optimized architecture optimize delivery system
00:51:59.960
for the users as easy as possible and in a way where developers can now very
00:52:05.520
easily choose what goes on the back end or the front end and one of my favorite Arguments for this is like uh the
00:52:11.599
ability to collocate everything that's related to one sort of thing or like
00:52:17.079
entity that you're rendering on the front end right now you can collocate the data fetching the JavaScript what
00:52:23.760
the the the you know the data fetching and the component all the rendering all in one place on your back and and um I
00:52:32.319
find that mental model of development very very convenient I'm still not sure
00:52:38.200
if this is the way to go for the future uh I think this is very very new and the communities also seems to be divided
00:52:44.400
there's also a server actions another feature from react that I'm much more on the edge there like as to whether that's
00:52:51.119
actually interesting or not or if that's dangerous um so I think next year is going to be interesting and uh I want to
00:52:58.760
build this because I want to jump in and see what could come out of it and if this is Ruby generates JavaScript code is
00:53:06.520
what you're saying or we have components on front it it actually it just renders to the streaming format that's all it
00:53:12.200
does yeah yeah any other questions yeah probably
00:53:17.720
from the Tes perspective now that you are um I say liberating over streaming
00:53:24.760
uh responses uh how did you deal with testing uh for example because let's say
00:53:32.319
tomorrow you want to make sure that you are rending 50 records from the database and since now you are using a lot of
00:53:38.720
streaming what happens if for one test it will probably get 10 or for the next one when I get 20 uh like have you
00:53:46.119
experienced flak test in the past because of that that's a really good question uh the reality is there are no
00:53:52.599
tests for that demo app uh this was just built to to see if it work Works um there I think I have a couple backend
00:53:59.200
tests just to make sure I can render to the the streaming format but that's about it um so uh this is untested
00:54:06.680
grounds I don't know um I think you could you know fake the streaming which
00:54:11.799
sounds very ugly and inconvenient but if maybe you have some helpers for that could work like you can test your front
00:54:18.680
end by faking the back end then you know at least you're you're starting to get somewhere otherwise uh have a way to dis
00:54:26.599
the async component maybe I'm I'm not sure yeah it's interesting saying from a
00:54:31.680
personal perspective I don't see like depends on the case sure but much like
00:54:38.599
value of testing only the return of the data because in the end we can either do like a system test to check it out use
00:54:45.520
your behavior or if you would like to check the return of the data doesn't need to be from the stream itself can be
00:54:51.839
for a p unit test from a part of the what you would like ref itself so you
00:54:57.920
either checking the data from a service or you can also check the behavior from a system test
00:55:04.920
like ATT tach from the response itself being the data uh yeah I don't know I don't know
00:55:14.319
yeah I mean the the the streaming format is parsable you could have utilities
00:55:19.839
helpers and your rspec test to you know in a request test for example to check that it contains the data you want um um
00:55:27.599
yeah I think that's probably the way i' go do the streaming breakes essentially
00:55:33.160
ja unit testing um or would you still be able to
00:55:38.839
load up component and the props that would be coming in you need to go through
00:55:44.799
streaming because you you mentioned you could fake the stream data that jeez that's like that's unreadable
00:55:53.119
so does it break it or there's still way to uh it depends right I guess like if I
00:55:59.720
was to do uh unit testing on the front end i' render individual components and
00:56:05.839
the streaming would happen outside of that right like the the create for mutable stream method which would be
00:56:12.680
what's problematic would be happening in some sort of uh entry point file right
00:56:17.839
in like the the sort of root JavaScript that's injected by the framework um and
00:56:23.520
so you don't uh for unit testing you just load the component that you need it doesn't
00:56:29.319
care about any streaming you still pass the props just says before right it doesn't change any of that
00:56:34.640
um it's only it's really only if you want to do like more of an endtoend test more of assistant test I think and in
00:56:39.880
that case you also have the back end to complete so
00:56:47.200
yeah all right I guess I'll stop the recording here but feel free to ask me
00:56:52.839
uh more questions uh after come come talk to me I'll stay stay for a bit before leaving and uh thanks very much
00:57:00.720
for coming
