fix: chart state and series functions cleanup

[monfera]

Summary

Mild refactoring that leaves logic and types in place:

• fixes the handling of zero non-global chart types
• fixes a sorting issue with non-finite returns
• removes some branching and dries up conditionals
• removes avoidable variables, lets and conditional mutation
• attempts to improve the readability and "flatness" of some logic, converting some triangular bits to linear and rectangular shape
• regularizes returns into one or just very few, easy to spot places
• removes some type related branching that used to (or should have, sans TS limitations) narrowed to a singular type or never
• added a heterogeneous small multiples test case we looked at together
• removes IDE-generated JSDocs @params encountered

No functional or API change. Precedes further work on non-cartesian small multiples.

Checklist

Delete any items that are not applicable to this PR.

[monfera]

The block below (return nonZeroLength...) could be extracted into a separate function, though not much benefit right now. And flat, linear ternary chaining for the inherently fall-through logic, we might need to chat about it 😃

[markov00]

All good for me, thanks for taking time to clean this up, in particular the state reducer,
I've just set a comment to rotate the added chart horizontally that looks a bit better IMHO

[nickofthyme]

I don't agree with all the if statements being converted to nested ternaries, in some cases they a cleaner but in many cases, the compact logic is hard to follow. I think this should be a preference thing when using nesting ternaries is required.

[nickofthyme]

👍🏼

[nickofthyme]

This seems harder to read for me TBH, not sure why the nested ternary lines are not indented.

[monfera]

I think it's not nesting b/c it's a linear fallthrough case, ie. no structural nesting applies, more like a case sequence in a switch. Would work with indented formatting, would still preserve ability to linearly read through

[nickofthyme]

It's a ternary inside another ternary, that's nested no?

As far as the indenting, this is what I'd like to see that delineates the exprIfTrue and exprIfTrue code blocks.

const customLabel =
    typeof spec?.name === 'function'
      ? spec.name(seriesIdentifier, isTooltip)
      : typeof spec?.name === 'object' // extract booleans once https://github.com/microsoft/TypeScript/issues/12184 is fixed
        ? getSeriesNameFromOptions(spec.name, seriesIdentifier, spec.name.delimiter ?? SERIES_DELIMITER)
        : null;

[monfera]

This formatting would be OK too, maybe in some formatting PR we can test drive how the rule would shape the ternaries here and elsewhere.
You are right, the syntax AST is a right-deep tree which is conceptually still linear (the reason it was born), as in, you could substitute it with a reduce, or switch/case alternative, or it can be read as

Condition1
Result 1
Condition2
Result2
Condition3
Result3
...

Especially with code I didn't write, I find it way easier to linearly step through, "OK this condition still not true, let's look whether the next applies" compared to needing to simulate ascending and descending into (semantically, not just AST-wise) nested ifs. So this is what I meant by rectangular code, linear readability. I know I'm in trouble when the left edge of the code is meandering, I might have some weaknesses there, usually, it takes less time to simplify data flow and control flow paths and making the code shorter (all of which I think also happened) than to eyeball it long enough to grok what's going on.

Languages:

JS doesn't offer a true cond, and the equivalent switch(true) pattern is not only a yoda condition but also a bit unwieldy (b/c our linter requires curlies for even single-row returns), though often better than nested if. A reduce with the options would work too, but it'd eagerly evaluate never taken options, expensive and would need a lot of defensive optional chaining etc.
The best support in this case is provided by those that have pattern matching constructs. Eg, a Fibonacci in haskell would be

fib n | n == 0 = 1
      | n == 1 = 1
      | n >= 2 = fib (n-1) + fib (n-2)

again, linear/rectangular code, easy to read top to bottom, and a single pass reading gives a good picture, no need to ascend and descend into conditional valleys. JS don't have no such pattern matching...

Bigger picture:

Both code (internal view, our DX) and API (external view, Kibana DX) benefit from a strive toward simplicity. One way for achieving it is to reduce the number of conditional paths, nesting variety and one-off handling. It's always straightforward to add to the code; "on this condition X let's do something different before/after/instead of the current thing", which is how code bases become tangled.

So my feel is that the real solution is not to turn into ternary all such bushy if trees, though it has some positives too here, and also, not to introduce code level constraints.

