- Backend to frontend, and vice versa
- Main thread to worker thread
- Electron's main to renderer process
If what you're transferring is a "class object", it will never work smoothly.
class, which uses
prototype information under the hood is static.
It comes with your program.
Common sense says it must not be serialized and it is not serialized by default.
const something = new SomeClass(); something.someMethod(); const serialized = JSON.stringify(something); sendSomewhere(serialized);
You will hope that you can reverse it by deserializing it.
const serialized = receiveSomething(); const something = JSON.parse(serialized) as SomeClass; // expect this to be of SomeClass something.someMethod(); // disappointed
But it turns out disappointing when you call
someMethod and the method does not exist.
Those experienced enough know that this is bad practice, but it is common to expect serialization and deserialization should be reversible.
It may be partially caused by
JSON's non-reversible nature (and this series
will later visit
JSON's non-reversible nature), but replace
JSON.parse with any serialization/deserialization method and
and the result will just be the same.
Insisting on Using Class
With this somewhat "better" serialization/deserialization pair, you can expect this to work more often:
const something = new SomeClass(); something.someMethod(); const serialized = SomeClass.serialize(something); const somethingCopy = SomeClass.deserialize(serialized) as SomeClass; // expect this to be of SomeClass something.someMethod(); // disappointed
But to what extent?
What if at the receiving end, they don't have the same deserialization method?
Must you write serialization and deserialization for every class you have? You have to write more as your codebase (i.e. the number of classes) grows.
Writing serialization and deserialization for every class just does not scale.