This conversion cannot be checked in its functionality, as we must
convert the underlying components too in order to check the current
setup.

The NumberPagination component now also consumes content and sends
updates.

This is the path that allows us to render a sortable header.  Yet
nothing else is currently being rendered.

The content can now be rendered in an Ember 4.x application.

The base building blocks the search used are quite neat.  We've
continued to use those and were able to simplify a tiny bit due to new
abstractions.  This component can likely benefit from some shuffling of
the code but that would require a second reading.

Filter was not passed correctly.

These had some leftover todos attached to them.  Not needed.

The test cases may help us find a way out of this, but this feels like
it's a sensible step to at least get the branch into a possibly sensible
state.

This provides with a few options, as summarized in the docstrings.

This component is the first to receive support for named blocks.  This
allows a user to override only part of the component.

The pattern that arrizes in the component is feasible to stare through
and so we hope this may be a construction that we could iterate on for
the other components too.

This should allow users to use the menu once again.  You don't need to
extend the full component for using this anymore :)

The idea is that we allow various slots to be used to override parts of
the data table, allowing other parts to stay put.  This structured could
possibly be used as a guideline to styled versions of the
ember-data-table.

The big template would make replacing parts easier from a consumer's
point of view.  It does mean we have a single very large template with
all visible options embedded in it.  Question would then be if this is
easier to maintain and manage than the alternative with many components.

This approach should make the template a tad easier to understand as we
have removed more information-passing logic into components that don't
render output themselves.

These basics should help people get started with the components.  The
route and controller could receive more love to allow better combination
with other libraries.  Not sure how much that happens at this point in
time.

Whilst implementing an alternative view, some thing options turned out
to be missing.  Adding those in.

These are space-separated lists you may supply to indicate for which
columns the :data-header and :data-cell should be rendered.  When
specified it will only be rendered for those cells.

This DSL should make it obvious how to add common views to be linked at
the end of the view.  It is possible to override the statement by using
an actions block.

Renaming the files ensures they don't currently run.  We may want to
alter these tests so they're picked up again later.

The number pagination has a concept of the server pagination on the
outside and human pagination on the inside.  Some features could be
added, but this is an easier to understand workflow for the features
that exist now.

Co-author: @erikap

The components hbs files mostly follow a logical name but it can still
be a bit confusing.  We're adding the breadcrumbs now so we can find our
way back more easily.

These field objects contain information fetched from various
configuration parameters and will make it easier to provide certain
overrides by providing known information through a single interface.

Co-author: @erikap

Cleaner wording, replaced semi-automatically.

Co-author: @erikap

More obvious naming.

Co-author: @erikap

A warning is shown on missing update functions.  This will not error
before they're used but it's a bit more helpful.

Co-author: @erikap

This only appears in the RawDataTable component at this point.  Best to
update it as it will likely become the preferred starting point.

These properties have been replaced with the fields object.

Co-author: @erikap

Co-author: @erikap

Co-author: @erikap

Co-author: @erikap

Co-author: @madnificent

Co-author: @madnificent

Uses the human element towards the implementor which hopefully makes
things a bit easier to implement.

Co-author: @erikap

Co-author: @madnificent
From @rollvolet <3

Co-author: @erikap

Co-author: @erikap

Co-author: @erikap

The readme would need to be completely revamped for the new data table.
This should go a long way towards that.

This documents the various parts which can be overridden.  It's probably
the easiest to check the specific design implementation but this might
help determine the intent.

These were within a component and they're not allowed there.

This is a wrapper object containing:
- size
- page
- filter
- sort
- isLoading
- updatePage
- updatePageSize
- updateFilter
- updateSort

It is an opaque object from the user's point of view.  All current
arguments take precedence making it easy to override.  The default case
becomes shorter which is great to show what's special about the specific
Data Table at hand and thus lowers mental overhead for the default case.

Makes it easier for users to fallback to the default behaviour when
implementing custom sort parameters for an attribute.

The addon imports the JSONAPI serializer from ember-data