NullVoxPopuli
commented
7 months ago The current class-based resources are hard to implement with good typescript types, because they don't have access to their arguments in their constructor.
Yeah, arguments are only available via modify in the current implementation, they mirror class-based modifiers -- which probably also need re-evaluating.
It could have a different method for receiving updates
After lots of playing around in this space, I'm not sure we want to have an update callback. Derived data is sufficient, and documenting how folks can effectively use derived data would handle most folks' use cases.
As-is, the modify hook we have right now (and in modifiers) is used as a backdoor to an effect.
I've been considering re-doing class-based resources' implementation (which would be non-breaking), to instead wrap function-based resources.
The implementation would roughly be:
function ClassBasedResource(args) {
return resource({ on, owner }) => {
let instance;
on.cleanup(() => instance && destroy(instance));
return () => {
instance ||= new SomethingFromTheUser(); // + setOwner, associateDestroyableChild, etc
instance.modify(args); // spirit of, not exactly.
return instance;
}
});
}that said, I think I'd rather document how to implement various "resource-like" patterns with classes using the function-based resource api, as folks may want different capabilities around construction and updating.
The types for template-only glint compatibility tho is bonkers, and def not for the feighnt of heart.
Probably need to open an issue with some ideas before moving forward with this though.
In a lot of folks' use-cases, the link-pattern would be sufficient: https://ember-resources.pages.dev/funcs/link.link
ef4
The current class-based resources are hard to implement with good typescript types, because they don't have access to their arguments in their constructor.
Another way to say this is: they expose a user-visible "dead time" during which they exist but don't know their arguments.
This problem manifests as being forced to declare all your fields as
TheirRealType | undefinedbecause they are undefined before the first call tomodify, even though that time is irrelevant.An API that used the constructor for initial arguments would not have this problem. It could have a different method for receiving updates. Using the constructor would also avoid the weirdness of using the word "modify" to describe the initial creation of a thing.