Skip to content

Preserve prototypes in the synchronization logic #531

@Dassderdie

Description

@Dassderdie

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 } with const 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. There is no easy way to differentiate between elements #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:
    image
    from How JavaScript Works (2018)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions