Vfrdtyky

A little bit of backstory:

We're trying to address a bug on a local library we have.

I was trying to convince the senior developers of changing naming convention when using word like these:

enable disable hide unhide

because they were using

enable disable hide undelete

We discussed the fact of this being a breaking change and will stop other products from working.

So it was disscused to add the unhide without taking the undelete out so that it does not break anything and in the process, if the user uses either unhide or undelete they should still do the same in theory.

Here comes the programming problem now:

This is my function:

toggleAction(data._id, 'undelete', (err, data) => { // cool stuff }, false)

How can I continue to pass a string (without converting to an array or object) but also start passing 2 values so that the changes have to be made in this file and not in the projects side validating, etc.

Another thing, this function will default if the switch case does not found the string.

Also thought about sending two request at the same time but that's just bad programming.

Also though of fallback to another request with the other naming, but since the switch case will still default if it's not in the options, it will not throw an error to actually do the callback for the next function.

What do you guys think is the right approach for something simple and yet capable of breaking a lot of things.

Thanks in advance.

Kinda opinion based, but it's the wrong approach imho.
I would change the word undelete to unhide only on the rendered websites and keep the internal API the same way until the senior devs can fix the breaking changes.
So the user would see the word 'unhide' on their screen, but the API will still stay 'undelete'.

In more complex applications, you'd use an enumeration list so you can change the labels as many times as you want:

const enum_options = [

  'enable',

  'disable',

  'hide',

  'show'

];

// 3 is the index of the word 'show'

toggleAction(data._id, 3, (err, data) => { // cool stuff }, false)

That way the API never has to change when you change the labels to any word you desire. Which will also help alot if you ever have to support multiple languages.

ps:

1) if this is a breaking change, there's an issue with the architecture used.
Fix the issues instead of adding even more fragile code. Switching to like using a string 'undelete-unhide' will still need alot of api changes if the entire app has the word 'undelete' written everywhere at the moment.

2) The opposite of hide is usually 'show', not unhide.