TestJS Summit

TestJS Summit - January, 2021

The talk will be presented as a refactoring story - will start from the messy untestable component, cover it with a brittle smoke test, and then show how to move all our react component logic into a custom hook and test this hook. Will present patterns to test things like - useState, effects, and Apollo. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Testing React Hooks with Confidence

Hello, everybody. My name is Radoslav Stankov. You can find me online over here. I'm head of engineering at Product Hunt and currently I'm located in Bulgaria. If you want to check out my presentations, they're over here. All the slides and code are linked to this page, so you can check them later. So today we're going to talk about testing hooks with confidence. And there is this big divide between test-driven development and automated testing, as you might see during this presentation. In my talk, I'm just going to mention how to automate testing. I won't go to test-driven and stuff around that. So again, talk is cheap and I don't have much of it, so let's show you some code. So I'm going to show you this untested React application. This is just a small calculator app. And this is the code of the app, and if you notice, there is a lot of it. And it's pretty simple app, but there is a lot of code. So how would we test, how do we know that it works? So what we can start with is we can start with just a simple smoke test. So for the smoke test, we can just add those test data attributes. So we can select the elements, we can use the React testing library, and we can create this very simple smoke test where we get the React testing library. Usually when I do tests, I like to have those helpers because overall, I hate writing five functions copying each other. So I just say, OK, click this data ID. And for my test, this is another small trick I do. If I need to rename the component, I don't want to go back and rename the test. So here, I just created a very simple smoke test. It just works. So I'm just testing.
Empty zeroes, clicking plus one, one, plus two, remove, two, evaluate, and reset. Basically making sure that this component works. This is something that I would do normally to test if things work manually. This is just a placeholder. This is not like a real good test. I'm going to remove this in the end, but this just makes me sure when I refactoring, I don't break something. It's not a very good test because it doesn't follow the four phases of good testing. So where should we start now? So the first thing we can do is to clean up the code, what we can do is refactoring. I like to call extract custom hooks. This is one of my favorite features of hooks is that you can actually do hooks from other hooks. And they create these very nice interfaces. So here, all these big fat logic can just be extracted into a simple hook. And this hook can give you, okay, that's what's the memory of the calculator and what are the actions. And again, the code for the hook is just copy paste. It works. So how are we going to test this custom hook? Like this is the next step we needed to do. So for testing this custom hook, there is this nice library called React hooks for me up testing library, which allows you to very easy test the hook. And what I like to do is I want to have a function called emit hook, which basically hides the boilerplate of setting up the hook. And for example, I want to test the add action. So for the add action, it's just setting up the hook, adding card value and checking that after the hook is reloaded, we have updated our value. And we can basically test, okay, if I have two digits, they're added. And you can go through all the tests for add. For remove is very similar. You set up the hook, you just call it. You have this nice call function where you encapsulate this and you have all of this.







And again, it's a bit long and I would link you to the slides in the end so you can dig through more. And now when we have this test, which very thoroughly tests our hook with all its edge cases, with all its workarounds, we can actually start refactoring this hook. The thing we are going to end up in the end from this big ball of mud is basically the fact that this hook to use just a simple use reducer, where we say, okay, we have a reducer function and in the end, we have the same actions, add, remove, reset, evaluate. And this is again, the reducer. It's a bit more complex. It's a bit more split, but this actually tests our calculator. And we actually have like a full test coverage. And again, the code for this presentation is living in this address. So you can click it and go to the details. I actually split it into steps so you can see all the refactoring steps. And a couple of the final notes I want to say here is in the end, I'm actually removing all that code from the smoke test. I don't need it. What I have found in practice is usually when I write React components, they're either very dumb, like they get some data and render stuff. So it doesn't much value adding to test them as a unit test or the biggest logic and the biggest thing I have in my test is the hook code. Like usually that's the place where a lot of the complexity of my system is. So I generally stopped doing React unit tests. And what I try to do on the unit test level is to just unit test the simple function. Like for example, I can just test the reducer. I can just test the hook by itself and not test the React components. The way I'm sure that the React components work is through doing end to end testing with something like Cypress or something like Capybara, which actually test my core workflow. Because I very rarely have found bugs in my system which were regarded to just the React components itself. Usually the bugs come from very complex hooks or when we have class components, class components. So yeah, that's basically what I wanted to share with you today and thank you for joining me.

Radoslav Stankov

React Summit Remote Edition

React Summit Remote Edition 2021

I'm going to showcase the React Native architecture we use in our new mobile app at Product Hunt. What we learned, among the way. How we moved what we know from web to mobile. Topics will be designing reusable React components, GraphQL, routing in the app, application lifecycle, keyboard controls, toast messages, and others. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

React Native Architecture at Product Hunt

