Twitter | Search | |
Satyajit Sahoo
When building components, boolean props may not be always the best idea. For example, say you have a button with a primary prop (for primary color), and in future, you needed another color (accent), it's now possible to have a combination of props which doesn't make sense.
Reply Retweet Like More
Tarang Hirani Jul 6
Replying to @satya164
So how do you go about this use case?
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @tarang9211
Have prop 'mode' or something which accepts an enum. <Button mode="accent" /> etc.
Reply Retweet Like
Varenya Jul 6
Replying to @satya164
Finite State machines or just use a type prop and use enums to constrain it to the the types ur expecting
Reply Retweet Like
Andrey Los πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡± Jul 6
Replying to @satya164
I think programmers are smart enough to not be that dumb to use both of them :D So I don't see any issues with this approach. Although color props with enum is a bit better and safer, yes, but looks uglier a little.
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @RIP212
No matter how smart, everyone makes mistakes :) Also, don't forget beginners who are mostly copy/pasting things and learning.
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @varenya90
If you use a static type checker, yes, but not everyone does that.
Reply Retweet Like
Alejandro [...πŸ‘¨πŸ»β€πŸ’»] Jul 6
Replying to @satya164
My thinking on that is: make it simple first, if you need more variants, then go for another approach.
Reply Retweet Like
Oleg Jul 6
Replying to @RIP212 @satya164
He points out to a very popular and important problem - impossible states. It is a real problem and programmers are not smart enough. Once you have an api that allows impossible states, it is unavoidable that you get there, even if by accident. "Make imposible states impossible"
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @oleg008 @RIP212
I love that talk
Reply Retweet Like
Manuel Bieh 🐝 Jul 6
Replying to @satya164
So? What's the problem? Define priorities. If `primary` AND `secondary` (or `accent`) is set, `primary` always wins. I see no problem here. You can also combine them. E.g. `<Button primary outlined />` - and you get an outlined button in the "primary" colors.
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @aganglada
For prototyping, yes. Otherwise changing the API of one heavily used component can result in touching a lot of places which is often not good.
Reply Retweet Like
Alejandro [...πŸ‘¨πŸ»β€πŸ’»] Jul 6
Replying to @satya164
You're probably never gonna get it right first time, and if you do make overcomplicate your API, you will end up with code you don't need. You will always have time to change it. Start small, always.
Reply Retweet Like
Abhimanyu rathore Jul 6
Replying to @satya164 @semanticui
1. booleans are good as long as you use them for unique properties 2. for properties such as color- string or enum(if typescript) will be better choice Below snapshot is taken from react type definition
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @aganglada
It's easy to follow this approach when you're working on a self-contained app. But it's not true when you're making a reusable component library. You don't want to introduce breaking changes for every new feature you add.
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @aganglada
Though I don't agree that using an enum vs boolean is overcomplicating the API. An API is overcomplicated when it takes more time to understand the code, which is not the case here.
Reply Retweet Like
Alejandro [...πŸ‘¨πŸ»β€πŸ’»] Jul 6
Replying to @satya164
I'm not saying you need to introduce braking changes on every new feature, but this is software and software progress with the time. Although, if you are doing a reusable component library, then I agree it has to be more flexible.
Reply Retweet Like
Satyajit Sahoo Jul 6
The `disabled` prop might be a better example here. You know you will never need another state other than disabled and not disabled. But for shape, you might actually want a different one, eg, MD docs have a diamond shape. Though it's impossible to predict everything in advance.
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @aganglada
Yes. Context is everything. I posted this when working on a component library and I meant it in that context :)
Reply Retweet Like
Satyajit Sahoo Jul 6
Replying to @ManuelBieh
If your code needs additional context (such as priorities) to understand what it does, it's not a good API. A good API should prioritize clarity over terseness. Combining primary and outlined is not a problem here. It's about props which control the same aspect.
Reply Retweet Like