Thanks for your responses. While I do think query params can help keep track of state, and would be great for knowing things like:
- Current Page
- If the group is open or closed
- Filter settings
It still doesn’t help with the loading issue. Each component requires data, a subset of data that is in the store, and they also have paging. When a page is requested within a component there is no route change to force that load and binding to the store doesn’t help (since we bind to a subset.) You could add a query parameter that is for loading and pass that back and forth from the route to the component, but that feels out of place to have a loading state in the url. You wouldn’t want someone to sent a url or refresh the page and have one of the components show loading with no actual data being loaded.
To better define the problem, let me explain it another way. With Ember 2.0, bindings will now be top down by default. Breaking this pattern will seem out of place if you are building components that all need two way bindings to work. With that said, the only want to get out of a component then is through actions. I like this approach using actions to send things up, and it works as expected.
Another example that I think explains this need better is, we built out a Stripe component that handles processing a credit card and contacting Stripe. It can be used in multiple places as it is context unaware and its just a wrapper for the Stripe.js library to handle everything within a single component.
Encapsulating all the functionality within a single component is great and works as expected, except we only want to process the card when the next button is clicked, and then receive the results back from Stripe (through an action on the component). The next button is outside of the component (since this is used to say next for more than just the Stripe processing). There isn’t a way to send an action down into the component to tell it to process the card. We had to make this work through some hacky data bindings, that when the binding changes, the component then processes the card.
This is where I feel like ember starts to fail. Everything we need for Stripe is encapsulated in a single component. The component doesn’t know about its surroundings and purely handles processing Stripe data. But since data is only going down and actions up, there isn’t an easy way to communicate with this isolated component to say, okay process the card, everything else on the page is ready.
Hopefully that better defines the problem and some of the limitations of ember today. Overall ember is a great solution, but communicating down to child components isn’t a viable option today. To get around this you either have to hack data bindings together, or build components that are no longer isolated from the app and are data and context aware.
Again, any additional feedback or solutions you have found would be great to hear.