Open linuxwolf opened 7 years ago
One option is to perform as much of our telemetry in our Redux reducers as possible, although that might actually be a bad practice, since they're supposed to be pure functions. It's arguable if logging actions makes something "impure" or not though...
I care less about some notion of architectural purity than I do:
A Redux reducer probably works well in a lot of cases, but it's ok if there are a couple of (documented) exceptional paths because of how things really work.
I think the main thing is that keeping reducers pure makes testing and maintenance simpler, as well as working better with devtools (so you can do stuff like time-travel to previous states). Another option might be to create Redux middleware that intercepts actions, since that's how redux-logger works. I'll do some research into this starting tomorrow and see what the right way is.
@jimporter is this addressed with your middleware changes? or still something worth considering / doing here?
This probably ought to be a separate issue, but telemetry recording can make the overall app brittle. There are a number of (still not understood) reasons for recording failure, it causes an uncaught failure in our code.
Personally, if it's a question between guaranteeing telemetry recording versus guaranteeing running, I prefer to let the telemetry fail but keep the app moving forward.
The current calls to
recordEvent()
are performed in places that works as we expect today, but might result in "false positives" in the future:render manage
might falsely record because of a locked database, or the user manually typed in the URLitemAdded addItemForm
might falsely record because an item was added via another path[ follow up from points made in #156 ]