Read on Twitter
I& #39;ve started reducing the amount of interfaces I use in projects actually. I write smaller, re-usable, composable functions (thanks Elixir for teaching me this), and then in their type signatures I only write the keys on the object that they use.
Quick thread: https://twitter.com/mjackson/status/1385414736511070211">https://twitter.com/mjackson/...
Quick thread: https://twitter.com/mjackson/status/1385414736511070211">https://twitter.com/mjackson/...
So let& #39;s say we& #39;re building an app and we have a User type that looks like the following. A user has a name, username, email, a profile pic, and various other things. This list only grows over time.
Here& #39;s a component for rendering the user& #39;s avatar / profile:
Here& #39;s a component for rendering the user& #39;s avatar / profile:
So here& #39;s what it would look like to use this component, passing in some dummy data:
One of the things you& #39;ll notice here, though, is that this component *isn& #39;t using half of the data we& #39;re passing in*. It really only needs a name, a username, and a URL of the profile pic.
One of the things you& #39;ll notice here, though, is that this component *isn& #39;t using half of the data we& #39;re passing in*. It really only needs a name, a username, and a URL of the profile pic.
So what we& #39;ve done by reusing this interface here is limit the reusability of our component.
For example, say we had & #39;bots& #39; that could join our app later. They need their own avatars rendered out. However the following would not work:
For example, say we had & #39;bots& #39; that could join our app later. They need their own avatars rendered out. However the following would not work:
Even though we don& #39;t need the email passed in, Typescript still relies on it.
Even moreso, relying on this single & #39;User& #39; interface for every part of our app would break things down the road. Adding or removing fields to it would require us to make more changes than needed.
Even moreso, relying on this single & #39;User& #39; interface for every part of our app would break things down the road. Adding or removing fields to it would require us to make more changes than needed.
So in my mind, the right solution is something like the following:
Thanks to Typescript& #39;s structural typing, we can pass in the entire & #39;bot& #39; object and Typescript ensures that that& #39;s sound.
Thanks to Typescript& #39;s structural typing, we can pass in the entire & #39;bot& #39; object and Typescript ensures that that& #39;s sound.
We also don& #39;t worry about the *size* of the profile pic here: whether we need to render a large or a small URL is up to the caller.
The function is also *much* more readable now, and it makes it clearer to the user what exact information on the object is used.
The function is also *much* more readable now, and it makes it clearer to the user what exact information on the object is used.
