[Idea] DRF compatibility

[gabn88]

Our project has a web interface, as well as a REST api. The REST API is build using DRF.

To create the REST API, one has to define serializers. These share a lot of similarities with model-based tables and I was wondering if in the future those could overlap?

Thinking even further, DRF also supports pagination and other features that overlap with django-tables2, so maybe the data generation part could completely be replaced by the serializers and other DRF functions?

Or would this just as easy as exporting the dict from MySerializer().data into the MyTable() instance and using the default django pagination?

[jieter]

@gabn88 thanks for the idea. While this might sound reasonable at first thought and there are certainly some similarities between a Table definition and a serializer.

But Table-definitions are often full of customized column rendering logic, which would not make the serializer definitions clearer.

I'd say your final sentence does make sense in some cases. I'm open to a PR (with tests and proper docs) adding a wrapper around a DRF serializer rendering its data in a django-tables2 table.

[jieter]

@gabn88 are you still interested in this? If not, I'll close this.

[gabn88]

I don't have time to do this myself and I think it would increase complexity of this module too much. Therefore it is closed

[jieter]

Thanks for reporting back!

[arpanpreneur]

I have a suggestion on this issue. I was thinking of migrating to React/NextJS the UI of a stable Django app that heavily uses crispy_forms, django-tables2 and django-filters together. We even have our own base classes that help us define consistent UI without touching HTML. Now, if we had a way to render JSON data (which we can use to reproduce the table UI anywhere), we could write a set of simple react components to render those tables without touching any existing code for the tables. Imagine we could migrate 100s of screens in under a week with this.

[jieter]

I see why serving JSON based on the django-tables2 table definitions might be a nice way to migrate to client-side rendering of tables. I'm not sure on using DRF to achieve the goal though.
If a sane patch is provided as a tested and documented pull request, I'll consider it.

[mschoettle]

I have done this in a client project without DRF as a view mixin. Everything like pagination, sorting, searching, exporting etc. was done client-side though. Not sure if it was the proper way to get it out of the table but besides performance for larger amounts of data it worked (and still works) well.

table: Table = self.get_table()
data = [
    {column.name: cell for column, cell in row.items()}
    for row in table.paginated_rows
]

I pulled the columns out separately via

# build list of columns and convert it to an
# ordered dict to retain ordering of columns
# the dict maps from column name to its header (verbose name)
table: Table = self.get_table()
table_columns: List[Column] = [
    column
    for column in table.columns
]
# retain ordering of columns
columns_tuples = [(column.name, column.header) for column in table_columns]
columns: OrderedDict[str, str] = OrderedDict(columns_tuples)

Here is the blog post with the full code snippets: https://mattsch.com/2021/05/28/django-django_tables2-and-bootstrap-table/

If I were to build a new web app today though I would keep everything server-side rendered and add the interactivity part using HTMX or unpoly. See also #908 on that particular topic.