Instead, we could be be a bit slower to add features; let's brainstorm if

• we actually need a feature (eg. this function is made this complex in part by the null return of the callback we discussed today; meanwhile nobody uses it, and even our test cases don't lock in the promising yet speculative flexibility)
• can it be achieved without added complexity, or how can we minimize added complexity
• can we even remove branchy code while solving a need by going a bit more general; eg. avoiding singleton cases

That's the drawback with broadening types into union types (discriminated or not), and/or optional props, and the error prone falsey and fallthrough cases that require mental juggling and exponentially growing conditional branches like | null | undefined. This is why I feel it was good to chat about lending the user overriding and other config options in ways that retain as much homogeneity as possible, and type clarity helps the user too, fewer types, tighter doc etc. This is all I'm learning along the way so quote me on this when running into my subpar code, past or future 😸

We talked about eventually farming out a humane layer for somewhat hairy rules, defaults and fallbacks, so our core isn't penetrated by API use brevity or other architecture wise superficially manageable reasons; ie. core charting, wrapped around with defaults etc. driven by best practices, folks' expectations, customs etc. We had a chat with @markov00 today about an approach toward layered, priority/fallback driven configuration, which doesn't bake in what the user can and cannot override along some preconceived directions. So either of these options could help avoid expoding conditionals.

So ultimately I agree, and work toward not needing this many layers of "pattern matching", ternaries or not. Future PRs from all of us FTW!

[nickofthyme]

Thanks as always for the thoughtful reply. I just don't want to get to a point where we are forming super complex ternaries to remove complex nested conditionals. Replacing some makes sense while others would be hard to understand, but yes reducing the bushyness would be great.

As for the null option and other non-used functionality. I think we could go through the code sometime and maybe identify features in the code that are any of the following:

• Not used and does not have a practicable use case.
• Features that are not used but have a good use case. (documentation is to blame)
• Features or options that have multiple (>2) options to use but only a simple and complex option would suffice.

[monfera]

Thanks @nickofthyme!

Great idea for hunting for disused functionality (esp. that's not foreseen to be used; maybe this null or some alternative would have great use). Maybe we could look out for the replaceability of optional or nullable/undefinable properties too, at least for alternatives discussion. Though both take a good bunch of time.

I agree the ternary chaining is less than optimal, there's room for improving on it, hopefully by simplification rather than eg. if/return or let/if/assign chaining or nesting the next time one of us touches that part of the code, so it's likely not for eternity.

[codecov-io]

Codecov Report

Merging #989 (17e1356) into master (d14de01) will increase coverage by 0.48%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #989      +/-   ##
==========================================
+ Coverage   70.87%   71.36%   +0.48%     
==========================================
  Files         346      362      +16     
  Lines       11028    11314     +286     
  Branches     2419     2448      +29     
==========================================
+ Hits         7816     8074     +258     
- Misses       3199     3221      +22     
- Partials       13       19       +6     

Flag	Coverage Δ
unittests	70.85% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/chart_types/xy_chart/utils/series.ts	96.05% <100.00%> (+0.28%)	⬆️
src/state/chart_state.ts	89.74% <100.00%> (+1.83%)	⬆️
src/utils/common.ts	90.41% <100.00%> (+0.06%)	⬆️
src/mocks/store/index.ts	100.00% <0.00%> (ø)
src/mocks/store/store.ts	92.59% <0.00%> (ø)
src/mocks/specs/index.ts	100.00% <0.00%> (ø)
src/mocks/geometries.ts	92.10% <0.00%> (ø)
src/mocks/series/series.ts	90.00% <0.00%> (ø)
src/mocks/index.ts	100.00% <0.00%> (ø)
... and 10 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d14de01...17e1356. Read the comment docs.

[monfera]

Re-titled to fix as it fixes two low likelihood runtime issues (zero chartTypes -> undefined return; Infinity and NaNs in sort function) and improves types (fewer asserts, removal of a never taken code path)

[nickofthyme]

Latest changes LGTM. Thanks for the comments.

[nickofthyme]

@monfera I think fix is also good, I think a more concise title is fine. Feel free to change it back if you like.

[markov00]

🎉 This PR is included in version 24.5.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