Currently, when computing memo key for an object based on a class type, we incorporate the full-qualified module path + type name as the memo key. This introduces difficulty for migration, e.g. if the type is moved to another module after refactor, existing memoizations will be invalidated.
We want to allow users to provide a stable distinct type identifier, so they can remain stable upon migration.
❤️ Contributors, please refer to 📙Contributing Guide.
Unless the PR can be sent immediately (e.g. just a few lines of code), we recommend you to leave a comment on the issue like I'm working on it or Can I work on this issue? to avoid duplicating work. Our Discord server is always open and friendly.
Currently, when computing memo key for an object based on a class type, we incorporate the full-qualified module path + type name as the memo key. This introduces difficulty for migration, e.g. if the type is moved to another module after refactor, existing memoizations will be invalidated.
We want to allow users to provide a stable distinct type identifier, so they can remain stable upon migration.
❤️ Contributors, please refer to 📙Contributing Guide.
Unless the PR can be sent immediately (e.g. just a few lines of code), we recommend you to leave a comment on the issue like
I'm working on itorCan I work on this issue?to avoid duplicating work. Our Discord server is always open and friendly.