DISCUSSION 1: ObserverSpy API - Methods vs getters about observer-spy

[NetanelBasal]

Hey Guys!

• Regarding the usage of methods or getters, I think it's a matter of preference. If we take a look at Sinon.JS, we'll see that most of its API are methods. One benefit of using methods is that they're scalable to changes without introducing a breaking change. For example, they can take additional parameters.
• IMHO the API should be simple and thin. Most of the usage will be to check the current value that was emitted.

[yjaaidi]

Hey everyone!
+1 for flat in favor of nested.

Concerning properties vs methods, I like how properties are shorter... but even if we ignore extensibility by adding parameters, the problem we get is the inconsistency between using props for values and methods for things like getValueAt().

I think that the most important thing here is consistency. For instance, hasReceivedNext() & getValues() vs receivedNext() & values().

I generally prefer the latest as it's shorted but we have to make sure that we'll never use any properties to be the least surprising.

[katharinakoal]

Well, that's a very interesting suggestion!
I like that the new API approach clearly hints that spy instances are stateful. That might benefit the readability of test specs where you want to go beyond checking basic behavior.

Maybe it would be helpful here to consider where this library will be heading to. What's your vision @shairez ? 🤩
If ObserverSpies should someday evolve to a comprehensive scheduler-free alternative to marble-testing, I would move forward with the new API suggestions.

Right now, I use ObserverSpies more like a supplement to marble-testing and like the simplicity of its API. That's why I rather prefer the current way of exposing only methods with prefixes (is/has/on/get). Each method has its decisive intention, and it feels somehow more consistent.

But that's just my opinion. I'm curious to see what's next. And if there is anything I can help with, let me know!

[shairez]

Appreciate the feedback @yjaaidi !

I agree with your points and also that shorter is better, though getValues() feels better to me than values() (maybe it's a matter of being used to it or something)

[shairez]

Thanks @katharinakoal for your feedback!

My aim for this library is to keep it small and simple.
That's why I like a more flattened API (vs nested).

And that's where Thomas wanted to take this library too - towards an API he believes is better and simpler than the current one.

I actually didn't plan to replace marble testing, just to make 90% of the every day app use cases easier to test :)

The question in this issue I believe comes down to - which is better - .getValues() or .values (and the rest of them)

I'm trying to find reasons other than "I like this style better because I'm used to it", but to actually show how it is saving time while reducing confusion.

So maybe something like "In the following test, look how this api is much cleaner and clearer" (followed by a code example)

I know my experience is just one man's experience, so I try to incorporate as many perspectives as I can to make sure we have an API that covers as much use cases while keeping it elegant and small.

[shairez]

Good points @NetanelBasal !
Thanks for sharing your feedback 🙏

[shairez]

Finally I had some time to get back to these issues 😅

I'm closing this issue as it seems like the majority thinks it's better to stay with methods.

Thanks everyone for participating!

BTW, You can view the latest release with @ThomasBurleson 's improvements here -

https://github.com/hirezio/observer-spy/releases/tag/v1.4.0