You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realize this is more a TypeScript than a Recoil question, but I was hoping to find some guidance on how we might prevent consumers from family atoms/selectors to pass additional, unknown properties in the parameter.
Due to how TypeScript works, it only warns for unknown properties when the parameter is a literal (as that gets its type from the family), not when it is an existing object (as that will get its type from the object, and as long as it also matches the type from the family, it'll work).
I've played with at least requiring all props of the parameter to be non-optional and then in the get-implementation throw if the number of properties does not equal what I expect. But that's evaluated at run-time of course.
I'm afraid TS today doesn't provide a way to avoid this, but any ideas are welcome.
All this is not a big issue in a small codebase with a limited number of contributors, but I've found that in a bigger codebase, with lots of people using selectors they haven't authored, they might pass common objects as parameter that meet the type, but cause it to update too often because they include other properties as well.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I realize this is more a TypeScript than a Recoil question, but I was hoping to find some guidance on how we might prevent consumers from family atoms/selectors to pass additional, unknown properties in the parameter.
Due to how TypeScript works, it only warns for unknown properties when the parameter is a literal (as that gets its type from the family), not when it is an existing object (as that will get its type from the object, and as long as it also matches the type from the family, it'll work).
The following CodeSandbox shows this and also the effect of additional props, namely that they will cause the selector to update even though it's not using it: https://codesandbox.io/s/typescript-forked-5tyw9?file=/src/example.test.ts
I've played with at least requiring all props of the parameter to be non-optional and then in the get-implementation throw if the number of properties does not equal what I expect. But that's evaluated at run-time of course.
I'm afraid TS today doesn't provide a way to avoid this, but any ideas are welcome.
All this is not a big issue in a small codebase with a limited number of contributors, but I've found that in a bigger codebase, with lots of people using selectors they haven't authored, they might pass common objects as parameter that meet the type, but cause it to update too often because they include other properties as well.
Beta Was this translation helpful? Give feedback.
All reactions