chrisz4

Once setup, I found that amount of code required for creating a simple trace via otel and logging is roughly the same.

Refer to: https://github.com/michaelperel/otel-demo/blob/master/cmd/se...

51: Start a span. Equivalent to one line of log 60: Add a event. Equivalent to one log 69: Set attribute. This retroactively add attribute to whole span since the start. While log don't have exact same effect, one line of log can be used here. 74: RecordError. Equivalent to one log

I haven't compare amount of code to setup a proper logger which connected to correct infra with amount of code to setup otel yet. Still, I don't think it gonna make much difference.

In general, I won't mind either approach if I get a great visualizer. The main reason I would choose OpenTelemetry is I get trace visualizers for free and I can switch to better visualizer anytime that I want.

Let's step back. I think your approach work really well if you model state machine for internal usage.

However, Redux is meant to be for UI work, which is a side effect. You cannot control side-effect. You cannot guarantee that user will not try to turn switch off twice.

Even in idiomatic Redux, the switch case for reducer always include `default:` which mean everything else go here.

As you said, the Redux FSM models a car lock button interface which is exactly what Redux try model.