Path treats a string parameter as an array of characters (v3.0)

[voliva]

I found this when missusing path by calling it without wrapping the string into an array (which I'm aware it's not how that method is used)

It was funny, because using it with innerReducer it created a deeply nested object containing basically each character on that string ({"c": {"o": {"u": {"n": {"t": 0}}}}})

This will be covered by TS when we add support for it on v3, but maybe it should throw an error on declaration/runtime... How does rereducer normally handle usage mistakes?

[josepot]

Yeah! I just came across that same bug too. I'm currently working on a fix that should solve that, because I want path to have 2 overloads:

• path([...args]) and
• path(prop) which would be the equivalent of: path([prop])

I thought that it was already working like that... Actually, it already works like that if the prop parameter is a string/number, however if you pass it only one parameter that's a function, then is when we see that issue.. Anyways, I will have the fix pretty soon.

This will be covered by TS when we add support for it on v3

That's awesome!

How does rereducer normally handle usage mistakes?

Right now, the only function that handles usage mistakes is switchReducers.

I'm planning to do the same for the rest of the public functions, but I'm leaving for the end as I think that it makes more sense to do that work once the API is "final", because I don't want to have to update messages every time that we make a change into the new API functions.