Using React Without Using React

The source of this, the inspiration for this talk, is the cases where I have to build vanilla JavaScript apps. And every time when I jump to do that, I always start thinking like a React developer. So what I did after some time, I just pull out some ideas and basically, this is what I'm going to share with you.

So as you just find out, I'm Krassi, I wrote some books. The first two are rubbish, don't buy them, they don't make any sense anymore. The other two, if you like to read, they kind of make sense. So I have this little app, which now you see, there is this button. When I click it, I go to the web server, I get some JSON. Do you know how to properly pronounce JSON? We as professionals should know how to pronounce JSON. So the real pronunciation is JASON.

So we go back to the server, we get some JSON. Then we move forward to rendering this like a select element. Then I'm able to pick some of the shows and then I just render some information. And now if I have to build this thing without React, I'll probably end up having this markup. And now, when I think how to actually build this, immediately what I start recognizing is that, well, I could think about components. I have H1 tags, so I think, okay, this may be just a title component. Then I move forward, I see the grid, so, okay, then I'll build a grid component. I have grid items, which now I have to kind of split everything into columns. Then I reach about this bit, which is the information for every character from the show.

Then I say to myself, okay, I'll just create a character component. Every time when I'm not using React, I actually start thinking in components. Because I'm doing this for more than 20 years, it wasn't like that before. The first thing typical about React is components; React's component-based architecture allows for scalability and rapid development. Creating a component involves input, logic, output, and composition, essential elements even outside React.

If I have to build the same example with components, I could create simple functions returning strings. Borrowing concepts like children props from React, the arguments of the functions in non-React projects are similar to React props. Functions can be combined using composition, such as rendering three columns with a show function. JSX initially caused skepticism but is now valued for its developer experience. JSX can be used without React by configuring the Bundler, replacing React.createElement with a defined function.

This approach allows developers to use JSX syntax, a fundamental aspect of React, in projects without React. React components are essentially React.createElement function calls. Configuring the Bundler to replace React.createElement enables JSX usage without React. Developers can customize the replacement function, maintaining JSX syntax. This flexibility demonstrates that JSX, although associated with React, can be utilized in non-React environments, enhancing development possibilities.

Yeah, here is, for example, the show function, which uses the grids. I pass some configuration, rendering, three columns. So it's really, really possible to apply the same concepts if you're not using React.

What about JSX? JSX was when it came, everyone freaked out saying, well, what's this like HTML syntax in my JavaScript? It was really weird. I was really against it. But I was against hooks. Now I'm against React server components. And I know that I'll adopt them. This is the truth, actually.

And I'll adopt them because it's a really good developer experience. And if you want to use JSX and you don't have React, you still can do it, because JSX is just syntax sugar, right? Every React component is basically React.createElement function call. So all we have to do is just to configure our Bundler, basically to replace React.createElement with something that we define. And this is like, it could be banana dance if you want. And then we get this.

So no React. You could write your own JSX. You could receive some JavaScript. And then you write your own stuff. The things which I saw over the years, and this is a bit of an abuse of this kind of like a pattern. I definitely think that it's not a good idea. But I saw one company that they love JSX so much that they were writing their CSS with JSX, which was like really weird thing. And yeah.

The other more valid case is a company that uses JSX to define their Express.js routing, because they like how React Router is working. So they wanted the same API, but they don't have React on the server. So what they did is basically they started using the ES build tool, just configure it properly and then write a little bit of logic to kind of understand the syntax.

What about separation of concerns? When I started using React, everything was kind of against that. Because for years I was following separation of concerns, meaning that styles should be in one place, the logic should be in another, the template should be in a third place. Everything should be split, should be properly done. And when React came, everything is just in one place. And over the years, I realized that separation of concerns in React is still there. It just depends on what kind of components we create.

Because you could create components for styling, you could create components just for logic. Now we have the hooks, which are purely about logic, right? Our markup is the templates. So separation of concern is still a valid concept. I think React is actually helping in this direction, because we all learned that when you're writing components, you can't just throw everything in one component. You start creating a dump of smart components, then you're extracting the logic into hooks. So there is separation of concern, and React is actually helping in this direction.

