Update: just tried the same against 0.27.2 and it worked as expected, so this can at least be narrowed down to a bug introduced in 0.28.x. Thanks!

Thank you for this detailed report.

@customcommander Sure thing. Mostly because I couldn't leave it well enough alone, I poked at it a bit more and noticed that reverting the most recent commit to that module fixes the issue; I went ahead and submitted a PR that does so as well as throws in a new test case.

If you'd rather fix it on the reduceBy side, feel free to close the PR; I just figured since I did the digging I might as well save someone else the busywork of doing the quickfix.

Damn, do I want to stop supporting transducers altogether. The code complexity is much higher than it would otherwise be because of them.

@CrossEye Aw, I love the transducer support! Though you're not wrong that the internal implementations can be.. a bit mindbinding in JS (moreso than the clojure equivalents, even), so I totally see where you're coming from.

Though, to play devil's advocate for a sec, at a glance it look like a lot of the complexity is coming from adding on the transducer support to things that are actually reducers, which is sort of doing a transform+reduce on top of what is already a reduce? I was tempted to bring this up earlier, but held off since it's a bit beyond the scope of the bug. But hey, why not while it's on my mind 😀 .

leaning into transducers

Since transducers are already transform + reduce, it might actually simplify Ramda over the current dispatcher/wrapper stuff to make transducers the core of the operators that support both usages; once you implement the transform, the normal, non-transducer equivalents are easily expressed in terms of a transducer.

For example, here's a groupBy from one of my projects that uses a minimalist transducer library (I ripped out all the library-specific util functions so I may have added a bug somewhere):

function groupByXF(keyFn) {
  return function groupByTransformer(xform) {
    return {
      keyFn,
      xform,
      groups: new Map(),
      '@@transducer/init'() { return this.xform['@@transducer/init'](); },
      '@@transducer/step'(value, input) {
        const key = this.keyFn(input);
        if (this.groups.has(key)) {
          this.groups.get(key).push(input);
        } else {
          this.groups.set(key, [input]);
        }
        return value;
      },
      '@@transducer/result'(value) {
        for (const groupEntry of this.groups.entries()) {
          value = this.xform['@@transducer/step'](value, groupEntry);
          if (value && value['@@transducer/reduced']) {
            value = value['@@transducer/value'];
            break;
          }
        }
        return this.xform['@@transducer/result'](value);
      }
    };
  };
}

export function groupBy(keyFn, col) {
  if (arguments.length > 1) {
     // you can optimize a bit more than this by overriding the step/result functions instead of passing to into,
    // which would skip the final "copy the groups to the object", but I apparently didn't bother when I wrote this!
    return into({}, groupByXF(keyFn), col);
  } else {
    return groupByXF(keyFn);
  }
};

That's the whole thing! Which allows stuff like

groupBy(x => `length ${x.length}`, ['a', 'ab', 'abc']);
// => { 'length 1': [ 'a' ], 'length 2': [ 'ab' ], 'length 3': [ 'abc' ] }

into([], compose(groupBy(x => x.length), take(2)), ['a', 'ab', 'abc']);
// => [ [ 1, [ 'a' ] ], [ 2, [ 'ab' ] ] ]

...that said, for reduce applications like groupBy, Ramda is already going even further than clojure does; despite being the origin of transducers as a thing, clojure's group-by is just reduce! It's literally 7 lines if you ignore the docstring and such.

So.. you could probably get away with that too? It can be kinda nice, though. For one thing, you don't necessarily need to coerce the key to a string if you aggregate the groups using a Map or similar...

That's fascinating stuff. The last few days I've been trying to think of entirely different ways to manage reduce/transduce relationships, but haven't come up with anything useful. This is at the very least an interesting alternative.

What I would really like to find is some way to make transducers an optional model; Ramda could ship with transducers, or without. But I'm nowhere near close to that.