When I use the option 1 to make my business types(T0
, T1
, etc...), I found I repeated Pick<ChannelBaseInfo1, 'channelCode'>
too many. So maybe option 2 is better? Please give me some suggestion. Thanks.
// Option 1.
type ChannelBaseInfo1 = {
channelCode: string;
channelName: string;
}
// Use Pick utility type
type T0 = Pick<ChannelBaseInfo1, 'channelCode'> & {
t0: string;
}
type T1 = ChannelBaseInfo1 & {
t50: string;
}
type T2 = Partial<Pick<ChannelBaseInfo1, 'channelCode'>> & {
t2: any;
}
// a lots of types using ChannelBaseInfo1 or Pick<ChannelBaseInfo1, 'channelCode'>
// ...
type T100 = Pick<ChannelBaseInfo1, 'channelName'> & {
t100: string;
}
// Option 2.
type ChannelCode = {
channelCode: string;
}
type ChannelName = {
channelName: string;
}
type ChannelBaseInfo2 = ChannelCode & ChannelName;
type T101 = ChannelCode & {
t101: string;
}
type T102 = ChannelBaseInfo2 & {
t102: string;
}
type T103 = Partial<ChannelCode> & {
t103: string;
}
// a lots of types using ChannelBaseInfo2, ChannelCode and ChannelName
// ...
type T200 = ChannelName & {
t200: string;
}
Top comments (2)
small interfaces.
and the
ChallelBaseInfo
should be namedChannelInfo
and the properties should be namedcode
andnumber
, otherwise you create a lot of stutter. it might help if you try reading your code out loud 😉Yeah. I understand I don't need to add
channel
prefix to each property likechannelXXX
pattern because we already have theChannelInfo
context. That's not the point. This is just a demo.Small interfaces like this:
Actually, this will raise another question. How to name the types. If the
code
property is a union type rather thanstring
. How should we name theChannelCode
object type?In order to distinct the
ChannelCode
union type and object type names, I add a suffix likeDTO
. There are some choices:Or,
How will you handle this situation?