Video details

Nir Kaufman @ ReactNext 22 - Kiss my App! – How to keep it simple and avoid BDD with React

React
08.03.2022
English

ReactNext 2022 www.react-next.com Israel's Annual React & React-Native conference
Powered by EventHandler ----------------------------------------- Kiss my App! – How to keep it simple and avoid BDD with React: Just because it's popular - doesn't mean you need to use it! React is simple and focused at its core, But once you dive into the ecosystem you might end up with a stack that makes your system over complex, and hard to maintain. In This session, we will revisit the KISS principles in practice, and learn how we can avoid Buzz Driven Development (BDD).
----------------------------------------- Nir Kaufman: In a long-time relationship with React as a developer, author, consultant, and trainer. Google developer expert in Web technologies, Vegan (but nice), electronic music producer, and sound designer at night.
----------------------------------------- #javascript #reactjs #programming #software #development #softwaredevelopment

Transcript

Good afternoon, everyone. So excited to be here at the Job Security summit. Today we're going to talk about cobalt and angular. No one knows how it works. Learn it. You're will always be employed. Now, seriously, the title for today is Key Smyap. And because it's 2022, let's start with a short disclaimer. This talk is not encourage you in any way to kiss my app or anyone else up. You can keep your own app if you like. I can kiss your app if you like. Me. Let's get started. John Lennon said there are no bad practices, just trade offs. Seriously, before he died, passed away. You can check it out. But if there's one thing that I would like you to take from this session, which is not going to be very technical, it's more just let's talk about things that you already know. Is this one. This is the most important thing. Because best practices, or even the term best practice, it's got some issues. We tend to stick to best practices. And it's easy for us. We don't need to think too much. Let me give you a practical example from real life. If you Google how to play a recorder, you will find these instructions, which is basically, you can hold it like this and you can play it, and you can spend your entire career playing the recorder like this. But let's think about it. Technically, we need flowing air to play the recorder. We're going to break the best practices, the manual. And what about two recorders? So what's the point? Nothing, basically. Thank you. I do always also bar mitzvahs and weddings. There are no best practices, only trade off. If you want to know what's the trade off, you can check out this flute later on. Great things happen when we start breaking down best practices. That's what I'm here to say and I want to tell you a tale. Let's start with once upon a time, because all the people here, at least I believe part of you are not doing, like software development for 20 years. Maybe even was like five years old. So let me tell you something. Once upon a time, there was no front end and no back end. Once upon a time, we were all just software developers. That's it. There was not even the term full stack. I don't believe it was exist. We are software developers. From time to time, we need to build UI because it's part of our job. Full stack development is kind of I don't know. And you buzz the term for something that we used to do. Basically, you can build software which can have a graphical user interface, GUI or not. And these days, there's a question that keeping me busy. Are we front end developers? In 2022? How much time in your job today you spend on actually building the UI part, the visual part? Maybe you use some UI component library. Maybe you spend most of the day in the skill set that is required from a front end developer in 2022. It's a bunch of other things which got nothing to do with UI. So you need to work with git and you need to own your pipeline and you deal with performance with other aspects of web development. When I made the switch from building website to building web applications, the term RIA was very popular. Who knows this? Just raise your hand. I just wonder how old are you? Without saying your age. It stands for rich Internet applications. So we stopped building website and I was a real developer. I used Flash and Flex and again, part of my skill set is to know everything about from databases and eventually there is graphical user interface. Now, these days user interface is a tricky term because it's not always graphical. If you build voice actions for voice activated device are you a front end developer? Do you consider yourself a front end developer? Interesting question. I'm the only one interested in it. Maybe, yeah, because I'm not doing too much with my life. So I've got a lot of time to think about it. So what is Kiss? Kiss stands for keep it simple. Originally stupid, but we don't say the word stupid because it stands for keep it simple and straightforward, keep it simple. Whatever you name it. It's easy to talk about it, it's easy to add to it. I believe that most of us we had this conversation how we can make things simple, build complex things built it simple, be it small, blah blah blah, but it's very hard to do. This is also a forgotten banned but it's a different thing. And we went a long way from sending some HTML to the browser to today. Basically when we build microfrontals from multiple single page applications that use different frameworks and that's just a starter, I should add a monitoring points inside. I mean our default projects become huge architecture. How many of you heard Neta Bondi earlier today? 50%. She was I think the all right, cool. We need to ask ourselves maybe we took it too far. Maybe front end development, which is like kind of a new term, become too complex with no reason. Maybe I'd say just maybe the complexity of the web applications that I do today is no different from the applications that I have. Web applications that I used to build ten years ago. So what's changed? The Internet was slower, now the browser is stronger, cool and then react. And then react came out. I think I believe it was 20, 13, 14, something like this. Remember this? There's a quiz by the end of this conference and almost immediately become very popular. And why it become popular? I believe that most of us it was like a fresh breeze of there is a JavaScript library that can do one thing and can do it one only thing next to my English, but you get the point. A JavaScript library that got one job, which I'm not a big fan of Microsoft, but it's like Office Suit. It's like Adobe. You've got like an application for something specific. Like you've got Excel. If you want to write register, of course you can write documents, and you can build slide deck out of Excel, but you won't do it. I mean, the one best thing that Excel can do is basically spreadsheets. And you've got Word for documents and PowerPoint for presentation and these things that I don't know what it does. All right, there's going to be another vehicle joke up ahead, so if you miss this one anyway, what I'm trying to say that React was a pressure because it was simple before we made it complex. So if you read the description of this talk I mentioned, BD, which stands for which stands for you're tired, you're sleepy After Lunch, stand for Bus Driven Development. Yeah, bus Driven Development, which basically the circle of death. There is a new library introduced, and then there's a lot of buzz and blog posts and YouTube videos, and everyone use it, so we should use it too. And it's actually become something that we seriously consider when we choose technology. I had a very interesting conversation with colleagues from other companies in our small industry, and it seems like that if the library is popular or not popular in most companies become a real thing. We're going to choose React because it's more popular than Angular, and we want to get the top talent out there to use it. Sometimes even we will choose, and we all doing it. And now we say it loud. Maybe it's not the right technology to use, but it's the popular technology to use right now. Cool. So let's forward some examples from recently. Hey, the hook use effect. It's great. You might not use effect. Relax here. Relax going to solve your problem. You might not need relax. Actually, the same person that build Redox, that's his quote. You should use Stars instead of Style component. You should use style components instead of SAS. You should use V for your next project and not create React app. Why? Because it's built for performance and your app when it's going to get complex build times. Are you familiar with Vid? Who's familiar with Vid? Who's familiar? It's a great tool, but the selling point is it's fast. Your code is going to grow. Your ad is going to become complex. So maybe, just maybe, if your app becomes big and complex, break it down. Just saying. And maybe we solve a problem that it does not exist. Why should we replace the tool that is working for us? I told you. It's like a philosophical fashion with things you already know. So Kiss Principle is basically a bunch of statements. A lot of them are like, kind of practical. Most of them are not. But it just opened our mind. It's communicate a little bit with Net session and I just collected a few of them and then we're going to do some live demo of something. So the first one pronounced Team Cody. I think there's more than one way to do it. And for this one, actually, I want to play with code a little bit because I talked too much and we looked at slide too much and I don't like it. So it's come up a lot of times when we're doing code reviews and a lot of teams, maybe you agree with me and maybe not. I mean, one thing that we like about React and if you're not agree with me, you can just shout out or something. You can leave the room. She's here for the food. One thing that we like about React is the composition components wrapper component. I mean, we can create an error boundary which wraps suspend, for example. Suspend, yeah, too many beer. Suspends which rocks, whatever. Some lazy components using children, it doesn't really matter. Write down the concept. We like this in react. I like it in react. I look at this piece of code and I think it's readable, it's beautiful, it's declarative, it's whatever. But when it comes to other things, I've got a lot of arguments with other developers. For example, what happened if you want to show something conditional rendering, for example, let's take this image and we want to show it conditionally so I can do this very popular. I believe you agree with me. I mean, that's the right way to do it. May be the most popular way to do it, but what if we've got more than one condition? So I would like to quote Neta from earlier session and she said something like I took a note here, write functions. Maybe she said some other things. No, I'm kidding. I heard everything. But I took this one. Write functions, use functions. And sometimes we forget that React components are just functions. So one of the things that I like to do is to build a component, a utility component that looks like this. I can call it switch because it's going to switch, obviously. You know what, let me just grab it out from now. Let's call it we've got enough time. I'm going to call it Twitch. It's going to take some value. I'm going to use children, actually. I don't know if it's the best practice, but a good practice is to use a children API from React use to array and convert children to array because it's not an array regionally. And then I can filter this array and I can decide that each child and I'm going to use the fact that we access plane object. I can return if there's a prop child prop and let's use like a valid HTML data match. Let's say it equals the value. Something like this. Children crops and with this simple function, I can write code that looks like this switch, switch. And I can pass some value, something that I want to switch, like count. And then I can use some plain elements and I can use the data match or whatever I would like to use. But this one is valid and then I can give it another two show if two. So we have another case and that's going to be four. Show if four. And then I look at this piece of code and say, all right, I find it much more useful. And that's my own opinion. Just a small thing to warm up before we move to another live demo. And a lot of developers don't like it and they fight with me on this. Now, it's not JavaScript, but I would like to see some suggestions which are not including like early return and put it on the component that show this beautiful piece of code that I totally understand because I created a simple utility function. So something to think about. I'm going to share this code with you when we're done. So let's back to our kind of principles. So this one was easy. The famous one, the agony is connected to things that I've already said. So we can go really fast through this. Don't add functionality until then. Necessary. But we are all doing the same thing. We are all building new projects with defaults. We are like endless defaults. So learner or NX and a UI library and state management and styling, whatever it is. All right. In Hebrew we call it analamus gang. For the English speakers is PFAC preparation for air conditioning. Fluent English. Yeah, that's my native language. And you can understand the last one. Before I will show you something that might surprise you is this principle DTS. Dttcpw pronounced which is do the simplest thing that could possibly work. Now, I didn't made it up. All right, read a little bit about it because it might open your mind. And it goes against everything that we aim to do in our day to day job. We don't want to do the simplest thing that can possibly work. Maybe we want to do it, but some workarounds are involved. Again, in the previous session, neta discussed keeping your car dry or keeping your cold wet. What's going to be the simplest thing that could possibly work? And we can obviously scale it up. All right, so just because it's popular doesn't mean it's good for you. And now let's take the last ten minutes and show something which is I think it's going to be some kind of surprise for the youngest developers here. And maybe how many of you have wrote like build web application in 2010? Raise your hand. We've got enough people here. Cool. What happened in 2010? First of all, PHP developers were rock stars. Yes. These days you can call the halfline. It's a real number. If you know someone that actually still looking for a job or need to convert to JavaScript, please call this number. I will share these slides with you. But that was 2010 and one framework, one very interesting framework before Angular and before React, which these days there's frameworks built on top of React becomes a big thing. So this battery included the Amber and I can go on and on. There was this tiny framework who had a chance to build something with Backbone. Raise your hand. Cool. So to end this talk and there's a point behind it, I would like us to get her to start a tutorial for a front end developer in 2022 using Backbone and React. Why? Because it's kind of a tiny reminder that frameworks that solve real problems doesn't have to be complex. Frameworks can still give us the flexibility to choose what works for us. And because it's just fun. So let's give it a would you like to try to see some more slides? All right, cool. Just checking. Actually, you don't have any choice. I have ten minutes. It's not polite to leave the room, so just sit down and watch. All right, so in 2010 and now I'm going to say some dirty walls, people. I'm going to say model on front end development. I'm going to say congratulations, controller. Yeah. What else? View. Yeah, what else? Actually, if you work with Backbone, there is a nice utility called Collection. Collection. Collections. Collections. I can't see collections. All right. Nice. When React just went out, the slogan on the website was React. Who remembers react is the V for your NVC. That was the initial idea. React is doing one thing. It's going to be the view for your MVC pattern. Before MVC become unpopular, we don't talk about Bruno. All right. So let's try to recover this idea. Now. You don't need to sit down and watch me type. I'm going to build a component. You know what? Why? Let's start with the most basic thing. Let me take this piece of code and literally just copy it to our walking app. This is what you're looking at right now. This is the backbone model. Because once it's much simpler to talk about. I use NPM. I took Model. I'm extending it. I'm using modern JavaScript because it's 2022. I'm just initialized some things in the constructor. I've got my custom method on it. And because I'm extending Backbone model, I get for free bunch of things that I might want to use. So if I'm going to instantiate this task, all right, I'm going to have a bunch of metals that I can use with like fetch and get and obstruction on top of API. We're going to use it in a second. So that's my mobile. Let's move forward. I want to create a collection, a collection of tasks. When I take this file, I'm going to put it right here inside our collections and this is how the old Backbone framework looks. In 2022. I've got a JavaScript class. It's not even TypeScript. I can use TypeScript. I'm instantiating a model and I initialize an endpoint. I get fully restful implementation for free. And we don't talk about rest anymore. These days. It's what? React Query, Graph, QL? I don't know. Simple collection. I'm going to get a bunch of methods for free out of this collection. But let's move to the interesting part, how the controller looks like. Well, what if I'm going to take hooks and I'm going to say that my controller is a React hook. The Backbone framework worked on a very simple principle. If you created a collection, you can listen to specific events, react beauty, and React. You want to rerender, you should call Set State in this specific hook. I'm using the state hook. So basically I can take something very modern that we like, the Hooks API. I can call it Controller. I can work with a model and a collection for a tiny framework, and let's see if that's going to work in any way. All right, so the view, let's put it here. Sorry, view Tasks. I'm going to copy it right here. And this is how our view looks like. And this is like modern React. There's nothing special here. I just need to make sure to fix the imports because I believe that now it wouldn't be able to resolve. So I will take used tasks from Controller, which should be Controllers and Collections. That's good. And here it's a model task. And now you can take this task collection wherever you are. You can push, you can keep things simple and old and works, and let's reactivity. Forget about it. I lose my vocabulary again. And let's react to these things and let's see if it's going to work. So this view called Tasks from View, and I think I've got it up and running. Yeah, of course. Cannot find models. Now it's just a matter of a bad import somewhere. Let's try to find it quickly, just so we can end up with some working code that's not this project. Where are you? All right, this is fine. No problem with imports right here. That's the problem. Yeah. All right. This is just the key because I'm doing a map. So there's no surprise that works. It's not surprise that it works the way it should work, but that's not the point. The point is that I've got a challenge for you if you would like to take it. Take this old unpopular things that were not mentioned today. This MVC flexible framework from the past twelve years ago. Try to implement the initial idea of React JS a small focus library to build UI explore Backbone. Try to build something useful using the Backbone and React as an exercise. I can tell you that I used to have one client that we actually build something real in production using backbone in 2020. Why not rest for an MVC? It's not a bad thing to say. It's not like PHP. All right, Summarize. Like I told you at the beginning, this is not a deep technical talk. It's an entertainment talk to let you think a little bit about something. That makes me busy lately. Did we made frontend development unnecessary? Complex? Are we coming up with problems and then try to solve them? Can we keep things simple? Can we learn from the past and aim for the future? That was like a wonderful statement code made for humans. All right? Neto talked about it a lot. Watch it on YouTube. If you missed her talk, let's not forget it. Other tips use triple A toilet paper. It's much more softer than you think. It drastically changed my personal life and my professional life. If you want to know what's the connection between them, you can visit me at the next insurance booth out there. It's easy to add complexity. It's hard to reduce it. Don't build your default react app with all the latest libraries and extra layers. It's easy to add them later. I know we talked about it. We're not doing it. All right? And there are no bad practices. Always questions. Always try to break them and challenge them. If you want to keep talking about it, you are more than welcome to visit me at the next insurance booth. I was near. If you want to learn more about me, you can visit near live. And if you want to get free, call because it's late. And learn how you can play three flutes at once. I'll catch you later. Thank you very much. Hope you enjoy.