Improved semantics around model hook reloading about rfcs

[locks]

That's two different places in the guides where the semantics are referenced, on top of the API documentation. Suggest specific improvements to the Guides repo, as that is easier for us to keep track of and give feedback.

I don't agree with the modelHook attribute, especially if it'll override the current semantics leading to more unexpected behaviour. Another question that might necessitate some more discussion is what happens when the model hook isn't just, say, a store call, but a hash of several of them?

[davidlormor]

Thanks for the input locks. I'll definitely make any specific suggestions re: improving the guides over in that repo.

I know that skipping the model hook via a passed in object is legacy API that has been around for quite sometime (and there are definitely cases where the behavior is warranted) but I believe a more declarative syntax would be beneficial in reasoning about an application behavior. I also believe this behavior was much more desirable when Ember Data lacked the semantics and facilities to do determination about when to reload models (via {reload: true} in queries, shouldBackgroundReload properties, etc.). Because this functionality now exists, the ability to pass in a model to avoid an API call is much less necessary.

Also, given JS's dynamic typing, there isn't anyway to guarantee what's being passed in to the helper, which leads to potential nondeterministic behavior in route initialization. Ultimately, there is no way to specify the desired behavior, either in the helper or the route...it is all determined at run time based on the type of object passed in. In general, this would not be good practice and potentially leads to challenges in reasoning about and debugging parts of an application.

For examples of the confusion caused, see discussions here and here.

IMHO (for whatever that may be worth...), I think having a clear interface to define whether a route should fire the model hook is a win across the board. The existing behavior could continue to remain the same, so as not to be a breaking change, but a higher degree of specificity could be achieved where a developer desires.

Finally, regarding your last point about more complex model hook behaviors...I think that's something that could warrant discussion, but is really outside the scope of what I'm proposing.

Thanks for taking the time to consider this change!

[wagenet]

I'm closing this due to inactivity. This doesn't mean that the issue is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!