I'm not a huge fan of middleware either. It is sort of dispatch -> mystery transformation -> reducer. Entering a codebase with a lot of middleware can be super confusing.
This is not elegant, but an example myMethod(aTransformer(payload)) another developer coming in knows exactly what is going on. The downside is that you will be typing in that transformer over and over. If the middleware is fetching data, well. fetchFn(payload).then(myFunction)
I also totally get the idea of serializing events. I have built many API services that do something similar. I often use something like jsonpatch.com/ where I have a data object that I can apply, unwind, flatten, etc... It is pretty easy to have a function getPatch(prevState, nextState) then drop that in a Set/Array/Database/etc...
I'd argue that something like a JSON Patch becomes more useful anywhere. What you define as { action: "someAction", payload: "somePayload" } is not always a straight up merge. Often the payload is a single key in the state. Or there is business logic in the reducer. Thus, you need to know how the code works and if you change the the code, you break all previously stored actions if you needed to reapply them.
Of course, I'm talking about actually storing event history. In reality, how many React develpers do much more than a simple undo and even then I rarely see that. What I do see is that developers use the actions in Redux tooling to see if their event fired and what side effects might have happened. And right there I would say build that all in a Jest test and check your results there with assertions. Like, actually develop in your test runner. Then you have test coverage and you'll know if your state breaks with some code/dep update.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not a huge fan of middleware either. It is sort of dispatch -> mystery transformation -> reducer. Entering a codebase with a lot of middleware can be super confusing.
This is not elegant, but an example
myMethod(aTransformer(payload))another developer coming in knows exactly what is going on. The downside is that you will be typing in that transformer over and over. If the middleware is fetching data, well.fetchFn(payload).then(myFunction)I also totally get the idea of serializing events. I have built many API services that do something similar. I often use something like jsonpatch.com/ where I have a data object that I can apply, unwind, flatten, etc... It is pretty easy to have a function
getPatch(prevState, nextState)then drop that in a Set/Array/Database/etc...I'd argue that something like a JSON Patch becomes more useful anywhere. What you define as { action: "someAction", payload: "somePayload" } is not always a straight up merge. Often the payload is a single key in the state. Or there is business logic in the reducer. Thus, you need to know how the code works and if you change the the code, you break all previously stored actions if you needed to reapply them.
Of course, I'm talking about actually storing event history. In reality, how many React develpers do much more than a simple
undoand even then I rarely see that. What I do see is that developers use the actions in Redux tooling to see if their event fired and what side effects might have happened. And right there I would say build that all in a Jest test and check your results there with assertions. Like, actually develop in your test runner. Then you have test coverage and you'll know if your state breaks with some code/dep update.