1

Say I have a Person object. I need to ask the user to choose from a list, which laptop they have.

They can also choose the option "My product isn't listed here".

Now the Person object will look like:

{
  name: 'John',
  laptop: 'Dell'
}

If the user selects "My product isn't listed here", I can store it as:

laptop: 'OTHER'

But this is not recommended, as I shouldn't mix the laptop name string with the "other" string. In the code I'll be checking against the string "other", like a magic constant, which doesn't seem right.

I can't leave it as laptop: null because then I wouldn't know if the user selected "other" or did not make a choice at all.

Another option is to have a separate field like:

{
  name: 'John',
  laptop: null,
  laptopFoundInList: false
}

With this, I'll have to maintain 2 fields for the same thing.

I'm sure this is a very common problem. What's the correct convention to store such information?

3
  • 2
    The "correct" way is determined by further use of this information. Why do you need this information, and what will be done with it?
    – mtj
    Apr 1, 2020 at 4:24
  • @mtj it will control the flow of my app. For instance, if it's Dell, Asus, or something, I'll show a link to go to the company's website. If it's "other", I'll hide the section completely. If the user hasn't chosen anything yet, I'll show a CTA for the user to choose.
    – Kartik
    Apr 1, 2020 at 4:34
  • "code I'll be checking against the string "other", like a magic constant" - well, confine the special case to one place in code, the one place where you have to check, and then either concoct some scheme to treat it polymorphically, or treat the two differently/separately if that makes more sense. Apr 1, 2020 at 8:24

2 Answers 2

1

After your comment, the value "laptop" basically is used for a switch on how the user interface is structured, along the lines of:

"dell" -> include dell-specific interface
"hp" -> include hp-specific interface
"other" -> don't include anything / include empty section
null -> include selection interface

I cannot see any reason here, why "other" should not be a string, just like the other selections.

1
  • "other" is fine. Slightly better might be "____other____" or "__". Which ever you decide should definitely be defined in a constant.
    – user949300
    Apr 1, 2020 at 5:07
0

A single string seems to not be enough to represent what you need.

I would promote the laptop string to an interface.

interface ILaptop
{
  string Name {get;}
  string WebsiteUrl {get;}
}

Now the person entity can use this directly.

interface IPerson
{
  string Name {get;}
  ILaptop Laptop {get;}
}

In the db it would be like this:

Persons: ID, Name, LaptopID(nullable)
          1, John, 1
          2, Jack, 2
          3,  Bob, null

Laptops: ID, Name, WebsiteUrl(nullable)
          1, Dell, https://dell.com
          2, Other, null 

Selection is now matter of choosing one item from a codelist (of laptops). "Other" is now just an item of the codelist like every other, execpt it has no website.

A person having LaptopID=null means he did not choose yet. A person having Laptop->WebsiteUrl=null means there is no link to be displayed.

Of course there may be situations when this is not appropriate (ie. if it was allowed to buy those laptops, it would be weird to buy the "other" laptop, which is not really a laptop), but for your provided use case, this should be absolutely fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.