And here is an example. I bet that you most probably have something like this. You could see styles at the top, then we have some logic, like an async logic, then we have the template at the end. Well, this is really just, it could be just this, where we extract the logic into a hook, we have the templates just containing some markup, right? And the styling of the button is in its own component.

And when you build stuff without React, you're actually following this same pattern. So you are following the separation of concern, which is kind of important for your app in order to scale well. So it's one more thing to kind of get from React, is that, indeed, you're just like splitting the things in different areas. The control for React.

If you go back to this example in the beginning, where I click the button, get the JSON, then I render the select, then I click some of the items, and then I show some content. So it's pretty much why this picture is talking about, like step-by-step stuff. And if I have to order this thing in my head, it will be something like this. Really step-by-step how the flow goes. And then if I want to implement this with vanilla JavaScript, it's me just using innerHTML on an element.

I just throw some button. There is a global function. I fire it, then I go get the data, then I render. And when I render, the select item has this onChange handler, right? Which fires this function, and I render again. So this is what happens in my head when everything is working right. But this is really imperative programming. It's me saying how the things should happen and when. While React is really declarative. And this is the big difference between how I was doing the stuff before and how I want to do the things now.

So what is better is actually to create, for example, a state, right? This is kind of the main thing in React, where you have this single source through the state, and then based on the state, you render. And if you want to change something on the screen, you basically change the state. So I now add the function about the state, about changing the state. And I don't forget that after updating the state, I actually have to re-render. So I do this now, and then in my render function, I kind of declaratively explain what needs to happen. If this is loading, then show this. And all this has nothing to do with React. You can see I could just get this thing, I could use it without React.

So the declarative way of writing and thinking is not bound to React. You could actually take this concept, this pattern, use it in another place. And this leads to the same kind of conclusion, where we have this one-direction data flow, where you have state, change, re-render, user interaction, change of the state, and then you do the same. So this type of flow wasn't really typical in the past. When Angular, for example, came, there was this two-way data binding, which is kind of the opposite of this. You write something, you have the state, then you have the UI, and these things are synced immediately between each other.

When you change one, the other one is kind of updated automatically. When you change the UI, you have the state updated automatically. And this was done by the framework. While the concept here in React is different, in order for you to change something, you have to go and update the state. This is why we have this uncontrolled and controlled input, right? The idea of having this input is really interesting, because for the first time when I tried React, I had this input field, and I couldn't update the value of the input field. I'm typing in the field, why is it not changing? It's not changing because I was having this value in the state, and I'm just passing the value of the input field to the inputs, but I'm not updating the state with the hook.

Back then, it was the class components with set state. Then I found out, well, this is too much code for just updates, to just have an input field, right? You have to manually update, then re-render, and this whole thing. The truth is that over the years, this makes me think less about what I'm doing, because there's no magic. You know, the single source of truth is actually there. Only thing that I have to take care of is my state's management.

So the One Direction Data Flow is another concept which has nothing to do with React. It is introduced there, but you could get this idea and apply it to some other apps. You don't really have to use only React if you want to go there. Here I'm showing how it's done. It's basically the same code as before. We have state render, we update the state, we render again. So state management. State management is something that we could make a whole conference about.

What I want to say about state management is that, and what I want over the years with React is that state management is not about the tooling. It's not about whether you use Redux, Recoil, or Zustank, or Context, or Hooks about states. These are just tools which help you how to manage the state. The actual state management is about you figuring out what kind of state you have, and where this state should live. For example, let's say that I have an authorization layer, and I have my user authorized, so where is the information about the user? Does it have to be in some component somewhere, or it needs to be at the very top? So this is basically the state management. It's you deciding where the state lives.

And then based on this decision, you make the choices what kind of tools you need. Sometimes you have a giant paragraph of text, and you want to truncate the text, and you have a read more button. Is this going to be in a global state? No, right? Should we just leave a little state management in this particular component? And this is what state management is all about. So after years working with React, this is what I'm getting from there. It's basically, when I'm starting about states, it's really my first question is, where the state lives? And yeah, this picture is kind of illustrating the different levels of state management.

