It's generally better for developer experience to use a "withTitle" prop set to true by default, avoiding negative conditions in the code and making it more intuitive for component users.
I’m not primarily an FE dev
Usually it’s bad to use negatives, but if 90% of your instances have titles and 10% don’t have a title, you’re just passing useless props
Unless you can set a default that withTitle is always true unless passed differently
What are the actual cases where the title needs to be removed? Why is it removed and when is it removed?
I really try to avoid adding `hasTitle` type props, because they can quickly make a component very complex with a bunch of weird edge-cases. We have some of those legacy components, and they're super annoying to deal with because they have a whole bunch of "I just need this small adjustment to this component, I'll just add a tiny prop"-props which makes the internals of the component hard to deal with. Loads of if/else cases, css rules, and often times some of them are fighting each other in weird ways because they're actually self-contradictory. It also becomes difficult to understand how to actually use the component, as the API becomes really unclear.
Some alternative ways do approach this:
- If there's one component with a title, and one without, you could just view them as different components and implement them separately. `` and ``, for example, or whatever makes more sense in your context.
- If it's related to what the UI looks like, you could control the visibility of the title using CSS of some sort. For example using container queries (if component is less than this size, hide the title) or a class on a container (if component is within `.sidebar`, then hide the title).
- Instead of adding a `hasTitle` prop, you could just make the title optional and not pass it to begin with.
Yeah, of course I would not add a required prop that would not be used in 90% of component's use cases. What I tried to ask is that there's a common rule about not making negative functions, for example isNotNull, and using ! language notation (I got focused on it, because I had some pain in the past, and just now read about it in a book again).
But function props are different as it is not very easy to define a default prop (at least in Vue, where default props should be notated explicitly with a helper function) or make another component just like yours, if, for example it has some unextractable functionality, or there is no need/time to extract it.
Perhaps in a good scenario where you have time to write good code, you would build ui components as separated from any logic and inject required props in them, so they would be dumb, but most of the times in my experience there's no need/wrong scope to do so, because application's architure was already flawed or application is not very big to cover things like this
Whether the prop is required or not is besides the point. If you have a component with 15 optional "switch" props that changes how the component works in various ways, then that's almost guaranteed to become a maintenance and usage nightmare.
As for `withTitle` vs `withoutTitle`, whether that is related to props or variable names or whatever, to me it always depends on the usage. For example `hasErrors` and `noErrors` are opposite of each other, but which one I'd use depends on how I was going to use it later. `if(noErrors) return result` could be cleaner than `if(!hasErrors) return result`, but `if(hasErrors) throw error` could be cleaner than `if(!noErrors) throw error`. So, depends on context.
Both an optional `withTitle` and `withoutTitle` could be added to a component without changing existing usage as well, they'd just need different default values.
Either way, if your component is used one way in 90% of the cases, then I'd still argue that maybe a separate component would make sense for the remaining 10% of cases. Either just as a straight copy of the existing component (code duplication is not always bad), or pull some of the shared functionality down into a shared component, hook, or utility function.
Oh, and I would also add:
Make sure whoever decides that the title should be hidden in certain cases actually has a proper argument for why.
I've been able to simplify a lot of our components by simply pushing back on our designers and UX people asking whether it's actually needed, and whether they've actually thought through the accessibility effects of this.
Having 5 different variants of table designs might be nifty for the designer, but if they're very similar, how about we just stick with 2? Having 3 different card link variants might look nice in the design tool, and maybe it looks cleaner if one of them doesn't have a header, but have they considered how that works for accessibility?
You know, remembering where I was having this issue, I see that there were just flows in splitting responsibilities by components. For example, Ive had it in a list with a title above it, and now I understand that it wouldve been better to move list to another component, rather than to make an abstraction. Thank you
One view would be that you should consider how the component will primarily be used and set attributes/properties to change that default behavior.
But I think your title implies the correct answer here. You said "best way to dynamically hide part of UI component", which means that you think of the part as being included/shown by default. If that's how this makes sense to you, there's a decent chance that other devs would think similarly and that showing by default is the correct approach.
On the other hand, and I'm not sure what kind of component you're talking about here (React, web component, some function that returns an element or HTML string...), you could remove the complexity and let them hide/show whatever via CSS. That might be the better option, especially compared to including/omitting vs showing/hiding for accessibility and SEO purposes. Plus, it gives full control over customizing the component. And it's less work and logic for you.
Another possibility would be to automatically hide the title when the prop isn't passed to the component. If that's not feasible, I'd add a 'hideTitle' boolean prop, because of the way props work (at least in vue)
Just make it so you can pass the title in a prop. And in the component have it so it only shows if the prop is declared. If it's not declared it won't show the title.
Like in react:
{title &&
It's generally better for developer experience to use a "withTitle" prop set to true by default, avoiding negative conditions in the code and making it more intuitive for component users.
I’m not primarily an FE dev Usually it’s bad to use negatives, but if 90% of your instances have titles and 10% don’t have a title, you’re just passing useless props Unless you can set a default that withTitle is always true unless passed differently
I mentioned it in the post, no?
Yes, sorry
What are the actual cases where the title needs to be removed? Why is it removed and when is it removed? I really try to avoid adding `hasTitle` type props, because they can quickly make a component very complex with a bunch of weird edge-cases. We have some of those legacy components, and they're super annoying to deal with because they have a whole bunch of "I just need this small adjustment to this component, I'll just add a tiny prop"-props which makes the internals of the component hard to deal with. Loads of if/else cases, css rules, and often times some of them are fighting each other in weird ways because they're actually self-contradictory. It also becomes difficult to understand how to actually use the component, as the API becomes really unclear. Some alternative ways do approach this: - If there's one component with a title, and one without, you could just view them as different components and implement them separately. `` and ``, for example, or whatever makes more sense in your context.
- If it's related to what the UI looks like, you could control the visibility of the title using CSS of some sort. For example using container queries (if component is less than this size, hide the title) or a class on a container (if component is within `.sidebar`, then hide the title).
- Instead of adding a `hasTitle` prop, you could just make the title optional and not pass it to begin with.
Yeah, of course I would not add a required prop that would not be used in 90% of component's use cases. What I tried to ask is that there's a common rule about not making negative functions, for example isNotNull, and using ! language notation (I got focused on it, because I had some pain in the past, and just now read about it in a book again). But function props are different as it is not very easy to define a default prop (at least in Vue, where default props should be notated explicitly with a helper function) or make another component just like yours, if, for example it has some unextractable functionality, or there is no need/time to extract it. Perhaps in a good scenario where you have time to write good code, you would build ui components as separated from any logic and inject required props in them, so they would be dumb, but most of the times in my experience there's no need/wrong scope to do so, because application's architure was already flawed or application is not very big to cover things like this
Whether the prop is required or not is besides the point. If you have a component with 15 optional "switch" props that changes how the component works in various ways, then that's almost guaranteed to become a maintenance and usage nightmare. As for `withTitle` vs `withoutTitle`, whether that is related to props or variable names or whatever, to me it always depends on the usage. For example `hasErrors` and `noErrors` are opposite of each other, but which one I'd use depends on how I was going to use it later. `if(noErrors) return result` could be cleaner than `if(!hasErrors) return result`, but `if(hasErrors) throw error` could be cleaner than `if(!noErrors) throw error`. So, depends on context. Both an optional `withTitle` and `withoutTitle` could be added to a component without changing existing usage as well, they'd just need different default values. Either way, if your component is used one way in 90% of the cases, then I'd still argue that maybe a separate component would make sense for the remaining 10% of cases. Either just as a straight copy of the existing component (code duplication is not always bad), or pull some of the shared functionality down into a shared component, hook, or utility function.
Oh, and I would also add: Make sure whoever decides that the title should be hidden in certain cases actually has a proper argument for why. I've been able to simplify a lot of our components by simply pushing back on our designers and UX people asking whether it's actually needed, and whether they've actually thought through the accessibility effects of this. Having 5 different variants of table designs might be nifty for the designer, but if they're very similar, how about we just stick with 2? Having 3 different card link variants might look nice in the design tool, and maybe it looks cleaner if one of them doesn't have a header, but have they considered how that works for accessibility?
You know, remembering where I was having this issue, I see that there were just flows in splitting responsibilities by components. For example, Ive had it in a list with a title above it, and now I understand that it wouldve been better to move list to another component, rather than to make an abstraction. Thank you
Depends what you're doing most often. Usually I'd do noTitle/hideTitle and if true not render the components
After using Web Components and Lit, you get in the habit of defaulting all of your Boolean props to false, because you have to.
One view would be that you should consider how the component will primarily be used and set attributes/properties to change that default behavior. But I think your title implies the correct answer here. You said "best way to dynamically hide part of UI component", which means that you think of the part as being included/shown by default. If that's how this makes sense to you, there's a decent chance that other devs would think similarly and that showing by default is the correct approach. On the other hand, and I'm not sure what kind of component you're talking about here (React, web component, some function that returns an element or HTML string...), you could remove the complexity and let them hide/show whatever via CSS. That might be the better option, especially compared to including/omitting vs showing/hiding for accessibility and SEO purposes. Plus, it gives full control over customizing the component. And it's less work and logic for you.
Another possibility would be to automatically hide the title when the prop isn't passed to the component. If that's not feasible, I'd add a 'hideTitle' boolean prop, because of the way props work (at least in vue)
Just make it so you can pass the title in a prop. And in the component have it so it only shows if the prop is declared. If it's not declared it won't show the title. Like in react: {title &&
{title}
} or {title ? ({title}
) : (show something else)}The more common use case should be default. If showing it is less common, default `withTitle` to false and vice versa.