Cool. Cool cool cool

It’s a bear dance!

Unfortunately, “sauron [command]” still won’t see the Jia Tan backdoor obscured in the shadows, nor the_ring.yml that you’re piping to /dev/null

Imagine being so disliked that it becomes the goal of elderly voters to live long enough to vote against you, nevermind that it’s a former president

When the enum reaches your JSON, it will have to be a string (as JSON does not have a dedicated “enum” type). But it at least ensures that languages parsing your JSON will should have a consistent set of strings to read.

Consider this small bit of Elm code (which you may not be an Elm dev, and thats okay, but it’s the concept that you should look to get):

-- A Directions "enum" type with four options:
-- North, East, South, West
type Directions
    = North
    | East
    | South
    | West

-- How to turn each Directions into a String
-- Which can then be encoded in JSON
directionsToString : Directions -> String
directionsToString direction =
    case direction of
        North -> "north"
        East  -> "east"
        South -> "south"
        West  -> "west"

-- "Maybe Directions" since not all strings can be parsed as a Directions.
-- The return will be "Just <something>" or "Nothing"
directionsFromString : String -> Maybe Directions
directionsFromString dirString =
    case dirString of
        "north" -> Just North
        "east"  -> Just East
        "south" -> Just South
        "west"  -> Just West
        _       -> Nothing

The two functions (directionsFromString and directionsToString) are ready to be used as part of JSON handling, to read a String from a key and turn it into a Directions enum member, or to turn a Directions to a String and insert the string to a key’s value

But all that aside, for your restructuring, and keeping with the license plate example, both type and license number could be contained in a small object. For example:

{
    ...
    "licensePlate": {
        "type": "government"    <- an enum in the language parsing this
                                   but a string in JSON
        "plateNumber": "ABC123"
        ...
    }
    ...
}

If its something that represents mutually exclusive states, like the license plates examples (Gov’t, Embassy, Learner), an enum like 4wd mentioned is a better idea than many boolean keys. This would also be the switch/case question you posed. For a “regular case”, I would include that in the enum, but if you create an enum that only contains “special cases”, you can always set it to null.

On the case of booleans, I would suggest avoiding them unless it is necessary, and truly a binary (as in, two-option, not binary numbers), self-contained-in-one-key thing (obligatory anti-boolean video). If the use case is to say what a different key’s object represents, you don’t need it (see: enums. You’ll thank yourself later if you add a third option). If the use case for using it is saying another key contains value(s), you don’t need it. Many languages can handle the idea of “data is present, or not present” (either with “truthy/falsey” behavior interpreting “data-or-null”, or “Maybe/Option” types), so often “data-or-null” can suffice instead of booleans.

I would suggest trying to always include all keys of a present object, even if it’s value is null or not applicable. It will prevent headaches later when code might try to access that key, but it isn’t present. This approach might also help you decide to reduce the quantity of keys, if they could be consolidated (as in taking booleans and converting to a state-like enum, as mentioned above), or removed (if unused and/or deprecated).