Using ember-yeti-table with the model() hook and queryParams

[charlesfries]

Big fan of this addon. I love the template-based approach you've taken, and it's one of the only Ember table addons I've found that allows for template-based HTML table cell content while retaining sort functionality. My issue is as follows:

I'm trying to follow Ember's data flow guidelines to a T, but I'm having an incredibly hard time integrating this addon while adhering to said guidelines. I have a dataset with 10,000+ records, and as such I have no choice but to use server-side pagination. My table data originates from the route model() hook, and page/filter/sort changes are bound to queryParams with refreshModel: true so the model() hook can be notified to fetch a new set of data.

Here are my requirements for this addon:

• Data originates from the route's model hook
• Page/filter/sort changes propagate up through the controller and ultimately end up in the route (in model(params))

In this addon's current state, is this kind of functionality possible? It's almost like I need to use @data to populate the table with data from model(), and then use @loadData to listen for page/filter/sort changes in order to update queryParams.

I see that actions are exposed via table.actions, however is this not the reverse of how things are supposed to work? As I understand it, we call these actions from a parent context to call internal actions inside <YetiTable>. But doesn't this design violate DDAU? Or am I misunderstanding something/behind the curve of how things are done in 2021?

Again, huge fan of this addon. I'm just struggling mightily trying to incorporate this table component into my large app while adhering to Ember's recommended way of doing things. Any information is appreciated. Thank you.

[miguelcobain]

All this addon requires for async loading is a function that returns a promise with data. The component will call the provided function when needed.

Unfortunately, this doesn't play very well with the model hook + query params way of loading data. Because, as I've said, YetiTable expects to be driving the data loading through a single @loadData function. It's like a "black box" that is expected to return the needed data and we don't really care how. The problem is that DDAU, i.e changing params up and getting a new model down isn't a black box. It's a "two step" process. So the @loadData approach doesn't work for this.

Passing in @data wouldn't be appropriate, because YetiTable expects it to contain all the data for it to calculate pagination, filtering and sorting. It's the "batteries included" approach, where it is expected to operate on a full set of data. This isn't the case here.
@loadData also isn't a good fit either because, as I've said, it expects you to return the data, which you can't because you're requesting it from the model hook.
I can imagine a way to "decouple" the loadData process into:

• actions like @onPageChange, @onFilterChange, @onSortChange, etc (or perhaps even a single action like @onLoadParamsChange that would include all the params)
• another argument where we pass in the data ready to be shown like @processedData

With this you could do something like:

<YetiTable
  @processedData={{this.model}}
  @onPageChange={{fn (mut this.page)}}
  @onFilterChange={{fn (mut this.search)}}
  ...

where page and search would be query param properties in the controller.

This functionality doesn't exist at the moment. Not for any particular reason. I think no one simply needed it until now. :)

I'll leave this ticket open. It doesn't seem like a too complicated feature to implement. It's basically making sure YetiTable also works in "dumber" scenarios (dumber in the sense that YetiTable does less things).

[cah-brian-gantzler]

I think the route model hook is really more for the initial data, and changing data is controlled by the controller. Thats why at this time the query params are on the controller not the route. If your yeti table is on the controller template you shouldnt have a problem. If your table is in a component, then yea you need some communication back and forth.

Routeable components was a direction ember was going at one time, doing away with controllers, and have removed all the obstacles but one, query params were only accessible from the controller. :(

Adding the additional actions would probably be useful, although increasing the API surface and complexity. I am waiting on the following RFCs to land
Query Params as Derived Data (docs-only RFC)
Arbitrary Query Params (new optional-feature)
Once they do, I can think of some creative ways to get yeti table to optionally support query params directly to remove some of the burden on you to do that communication back and forth

[Windvis]

This is similar to the issue I created a couple of years ago: #18

But I probably didn't explain it well enough 😄.

[cah-brian-gantzler]

It some recent work I have done with replacing ember-crumbly, I see query params are already accessible in the router service, just cant be updated there yet, but read-only is what we need.

Will see if I can find some time to see what might be done here