-
-
Save samselikoff/53ca7b5eda29487615b1 to your computer and use it in GitHub Desktop.
@ef4 Haha, yep - that was an experiment. It's because this is a controller's template, and I was experimenting with non-blocking rendering. Since we have no routeable component I don't get a didInsertElement
hook for this route's template, which is really what I wanted: initially render the template in a 0-data state, immediately fetch data & show loading spinner, then (automatically) rerender when the data comes back.
I was also experimenting, bc I'm starting to feel like data fetching should be done closer to components that need it. With such a great DI system I'm wondering if we even need routes? Non-blocking rendering & components that are smart enough to know how to render in various states (no data, loading, etc) makes for a better UX anyways. Thoughts?
And I agree, I think this template is nearly at the point where I'd start breaking it up. But, it's so fun how much less code I had to write using these composable helpers. Also how easy it is to change.
There's definitely nothing that precludes doing component-centric data loading, so if that turns out to be the best approach I think it will just win out in the community through usage. But I think we still have a ways to go before asynchrony within components is as nice as what you get in Routes.
I also think a lot of aspects of routing should move to be less stateful. Today Routes are instances, but they really don't need to be and a lot of things get cleaner if they're not. Moving all data loading into components would potentially be a step backward along that dimension, unless we create a convention for routable components that lets them declare their asynchronous data requirements up front in static methods. Redirection, aborting, retrying, and error recovery mean you may need to bounce through multiple states before settling on one that you actually want to render. I don't want any of those intermediate steps to instantiate component instances.
We have clear separation today between the routing layer and the rendering layer that lets something like this work correctly:
In older Embers, if you toggled something
off and on again, you would lose the state in the outlet, because the state was living in the view hierarchy. Now it lives (conceptually) in a separate service, and it all works nicely. If we load data in components, we would need to preserve this capability by not storing the routing state on the component instances and stashing it off on a router service instead.
This feels slightly WAT when you first see it
But I think it's actually fine -- it's completely local and unambiguous what it does. And I like to do similar things with components that are pure behavior like,
{{scroll-page-to position=0}}
and{{#auto-focus }}<input>{{/auto-focus}}
.Overall I think this whole template reads great, though it's getting to the size where I start itching to break it into smaller pieces.