Next up on a task list is creating a search form component. As far we've been doing all our work in a single component, or app component. In react, you don't want a single component to be handling too much. Just like functions. If you find a component is doing too much, it's usually a good sign that it can be broken into smaller components. Having a look at our app component, I think the search form is a good candidate to be broken out into its own component.

Let's start by creating a new file named search form dot j s. For now search form will be a bare bones functional component that returns an h1 containing a greeting. This will be a temporary placeholder until we move the form element over from the app component. It's also a common pattern that the default export from a component file will be the component itself, which is the pattern we'll be following. In order to use the search form component from app you'll need to import it like you would any other file next lesson component to the render method and see if it works. Nice, we can see our component rendering, but it's not doing a whole lot. Let's copy the search form from app into the search form component file.

Once we save this, we can expect to see some errors as we're still referencing methods and state from the app component. The first error we get is can't read property on search submit of undefined. This is because the answered submit method is referenced in our app component. So how do we access methods in the app component from the search form component? This is where props are your friend. Let's go back to the app component.

Let's add a new prop to the search forum named on form Submit. And what we'll do is pass apps reference to answer submit as the value of the on form submit prop. Now back in search form, instead of calling on search submit, we will access the components props and use the new on form submit prop instead. Which Don't forget is a reference to the answer submit method in app. Now when we save we can see that the answer submitted Gone, but now we have a new error, but this time it's complaining about on search change being undefined. Similar to before, I'm going to start by adding a new property search form named on search value change, and then pass apps reference to answers change as the value.

Then back in our search form, we'll call the on search value change prop in place of the answers change. Now when we save the air is replaced with a new one complaining that the state is undefined. By now you should know the routine, I'll add a new property search form named is searching and pass the is fetching joke state as the value. While I'm at it, I'm going to polarize the name to is fetching jokes since we're now fetching more than one joke and back in search form a place the reference to his fetching joke with his searching prop. Also, I just noticed we only disable the I'm feeling lucky button when a searching is true. We should be doing the same for the search button.

So let's add the disabled prop there as well. Well, it looks like that we fixed the errors but I can see that we're still referencing search jokes from the I'm feeling funny button If I go ahead and Click on it, you can see that we get an error cannot read property search jokes of undefined. This appears to be your last leftover reference to the app component. So let's go ahead and fix it. I'm going to start by copying the existing onClick value as we will be needing it. Then I'm going to add yet another property search form named on single search click for the value I'll paste in the onClick value I copied over before.

Now in search form, we'll use the on single search click prop instead. Not save and see how things are looking. OK, looks like the I'm feeling funny button is working again. The search is looking good as well. Now that everything's working again, let's have a closer look at the new component we created. The render method looks much more tidy now with all the former logic hidden away in the search form component.

Another added bonus is the search form component doesn't handle any data on its own anymore. All references to data are handled through props and callbacks. You may have noticed I've been keeping my prop names as generic as possible. Not having your prop names tightly coupled to your data makes your component more versatile. This way if we end up changing our app to search something other than jokes, we don't have to rename any of our search form problems. This type of component is sometimes referred to as a dumb or presentational component in the React community.

These components don't care what type of data is being passed to them, they're only concerned with how they look. This creates a component that is much easier to reuse. For example, if we wanted our search form to search for something other than jokes, we just have to update the props and callbacks to pass in different data instead of creating a whole nother component. With a search form component complete, we can cross that one off our list. Next up we'll be doing some refactoring and cleanup