We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

From jQuery to React

00:00

Formale Metadaten

Titel
From jQuery to React
Untertitel
Gradual migration with hybrid approach
Serientitel
Anzahl der Teile
561
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Migration from legacy javascript to react in a well existing project isn't instant or easy, but the outcome will be worth it. How we can combine legacy with a modern front end, surviving the hybrid umbrella, improving application's client and enjoy coding ! The migration process from legacy javascript to react might take you some time and wouldn’t be easy, but the outcome will be worth it. Two years ago, the foreman project decided to adopt react and started a gradual migration process from legacy javascript (rails assets pipeline) into a modern react web app. We’d like to share with you our journey, the do’s and don’ts Why we should adopt react, Where to begin - The first step, How to survive under the hybrid umbrella, Gradual process - is it good enough? Long term goals (does SPA one of them?)
10
58
80
111
137
Vorschaubild
15:21
159
Vorschaubild
18:51
168
Vorschaubild
26:18
213
221
Vorschaubild
15:22
234
Vorschaubild
49:51
248
Vorschaubild
23:06
256
268
283
Vorschaubild
28:38
313
Vorschaubild
1:00:10
318
Vorschaubild
21:35
343
345
Vorschaubild
36:13
353
Vorschaubild
18:44
369
370
373
Vorschaubild
44:37
396
Vorschaubild
28:21
413
Vorschaubild
16:24
439
455
Vorschaubild
25:10
529
Vorschaubild
15:36
535
Vorschaubild
28:04
552
Virtueller ServerHybridrechnerWeb-ApplikationClientOpen SourceTransformation <Mathematik>Ordnung <Mathematik>RenderingCodeBitDatenverwaltungMechanismus-Design-TheoriePhysikalismusZusammenhängender GraphRuby on RailsCASE <Informatik>ZahlenbereichBenutzerbeteiligungMultiplikationsoperatorKartesische KoordinatenRechter WinkelEreignishorizontRoutingProzess <Informatik>Dienst <Informatik>ServerSoftwaretestTermEinfach zusammenhängender RaumCoxeter-GruppeComputeranimation
Ruby on RailsZusammenhängender GraphZentrische StreckungQuick-SortOrdnung <Mathematik>Web-SeiteCodeClientTransformation <Mathematik>Mechanismus-Design-TheorieKonfigurationsdatenbankFunktionalElektronische PublikationMathematikGeradeMathematische LogikSelbst organisierendes SystemEin-AusgabeComputeranimation
Zusammenhängender GraphObjekt <Kategorie>Programm/Quellcode
ProgrammbibliothekZusammenhängender GraphRuby on RailsEndliche ModelltheorieWeb-SeiteDämpfung
MusterspracheUnternehmensarchitekturOffene MengeKartesische KoordinatenMusterspracheOpen SourceBootstrap-AggregationZusammenhängender GraphComputeranimation
Zusammenhängender GraphRuhmasseInformationsspeicherungQuick-SortMechanismus-Design-TheorieClientMathematikTaskLesen <Datenverarbeitung>KonfigurationsdatenbankGruppenoperationComputeranimation
TexteditorURLGruppenoperationOrdnung <Mathematik>InformationsspeicherungZusammenhängender GraphKartesische KoordinatenFunktionalMenütechnikWeb-SeiteElektronische PublikationFlächeninhaltCodeObjekt <Kategorie>Cookie <Internet>Mechanismus-Design-TheorieSkriptspracheReelle ZahlAppletBildgebendes VerfahrenXML
TabelleGruppenoperationCodeMathematikOrdnung <Mathematik>InformationsspeicherungMaßerweiterungKartesische KoordinatenHyperbelverfahrenVirtualisierungZeiger <Informatik>Trennschärfe <Statistik>SichtenkonzeptRenderingZusammenhängender GraphCASE <Informatik>GruppenoperationComputeranimation
Objekt <Kategorie>Kartesische KoordinatenWrapper <Programmierung>Zusammenhängender GraphFunktionalEin-AusgabeBildschirmmaskeComputeranimation
LastIntelVerschlingungTurbo-CodeVolumenvisualisierungRouterKartesische KoordinatenWeb-SeiteWurzel <Mathematik>UmwandlungsenthalpieGamecontrollerRoutingClientRuby on RailsRenderingRouterTelekommunikationEinfache GenauigkeitZusammenhängender GraphMechanismus-Design-TheorieBitQuick-SortServerElement <Gruppentheorie>PunktwolkeVerschlingungWort <Informatik>LastTurbo-CodeProzess <Informatik>Rechter WinkelCASE <Informatik>MakrobefehlReelle ZahlGeradeFlächeninhaltComputeranimation
VolumenvisualisierungDedekind-SchnittRouterWeb-SeiteClientRenderingRoutingServerDefaultFlächeninhaltTotal <Mathematik>VolumenvisualisierungWhiteboardURLMixed RealityObjekt <Kategorie>VerschlingungComputeranimation
Einfache GenauigkeitKartesische KoordinatenWeb-Seite
BitObjektorientierte ProgrammierspracheRouterWeb-SeiteComputeranimation
Zusammenhängender GraphKartesische KoordinatenServerGraphAttraktorWeb-SeiteEinfache GenauigkeitTaskClientMultiplikationsoperatorMereologieTermDickeRenderingBitHybridrechnerGanze FunktionComputeranimation
UmwandlungsenthalpieRenderingKartesische KoordinatenServerSystemzusammenbruchApp <Programm>LastFront-End <Software>Ordnung <Mathematik>Quick-SortDebuggingWeb-SeiteGüte der AnpassungMultiplikationsoperatorEinfache GenauigkeitClientObjekt <Kategorie>Projektive EbeneDienst <Informatik>Turbulente StrömungNichtunterscheidbarkeitBildschirmmaskePhysikalischer EffektComputeranimation
PunktwolkeComputeranimation
Transkript: Englisch(automatisch erzeugt)
before recording, and with the paper.
Thank you. Yeah, okay, it's good.
It's on? Yeah. Thank you. Hello, everybody.
I hope you pass a great FOSDEM event. Right now, we have a great presentation, how to migrate from jQuery to React, and I think a lot of people has work to do that. Thank you a lot for the presentation.
Hi, everyone. It's amazing to see so many people in JavaScript room. And so today, I will talk about the process, the transformation from legacy JavaScript from server-side rendering into a more modern web application, which in our case is React.
So first of all, my name is Amir. I work at Reddit for more than three years, and in my team, we mostly focused on Foreman. Foreman is an open source for a management tool and to servers, physical servers, and of course, virtual servers.
So Foreman established in 2009, and in 2009, Ruby on Rails was very popular. So we used Ruby on Rails, and we used server-side rendering. So today, I'll start with the first steps. What you should do. What the first step you should do
in order to start this process, in order to start this transformation process. After that, we'll talk about the connection, how to communicate between the old world, between the legacy JavaScript and the new world. After that, we will talk about client routing. Do we need client routing in our modern application
in hybrid way? And after that, we will wrap up things, and we'll talk about long-term goals. So let's start from the first steps. So first of all, why React? Why use React? So we have plenty of reasons for that.
I think the number one reason, of course, is performance. React renders only the components that has been changed. So your web application doesn't need to re-render each time. Of course, you can scale up things very fast. Due to the mechanism of components,
you can start from small, and then you can gain some complicated components after that. React is great community, and I don't have to mention that, of course, and with great packages. And it's fully testable with just an enzyme, and you can just, with one second,
you can write a test. And of course, the debugging stuff with React, you can see, actually, you can see the code in React, and you can understand immediately what happens. But with legacy JavaScript, it's a bit harder to do. So be my guest and see this thing.
So this is our legacy. One file, one JavaScript file. As you can see, it's very long file, more than 800 lines, and it's very difficult to debug. If you change something here, if you change that jQuery stuff, other functions can be changed as well.
So it's really difficult, it's really frustrating to debug this file, or even to change things, small things, or you want to do some refactoring, it's really frustrating to do. So that's the major reason we did that transformation. So our approach is start from small,
which means bottom-up approach. Start from basic components such as buttons, inputs, and you can gather these components, and you compose it from these components, much more, of course, complicated components. And with these complicated components,
of course, you can reach and have a full React page. So that's our logic, start from small, and then, of course, scale up. But first, let's imagine we just wrote a button component. We need to combine this component in our Ruby on Rails page.
So we need some sort of mounting mechanism to put a new code, a client code, client rendering code in our Ruby on Rails page. So we need to use some sort of mounting mechanism. So we have that function, that mount,
and the component we want to put in our Ruby on Rails page. But first, we need, of course, a registry in order to register that component. So we have a component registry, so let's imagine we have that button I mentioned before, and I just need to add it to my,
to our object, to our registry, and then we can mount it with the mount. So the mount, as you can see here, is a Ruby on Rails model. And with that, we can mount components,
we can mount React components in our Ruby on Rails page. So that's great. But instead, of course, to write your own components from scratch, you can use all the libraries. So I don't know if you're familiar with React Bootstrap, but it's really well-famous. And of course, we use and we contribute to Patternfly,
so if you have enterprise applications, Patternfly can give you really nice design and really nice components, and it's open source, of course. So this is the first step you should do. You should have some sort of registry,
and of course, a mounting mechanism to mount your components. How about the way to communicate between these worlds, between the old world and the new world? How we can communicate between these? So we use for that task, we use Redux. And why Redux? Because Redux is very easy to understand what's happening.
And of course, with Redux, you can access to the store. The store is your client data. It's like your massive data store of your client. And you can invoke actions, and when you call some actions, you can change the store. And if the store has been changed, it forced the component to be re-rendered.
So with this, we can control our components. And of course, we can subscribe the store for changes, and we can call a specific callback. So we use a special object, a global object, in order to be the glue between these layers. So as you can see, each entry here
can be just an ES6 function, or can be action that we can invoke later. Or as you can see here, we have subscribed, so we can subscribe to the store. If the store has been changed, we can run some callbacks, or we can gain some data from the store.
So for example, this is a page in our application. So this one, the layout, as you can see, the menu here and the top bar here, is fully based on React. And as well as the breadcrumb, as you can see here, still is, it's a React component. But beneath it, this area is not React code.
This area is a server-side rendering, OBE on Rails. So in order to communicate between these breadcrumbs and this name, as you can see, it's the same, and we need a way to communicate between these. So we use that ecosystem.
We use that mechanism. So as you can see here, this is a file which we import the store. We import a specific action that changed the breadcrumb title, and then we can just invoke that.
We can create a function that invoked that, dispatched that action. And with this, we can actually change the breadcrumb, the React component. So as you can see here, we use that function, update title, in the legacy JavaScript.
So it's jQuery, and we can just apply React things in jQuery code, in legacy code. So another thing, as you can see here, we can subscribe to the store, and if the store has been changed, we can run this callback, and this callback
allows us to reach the store, check the last action, and check if there's some errors, and we can just alter and change our legacy code, our server-side rendering code.
So as you can see here and here, I use jQuery, and I alter and change my legacy code. I cannot change React code with this. I can change only legacy code, because with React, I have access to the actual DOM, and I don't have access to the virtual DOM, and we'll talk about that later. What about the opposite way?
What about how we can use jQuery inside of our React component? Do we need it at all? So sometimes you do need it. In our case, we use select-to. Select-to is extendable jQuery, a nice one, really nice one, gives you a lot of features
in your select, and we decided, in order to keep our application unified, we decided to use select-to-jquery extensions in our selects, even in select in React. So let's see, first, how does it work? So as I mentioned before, we have the virtual DOM and we have the actual DOM. So React uses the virtual DOM,
and we need some reference in order to reference the actual DOM. We need the pointer to point to the actual DOM. So lucky us, we have React-to-f. So React-to-f is a really nice thing that React gives us, and as you can see here,
this thing, this dot select, is a reference to the actual DOM. So I can apply jQuery function from React component. So this is select, as you can see here. It's a wrapper for our select in our application.
So this dot select is the reference, and now we can initialize that reference. So here, as you can see here, I have the ref inside the select input, and then I put that select, which is the actual DOM,
I put it in this object. So now I have a reference to my actual DOM, and I can apply jQuery function inside of it. So that's the opposite way, and sometimes you need it.
So that's about how you can connect, how you can communicate between the old and between the new, between these worlds. And it's very important, because when you started to do that process, you don't rewrite your entire application in one day. So it's really important to have some sort of communication.
What about client routing? Do we need a client routing in our hybrid approach? So in Ruby on Rails, we use TurboLinks. And TurboLinks, in fact, mimics the feel and looks of SPA, single page application. So how does it work? In a few worlds, TurboLinks just swap the body element
between the new page and the old page, instead of, of course, full page load, and it makes your loading faster a bit. So you have the feeling that you have a single page application. But what about combining TurboLinks and React?
Does it work together? So we try that, and yes, it works together. But what if you have plenty of React components in your page? It's basically based on React components, so you don't have any server-side rendering. So in that case, do we have some benefits from TurboLinks?
And the answer for that is not really. So we decided, we looked into something else that will give us some benefits. So that tool is React Router. But wait a minute, we have server-side rendering, we use Rails, Ruby on Rails. And so how this can work in our application?
So we do some research, we do a POC, and we manage to combine these two. We manage to combine between client routing and server-side routing. So how we do that?
So we use React Controller, a specific controller that you can inherit after that, and that React Controller is rendering a specific React layout, which is still in the server-side area, which is very small, it's a very lean layout. It's not the layout you're familiar with, the urbanness, it's a really lean, really small layout.
And after that, in the client, we have a root component, which wrap your component, and of course, we have a switcher to switch, to distinguish between pages, to render the right page. And of course, if it's not a React page,
we should take the real page, we should render the page from the server. So we should use some sort of mechanism for server-side rendering, and client-side rendering together. So this is our,
root, as you can see, the router is wrapped, our layout, as you see before. And this is our switcher, and with the switcher, we can switch between our pages. So how the switcher looks? So the switcher looks something like that. So I have the switcher, and I iterate over my entire routes,
as you can see here, and my routes, and by the way, these routes are only the client routes, not Ruby on Rails, not the server-side routes. So if I have a page which I would like to render in a client rendering, I have this in this route object,
and then, as you can see, I render it with a client-side rendering. But what happens if that page is not React? What happens if my local, my current location is not React-based? So I have a default route, as you can see here,
and with the default route, I just use two rings, as you can see here, and then a server-side rendering appears. So we have a client-side rendering, and we have a server-side rendering together, mixed. So we benefit with these worlds.
So I would like to show you a demonstration of that, and first of all, please have a look on a page with two links with no React router.
So as you can see in the spinner here, and you can see that this page is, it's not a single page application. It's not single page application behavior. So let's have a look, it's skipped a bit,
with React router.
The same page, it's almost instant. So as you see, it's really amazing
to use React router, even if you have, most of your page are based on your server-side rendering. So you can scale up it, you can scale up things, and start from small, start from one React page, and after that, you can have, you know, when you have that feeling in your application,
I bet in, so it's only a matter of time that you use this kind of pages. You use this technology. So for long-term goals, is hybrid enough? So it's not a question of, it's not that, the question is something else. The question is, are you, do you wish
to rewrite your entire application? It's a really tough task. It's a really time effort. It's a really time-consuming task. So do you really wish to rewrite your entire application? So I bet you don't want to do that at first.
So in our approach, we thought that it's really better to use single-page application infrastructure, which means to, at first, to make your effort in infrastructure, and not in just rewriting your entire application, because with that,
you enjoy the technology now, and not just rewriting your application. You have the benefits of React now with hybrid approach. So when you have that infrastructure, which means you have better API, such as GraphQL, which, of course, use the client better,
you have client routing, as you've seen before, and you have plenty and plenty of components. And when you gather these three, it's only a matter of time until you become, until you become a single-page application. So yeah, it's not a matter of do you wish to rewrite your entire application? You will enjoy from this rewriting task.
You have fun with that part. But you still have that feeling today. You still use the new technology today, and not in the next future. So thank you very much.
Yeah? The format, what?
The format, what? Before, that went a bit fast for me. Like, what did you do here? Oh, in this specific page? No, just like with the format thing. You tested how fast it was, with and without Turbolinks?
Yeah, and we just put React Auto, and it's based on React, and it's client-side rendering. We don't use server-side rendering. We don't do round-trip to the server in order to get HTML. So it's much faster, just get JSONs and data, and you don't get any HTML from the server.
So it's much faster. Basically, it's single-page application. Single-page application, yeah. So with single-page apps, usually what happens is, they grow so much that the initial load
is impossibly long, and then the data that gets pulled from the server, also people usually, hey, I need all the people in my app, and not just five of them, and what happens is, they load all of them, they have it on the front end, and then they do stuff with that,
but the rendering, just parsing the requests from the server, in that case, starts getting too long, and I have seen where a single-page app has so much data to go through on the front end that that becomes a bottleneck, and I've seen stuff crash when you have too many objects, so how do you do that?
So it's for sure that single-page application is like an application in your application, because you have the server side, you have the backend, and then you have the client, so it's something else. It's not just like we used to be to have full-stack engineers that do both. We have some sort of application in our application.
So yeah, it's a bit complicated, but you gain a lot from it, so if you look at the, you know, in the next future, not what happened now, it probably, for us, you know, not for our project,
we took the hybrid approach because of that concern, because it's really, we don't like to be, to distinguish between our, in our application into this backend and client, and we want to have something more hybrid, something that combine between these server-side rendering and client-side rendering.
Yeah, we have the last question here. Could you share more about the price, how many working hours caused this relitening from jQuery to React? Sorry, again? Could you share more about how many working hours caused this relitening from jQuery to React? Okay. Price.
So from jQuery to React, so it's really a good question. From jQuery to React is something that you don't do instantly. It's something that you, you know, you join that technology because you want to gain something more.
With jQuery, you cannot do, you can do the same things like you do with React, but it takes you much more time. So you have much more benefits with this ecosystem, with this, of course, a hybrid approach because you still enjoy from new technology, from React, from packages, from, you know,
from new stuff, complicated stuff, but you still.