Of course, ideas like Redux, they're not only about React. You know that Redux doesn't exist with just React. You could use it in Angular or Vue or whatever. So it's one more thing which came out of the React ecosystem, and people are using it everywhere. It's because it's a simple concept. And this is the direction of my talk, is that there are a lot of things in React which you could just get from there, and apply them in another context. This is something which I really love in this technology. So this is a little bit more code, but it's a simple implementation of Redux. I bet that each one of us actually implemented Redux on themself, because it's quite easy. And you say, yeah, I could do it myself.

It's the same with the Flux, which came before that. There are so many implementations, because it's simple. It's just a powerful idea, and it's really simple. So now I'll do a little bit of live coding. And I want to show you how, by my experience, I see people actually use React. And at the end, we'll see whether this is a good idea or not. So let's say that I have a form. But because the form is kind of ugly, I want to add more space. And because I'm a professional developer, the way of adding space is actually to add some break tags, right? This is the first go-to tool for making space when you're a professional developer. OK, so that's cool. But because I'm a senior, I want to use something like a Tailwind. So I start adding a bit more stuff. I add some classes, especially for the button at the end. I add something like 17 classes to make this button look really nice. And you'll see in a sec that it's actually working pretty well.

What doesn't really work is the fact that I can't really make these radio buttons work. Because if I click one of the buttons, I can select the other one. So now, if I think as a fresh out of bootcamp React developer, I'll go here and I'll actually start doing some state management. So I'll use my powerful skills about using useState. So I'll add the checked attributes to my input field. I'll manage this with the state, and everything is really, really beautiful. Now, when I click here and when I click here, everything is working as expected. They're kind of like toggles.

But now, I want to be able to click on the labels as well. So how to fix that? Well, I'll do more. I'll wrap every label with Span and now it's another click handler. So I could manage the state and I could properly select any of the options. So this is all cool, but do you think that this is a good idea? Right? No. I see people like watching, no, no, okay. So this is the problem that I'm seeing today. A lot of people are just using React without realizing that a bunch of stuff are just there. So they are provided by the platform.

And the very first thing that we have to fix... Here, I forgot, of course, to add a click handler on the button. So when I click it, I kind of submit the form. The thing is that I don't even have a form here. So the very first step is just to add the form element. Because when you do this, all the elements inside the form element, they start working in a different way. Then maybe, instead of just using this, maybe I'll think a bit about accessibility, and I'll start using a field set. Because this is kind of a grouping, different things of my form. Then if I move forward, I'll delete all this bullshit about state management. Because I don't have to do it. It's already there. It's part of the platform. All I have to do is just to add a name attribute to my input fields.

And if the name attributes are the same for multiple inputs, they are married, allowing easy selection. Enabling clicking on labels is simple with a label element to wrap the content, facilitating interaction and accessibility. Utilizing arrow keys to switch between options is seamless, enhancing user experience without manual implementation in React.

Choosing a button over a div ensures proper form submission behavior, leveraging default browser functionality. Emphasizing the importance of understanding fundamentals before relying solely on React for web development. Learning step-by-step processes like HTML and CSS enhances React coding skills and overall application development.

Highlighting the significance of gradually learning and mastering foundational web technologies before diving deeply into React. Acknowledging React's strengths and the necessity of understanding its relationship with underlying web standards. Encouraging developers to appreciate React's capabilities within the broader context of web development.

So I know that this is a really extreme example, but believe me, it happens. People just get from somewhere, they start running React, and they forget about all the fundamentals and all the things which are actually there. Of course, the submit function, it becomes a bit different. Because if you have a button in a form element, and if you skip the type attributes, the default value of type is submit, and the form is submitted immediately if you click the button. So you don't have to click, you don't have to call the function. This is just happening because this is how the browser works. I could even just start typing here, press enter, and my form is submitted. So is this there if I don't use form elements? Maybe no, I don't know. But it's definitely something the user wants, and then you're not giving them. Because you're trying to reimplement stuff which are done with React, Way, and all the stuff.