Hello everybody, my name is Radoslav Stankov and I'm coming from Bulgaria, actually not coming, I'm here in Bulgaria sitting right now, and I'm head of engineering at Produhunt. And today I'm going to talk a bit about our React Native architecture and how we have structured our React app. But before we get into the big technical details, for every good architecture you have to get the context, like where the team is coming from, what the requirements are and how the stuff is built. So Produhunt is this website, this is how we look on the web, and I have given previous presentations around the Produhunt architecture and I won't go into details there, but when we decided to rebuild our mobile app early this year, actually we released it early this year, we started a bit later than that, we were wondering, okay, now we should do a big reboot into our mobile app. And for our cases we have basically two choices. One was go native with Swift and the other was go React Native. We really had really terrible experience around more than two years ago when initially we started React Native, which was quite a bit of a challenge. On the other side, we have only two developers who have some Swift experience, not very new ones, and we have zero developers with Android experience. And our app, we needed to run it on Android as well. Also, Apple, so we use GraphQL for all our data transferring and the best way to use it is Apollo, in my opinion. Apollo for Swift is not as good as Apollo for JavaScript. And our team already knew how to deal with React and Apollo. The other thing we needed for this app was to do a lot of UI experimentations. And again, we also needed Android. So early in 2020, we were making a mobile app experiments for your stack. So early in 2000, we work on two apps for a couple of our products and experimentation. One was your stack, the other was called Stack Camp. They were both not released because they were just in beta. We tested some ideas there. So yeah, don't tell anybody. So from them, we were able to compare the ecosystems from React and Swift. And we decided to go with React just because we needed Android. Our team already knew React Native and React Native actually become a lot better than two and a half years ago. It got a lot faster, a lot more stable, and we didn't have the same issues as we had before. And the test stack we decided to go was, okay, we can go with React and React Native. We use GraphQL, we access it to Apollo, and the table stakes, TypeScript, Jest, and Pretier are basically not in the question if we go with the JavaScript ecosystem. And everything done mobile, we are using Fastlane for tooling. So the things around architecture is if you don't know where to start, you can very easily get into the situation where you get stuck. So we want to move fast and have breakfast, not breaking things fast. So we want to move. So for our architecture, we have four goals. First is to make the common operations easy so the engineers can easily add new things. Then we need to put code organization so we can onboard new team members very easily into the code base. Isolate dependencies like in the JavaScript world and in basically every modern world we're dealing with external dependencies, and they can very easily get out of sync, out of date, and break a lot of things without our control. And the final thing is extensibility and usability. We want to build things that we can extend and reuse over time. But the most common thing for us is make the common operations easy so everything can develop fast to do their daily day should be very easy for them. And the way I'm thinking about the parts of the architecture, I'm seeing three pillars. The support, the components, and the screens. And they look like that in my head. We have a big support area which helps us build the core reusable components, and then we build the screens on top of that. So if for somebody more visual, this is the way you can imagine it. You have the pilot, you put them in the lines, and they make Voltron and make it really nice. So if you go and see our directory, this is how the directory structure of the mobile app looks like. And it represents the architecture of this app. And if you see, if I color code it here, we have support, components, and the screens. So again, talk is cheap, show me the code. So let's start with the top layer because it actually helps us understand the layers above if we start reverse from the screens. So all the screens are defined in the app GS. And here what we do is we use the React native navigation. We experiment with the others navigation, but this one was the one that fit our working style the best. It's a really good library and we didn't have almost any issues with it. So this is how our main screen looks like, like a summarized version of it. So we have this main stack and we are attaching these screens. And notice that here we are just doing a spread on the screens. So the spread of the screens, the screens come from this screens folder and it's in index. What we do is we just export all the different screens. So we have a central place where a developer can actually trace where their screen is. It's like a map. And for screens, this is how a screen looks like. We basically have a flat list where we have on the route, we have the screen name. Then we have a directory where we call, where we have everything related to the screen. Like for example, if in this screen, we have two private components, we search and the feed item. So those are components only used in the screen. We have the graph query, the query that will get the data for the screen. We have some utilities and the index.js is the screen. If we think about the screen, the screen is actually a state machine and this state machine starts with the layout. Then it goes to the loading state inside of this layout. If something bad happens, there is an error state and this error can be a server error, not found error, authorization, authentication and similar errors. On the other side, we can have the loaded state. So when the screen is loaded, there is a couple of operations we always need to do. We need to render the screen. And we noticed that we have a lot of this state code in our system. So what we did was we extracted an utility we have on the web called create screen. And this create screen allows us to define, okay, what's the name of the screen? So it's very good, useful for debugging. What's the query, which would be used to go to data? What are the query variables for this query? Which is the component this screen is going to render? And we just pass with this component, the data and the params. What type of screen is this? In our application, we have three types of screen. A screen which is like push screen, which we just push it back. We have an action sheet, which just opens like a action sheet. And we have an overlay, which is an overlay. Also, there is a couple of other options like the screen background. Different screens in our system has different background. What's the title in the navigation? And there is this safe area, which is the iPhone X style of no home button. And how do we do in different screens? So every developer can just build a screen with calling this command. So what we have is we have the screen, which is create screen. It goes to the screen index and then goes to the app. And here's an example screen. This is kind of the home screen we are having. We just have a query with its variable. And then we have the component. And we use two hooks to set up the layout navigation. We set up the push notifications. And we render an infinite scroll of items. And again, GraphQL is the thing which also connects everything to our app. So in the back end, we use Rails. And we export the GraphQL. The GraphQL goes to Apollo. And Apollo can help us generate TypeScript. So using the Apollo Code Gen, we can take the fragments from GraphQL and convert them into types in TypeScript. And we can use them in our pages. And this gives us this type safety. And the nice thing about it is we can nest those. We can attach fragments with more fragments. And this is how we start. The way we start is from the query from the page. And then it gets the fragments. And it goes down to the component level. And for me, that's still magic. It's very magical to go to the back end, test the change, and the mobile app complains that this field doesn't exist anymore. Or this is null, but you are expected not to be null. And this connects the whole app. Another cool trick we use is called routes. I haven't seen this in React Native app. So I think it might be very useful for everybody. So what we have is we have this file where we just export this routes list of, OK, we basically say our screens are routes. So for example, we have a login profile around. So because in our app, we have a screen, you can go to pretty much any other screen. You can just say, OK, this is the description where this thing would go. And we have those hooks to navigate between the different screens. And you can say, OK, I have a route. Go back. Login screen, profile screen. And I can use this in a button. I can say I have a button. And it navigates to the product with ID5. And this is a very common thing. So what we do is we have built into our core button component. And our core button component just has this. So the next step I'm going to talk about is the components. Those are basically things that are used in more than two screens. And more than one screen, actually. Sorry. So we use the same component as directory, where the route folder shows all the public stuff. The private stuff is all nested. Some components even have like 4 to 5 levels of components. We keep the GraphQL here. The mutation, the index is where we export. And we have pretty common components. We have our own version of text. So we have consistent text sizing. We have this spacing structure. The other thing we have is, again, the usual buttons. Like with us, buttons are not only style, but buttons are also functionality. So we can say, okay, button can link to a page. Button can, if the function which is clicked on press returns a promise, the button doesn't allow you to tap it again. We also have built-in confirmation, require login, and also it's built in with GraphQL. So the button can execute a mutation and handle the mutation results. Also, we have packages for button. We have a button which is just text, a button which is an icon, and solid, and an outline button. For layouts, we have abstracted out the built-in flex system in Apollo, in React Native, because we basically got tired of writing the same style over and over again. So we have this flex row and flex column, and a couple of helpers like flex expand, which expands the flex to the cold screen, a grid, which is those, those, those, those, those, and a text, which is basically a hack to have texts float properly with React Native. And as I mentioned, we have utilities, styling, and domain. So we actually have also domain components. Like this is the homepage, and if we see the post item, it has a bold button, and this bold button uses the button component, but also the post item uses the bold button and the button. So we have this deep nesting of utility components and domain components. It's kind of like an atomic design, just kind of, with our case, we just say, okay, we have the generic components, and then we have the domain components, which are related to a domain entity. Usually, the difference is one has fragments, the other doesn't. And the final thing I wanted to share is the utilities. I want to tell about some of the utilities we have in our system, and they just live in utilities, in hooks, and in styles. We split it into three folders because for engineers, we have found out it's good to have a dedicated place for things like hooks, and we know that the files there are very special. So I want to focus on styling. One problem which we were writing a lot of styling for was margins and paddings. So what we did was we added this helper, which we use in our core component, which is we have those properties for margin and padding. So here is something that on the web, we use the flex gap property, but this is not something we can implement with React Native. And because of this, we just have this styling helper where we have margin, bottom, padding, and all the associations, and every component can have this spacing prop, so we can add every spacing to those components, and this was very useful. The other thing which was part of the new feature set was having support for dark mode, which is a cool feature. So we use this package called React Native Dynamic, and we created a wrapper around it where you can use this dynamic style sheet, and depending on the color, you decide what color you are using. And we have a couple of helpers and style themes, like for example, use color background, and we have this color map, which is the dynamic value. So on text with this color, the sub-tile text with this color, and every color in our app is defined to this color and has to go to React Native Dynamic. So we actually have a built-in support for dark mode. And this is basically how the whole application combines. We built on the foundations, which are the utilities, and we have a lot more smarter utilities. There are a lot more internal helpers, but the one I showed you, I think, are the most memorable and most useful, and I haven't seen a lot of those used in other applications so far. And then on top of them, we build this core set of components, which is, we have this core set, which is things like buttons, text, the infinite scroll, stuff that they don't care about the domain logic. And then we have the domain component, which is like post button, post-roll button, post item, post thumbnail, which are basically things with fragments, things that they start from GraphQL. And then this, the whole thing gets combined into the pages, which are wrapped with this helper create page. So to recap that, if you want to take some takeaway from my talk is, yeah, GraphQL is awesome. It helps a really nice to design a system, which use the GraphQL everywhere. From screens, create screen is something which I am surprised I haven't seen many people use the pattern like that or the screen scalper. And for components, notice how we have isolated a lot of our dependencies. We use directory as construction, and we have this concept of domain component. So yeah, thank you very much. And that's all from me. Thank you.
