Worried about pluck operator deprecation

[DarioSoller]

I stumbled over an use case, in which the pluck operator has advantages over the map with optional chaining equivalent. In case you use a dynamic property key and not a string as the pluck function parameter, you can't catch that nicely with optional chaining. Super basic example:

// OLD WAY
const exampleObj1 = {a: 1, b: 2, c: 3};
const exampleObj2 = {a: 4, b: 5, c: 6, d: 7};
const objKeys = Object.keys(exampleObj1);
from(objKeys).pipe(
  mergeMap((key) => of(exampleObj2).pipe(
    pluck(key),
    map((value) => ({ key, value }))
  )
)

compared to

// NEW WAY
const exampleObj1 = {a: 1, b: 2, c: 3};
const exampleObj2 = {a: 4, b: 5, c: 6, d: 7};
const objKeys = Object.keys(exampleObj1);
from(objKeys).pipe(
  mergeMap((key) => of(exampleObj2).pipe(
    map((value) => ({ key, value:  exampleObj2[key] ? exampleObj2[key] : undefined}))
  )
)

• Old version leads to much more readable and clean code. Also mentioned here.
• New version throws an error in case of trying to access a non-existing property. Therefore additional condition is needed to catch that and optional chaining does not help in this case as far as I know. Instead pluck simply returned 'undefined', but did not throw an error, which seems to be more convenient IMO.

For me the deprecation of the pluck operator would mean a loss, especially when working with deeply nested data structures and you maybe do not even know which property key names come along.

[kwonoj]

1. The recommended equivalent is use optional chaining as you said. Any reason you can't use it?

map((value) => ({ key, value:  exampleObj2?.[key] }))

2. Deprecation does not mean you are not allowed to use those implementation anymore. It simply means core rxjs api surface will not maintain - but the implementation of pluck is a variant of map operator less than 10 lines:

   rxjs/src/internal/operators/pluck.ts

   Lines 94 to 104 in afac3d5

   	return map((x) => {
   	let currentProp: any = x;
   	for (let i = 0; i < length; i++) {
   	const p = currentProp?.[properties[i]];
   	if (typeof p !== 'undefined') {
   	currentProp = p;
   	} else {
   	return undefined;
   	}
   	}
   	return currentProp;

If you feel to keep it in your codebase, you can create custom operator anytime.

The main reasoning to revisit core api surface is we are trying to balance around surfaces of api itself, and triviality of implementation, and usecases including potential userbase who relies on it.

[DarioSoller]

Thx for your fast reply. I seriously did not know that the property access after an optional chaining operator can be done via exampleObj2?.[key]. I have to admit that I still need to get used to how this looks though. Also thx for reminding me on the custom operators again.