digital-fuesim-manv
digital-fuesim-manv copied to clipboard
Preserve prototypes in the synchronization logic
Preserving the prototypes is the big design decision between only saving state in the ExerciseState
(current implementation) or also behavior (functional vs. object-oriented programming).
What would need to be done to achieve this?
-
class-transformer
could instantiate the state and all actions after the frontend & backend receive them over the network/from the database, ... - When sending requests, the prototypes would have to be stripped (I believe socket.js/the runtime API already does this)
- ImmerJs can preserve the prototypes.
- We would have to replace all
const copy = { ...myObject }
withconst copy = clone(myObject)
. - Instead of
.create()
or object literals, we would always have to use the constructor. (in theory, we could also somehow disable the error from immerJs to not rely on the.create()
functions).
Positives
- We could use functions (including getters and setters, I assume) directly on the object instead of the static functions like now.
- We could use
instanceof
instead of a discriminated union. #530 - No workarounds with
.create()
to strip the prototype from the class
Negatives
- It is against Redux's philosophy
- It could break Angular and could prevent us from using certain libraries (e.g., proxy-memoize for magical selectors)
- The application could get very complex, as there is no clear separation between state and behavior anymore.
- Worse performance (how much worse?) due to the use of
class-transformer
- Worse performance (or the same performance?) in combination with freezing:
from How JavaScript Works (2018)