class-based Resource TS usability

[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 | undefined because they are undefined before the first call to modify, 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.

[NullVoxPopuli]

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

[NullVoxPopuli]

I've started a doc on proposing alternatives: #1056

[ef4]

As-is, the modify hook we have right now (and in modifiers) is used as a backdoor to an effect.

That's a very good point and another reason not to keep modify.

[NullVoxPopuli]

Closing this as the class-based-resource has been:

• removed from ember-resources: Remove class-based Resource #1082
• moved to a new addon: https://github.com/NullVoxPopuli/ember-modify-based-class-resource/
• utils using the class-based-resource:
  • moved from ember-resources to https://reactive.nullvoxpopuli.com/
  • no longer use the class-based-resource
    • example conversion of class-based to function-based with class:
      • Migrate trackedTask's implementation to use function-based resources universal-ember/reactiveweb#45
      • same API and behavior retained
    • example of overuse of resources, and the resource underlying usage was not needed at all
      • Refactor the map util to not be a resource, it never needed to be universal-ember/reactiveweb#54
      • same API and behavior retained