‫When we build a reusable component,
‫like the one we are currently building,
‫we should carefully think
‫about what props the component needs.
‫So let's now shortly look at how to think about props.
‫So, first of all, as we start working on our components,
‫we should get into the mindset
‫that any component is always created by someone,
‫and always consumed by someone.
‫Now, when you're working on your own,
‫the component creator and consumer,
‫is, of course, the same person.
‫But if you're on a team,
‫those might very well be different developers.
‫But in any case, it's always a good idea
‫to think in terms of there being a creator
‫and a consumer of a component,
‫so, different entities, even if it's just yourself.
‫So, basically, the creator
‫is the person building a component,
‫and defining what props the component can accept.
‫While the consumer uses the component
‫somewhere in the application,
‫by specifying values for the props.
‫Now, the reason for the separation
‫between creator and consumer,
‫even if you're just working on your own,
‫is that if we have this mindset,
‫we can think of the component's props
‫as the public API of the component.
‫So, as a component creator,
‫when we choose what props
‫the consumer is allowed to pass in,
‫we are essentially defining
‫the public interface of our component.
‫And, at the same time, we are choosing
‫how much complexity of the component
‫we want to expose to the consumer of the API.
‫Because, in the end,
‫a component is basically just an abstraction.
‫So, we are encapsulating a part of the UI
‫and the associated logic into a component,
‫and allow consumers
‫to interact with that component via props.
‫And that's it.
‫That's basically what creating a new component is.
‫But, anyway, when we decide about
‫what props to allow in a component,
‫we need to find a good balance on how strict we want to be.
‫So about how many props we want to enable for configuration.
‫For example, let's say
‫we're building a weather component,
‫so a component that simply displays the weather.
‫We could make it extremely simple,
‫for example, only allowing one prop.
‫So, for the location
‫for which the consumer wants the weather.
‫Now, this might be perfectly fine,
‫but it might also make the component not flexible enough,
‫or maybe even straight out, useless for the consumer.
‫On the other hand,
‫we could allow props for the URL of the weather data,
‫the number of days,
‫whether it should be daily or hourly,
‫how many days, which temperature to unit,
‫what data should be displayed, and so on.
‫I could think of really 20 other props here.
‫But the point is that exposing so many props,
‫might make the component
‫way too hard to use for the consumer,
‫because we're exposing too much complexity.
‫And speaking of complexity,
‫you'll end up with very complex code,
‫if you want to allow so many props.
‫So, when deciding on the right API for your components,
‫try to strike the right balance
‫between too little and too many props,
‫and a balance that works well,
‫for both the creator,
‫and the consumer of the component,
‫based on the project's needs.
‫Now, if for some reason
‫you really need to expose so many props,
‫make sure to at least provide
‫some good default values for many of them.
‫Okay, and as always, this will come to you with practice,
‫but I thought that it was quite important
‫to get you into this mindset
‫of distinguishing between component creators and consumers.
‫And so with that, we're ready to put this into practice.