feat(state): improve DX by logging undefined keys in selectSlice

[mrkpks]

Fixes #639

• picked a non-breaking solution: logging warning for undefined slices

Note: logs cases for selectSlice operator only. Behavior of this operator, when dealing with undefined slices, was the cause of confusion for developers most of the time

[hoebbelsB]

@mrkpks thx for the PR! from my perspective it looks good besides the minor comment above. A further improvement would be a way to let it not run everytime. We should at first try it one of the demo applications and see if we get spammed too hard from it?

[nx-cloud[bot]]

Nx Cloud Report

CI ran the following commands for commit a587e51f83a9d9ca77e6c7bc8e7161b38a45aaf8. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Status	Command
	nx affected:build --with-deps
	nx run ssr-e2e:e2e --headless
	nx affected:test --parallel --maxParallel=2
	nx affected:lint --parallel --maxParallel=3

---

Sent with 💌 from NxCloud.

[edbzn]

Hi, first of all, thanks for your work.

We discussed this and we think that it will spam too much the console as it is currently implemented. It's a very common scenario to have undefined keys with the lazy state initialization concept. We should find a way to avoid spamming when not desired. We came out with different alternatives:

• adding an argument debug or verbose to selectSlice
• adding a selectSliceDebug operator
• adding a generic debug operator (*)
• not implementing this (**)

*The generic operator should be used with the same array of keys and before the selectSlice operator, eg:

pipe(debug(['keyA', 'keyB']), selectSlice(['keyA, keyB']))

This solution does not look very satisfying to me.

**This is not a trivial problem, and I feel like there's no perfect solution to solve this. My position is to not augment the API surface and let the developer ensure keys are defined before selecting them.

cc @hoebbelsB @BioPhoton