Enhancements for ember 4

[madnificent]

The Ember framework has evolved substantially since we first constructed the ember-data-table. When this component was envisioned, Data Down Actions Up (DDAU) was not a real thing yet and variables were passed with two-way binding. We were discovering something like named blocks would be handy but we did not have solutions.

We now have tracked properties, DDAU, named blocks and Ember is moving towards being more explicit about integrations.

It has been clear for a while that the ember-data-table could be upgraded to cope with this new reality. We have also noticed that we'd prefer to expose more basic building blocks so alternative strategies can be implemented (like cards). This PR works towards upgrading the ember-data-table to modern Ember with named blocks. It also gets rid of the mixins that are currently in place. This has been a fairly mechanical effort up to this point and improvements can be made. Some things we see:

1. the code likely has bugs due to mechanical replacement
2. naming of the components can be cleaned up (the named block and the component name are not shared)
3. some libraries can be stripped, as suggested in #30
4. arguments (and their names) provided through the tree can likely be improved
5. for docs, the RawDataTable component could serve as an example to make data-table flavours use the same API (but upgrades will be manual)

A PoC bootstrap ember-data-table has been built based on the included raw-data-table.hbs file. It would be wise to have a few more of these cases so we can see if other arguments would need to be added.

[nvdk]

Could this be released as a beta so it's easier to experiment with in our apps?

[madnificent]

Yes, no, maybe, sure, not yet but maybe (*)? I think it makes most sense to try converting a few things with everything linked so we can update the renderless components at the same time. First tests show there's some streamlining of variables we should execute (these used to be internal state but are now much more a public API), and we expect some bugs to be in here.

I'm good with setting up a build for this if you'd want to gamble and run it somewhere, but I'm even more game for hacking on your use-case and seeing if it fits and where the friction is. I'm fairly certain the API is not stable as it stands, though the concept would stay the same and can easily be evaluated. If the concept stands, most changes will be name changes.

This is an open response, any thoughts? Go for a build anyways? Go yolo and base ourselves on a git tag?

[nvdk]

Ah I think I misunderstood how mature this was, perhaps a release is a bit early in that case.

FYI: From experience ember addons often have issues when installed from a git tag because npm tends to run the install scripts a bit different when doing that (I believe the prepare or prepublish step isn't ran or something like that, I'm sure there are good reasons for that but :exploding_head: ). That may or may not be an issue with this addon.