React is really cool. My point, from this presentation, the other thing except get everything from React and use it outside, is that we should learn the fundamentals. Because that's why, and then we'll be able to write better React codes. Because we don't have to implement everything. React is really nice, but it doesn't serve the purpose of the platform. So when you start writing React, just don't take the elevator immediately, take the stairs learn the step-by-step stuff, learn HTML, learn CSS, learn how to do it without React. And then you'll see the power of React, where it actually shines and why it helps us build great web apps.

Yeah, this is what I have for you. Thank you. I hope it was helpful. Alright, let's jump into it. I love what you said, how you ended with learning the fundamentals. I think it's very easy for people to jump straight into a framework and not understand why the framework made certain decisions. How do you think people can go and find those? Especially because lots of tutorials lead them straight to React, lead them straight to these frameworks. How do you think people should go about finding the story behind what these frameworks solve? Yeah, I think the best way of doing it is just to find a mentor, probably. Because nowadays we have so many resources and the content is just everywhere and it's really difficult to filter what we call fundamentals. So I think the best way of doing it is just to find someone that has more experience than you, and you basically ask him, hey man, what is the base of HTML forms? What do I have to learn? In most of the cases, you'll be forwarded to documentation, MDN documentation and places like this one, where people spend years working on this stuff and they explain things really well. But I think the quickest way is just to find someone.

Nice, nice, nice. Well, that is good advice. Whoops, I marked the question as marked, let me bring it back. So oftentimes when we're solving problems, we kind of see similar patterns and maybe other people are also solving similar problems, so the solutions look similar. And this question is down that thread, which is, aren't you building a mix of Redux and Signals? When you look at it philosophically, do you agree? Maybe you're thinking about it differently. The question is whether... Aren't you building a mix of Redux and Signals?

Well, I think very often these ideas, these patterns... And this is true for the frameworks in general, how people actually pick frameworks. And they pick frameworks not because they are performance or they have a huge community or whatever. Most of the cases, they pick a framework because they like the ideas, but kind of they align with the philosophy of this framework. And it's the same with this libraries and state management tools and everything. If you just don't like how it works, it's difficult to adopt it. So yeah, for example, I don't have any experience with Signals. I'm a bit like, yeah, let's see how it goes, where it goes.

While with Redux, I was speaking really quickly because it was a really simple idea and in my head, everything should be really simple. And it's aligning with what I'm thinking, so I picked this really quickly. So yeah. Nice. Give me a moment. And let me quickly go back to our questions. Which is, we've got another one. How do these concepts scale in larger terms? Doesn't this just eventually turn into yet another JavaScript framework? This is a really good question. I think there is a balance that you have to find basically because very often when I'm building vanilla apps, I get these concepts, I start using them. And indeed, it feels like you're building your own React really slowly, but you're getting there. More roads need to react. Yeah, exactly. So the point is that you should get the good stuff, but you should be always thinking about not going too far. And this is mainly about abstracting stuff. You start creating these big abstractions and after some time you get the sense of this kind of a good feeling that, well, this is maybe too much. And then you stop and you find the balance.

But it's definitely a good point and it's probably the biggest problem of this approach, of writing vanilla apps and taking what you know and just applying them. That absolutely makes sense.

And then the last one is, what about instant appearing error messages? What are the boundaries of native approaches and how to work around them? About instant? What? What about instant appearing error messages? So what are the boundaries of using native approaches? Because obviously there's a lot of things natively, but they work differently to the way frameworks maybe build around.

I would answer with, yeah, it depends on your user base, I guess. There are different approaches of handling this, but it really depends on the use case. And technology-wise, your team, what it's able to do, users, so it's a really complicated topic. Yeah, it's... Well, I'm 4 for 4 and it depends from our speakers in Q&A, so thank you. Remember, if you want to ask more follow up, we do also have time downstairs in the live speakers Q&A. We've got a few more times for some quick questions.