So my team is pretty split on this topic recently and I’d like to solicit guidance from the community and preferably anyone from the core team on the right path forward.
We have some components (provider-style in many cases) that fetch data using ember-concurrency tasks when some/all of their args change. They currently mostly use didReceiveAttrs lifecycle hooks to trigger refetch but we want to move away from that for at least two reasons:
- no power over which args trigger refetch (which usually results in too many fetches)
- lifecycle hooks are going away as we migrate to glimmer components
Obviously the long-term solution is the Resources RFC (or whatever shakes out of that), but we need something to use in the interim. Using the last couple comments in this RFC issue as a jumping off point some of us have started exploring the render-helpers type approach, but others really seem to hate that. Whatever the case it seems like we have 3 basic options:
- render helpers/modifiers or something like them
- computed properties which return task instances wrapped in a promise proxy object
We’ve done #3 a lot in the past but I personally dislike that solution very much as side effects in computed properties are strongly discouraged, and to me it’s kind of a “dishonesty” calling a data fetching task a computed property. Another group seems to really hate the render-helper type solution though, citing weirdness wiring things up in the template and “it’s basically just moving an observer to the template”.
Obviously none of the solutions are amazing and we all know we’ll have to compromise and it will be temporary, but is there any community/core consensus as to what we should do in the near term? I’ve done a lot of reading and it doesn’t seem like it, but it’s easy to miss stuff. I know @pzuraq has written a lot on these topics, and I’ve seen @ef4 in some of the relevant threads. Any feedback much appreciated.