sneakers-the-rat / paper-feeds

A FastAPI web server for creating RSS feeds for scholarly journals with the magic of adversarial interoperability
GNU General Public License v3.0
60 stars 4 forks source link

Advanced tables #32

Open roaldarbol opened 5 months ago

roaldarbol commented 5 months ago

We're still not quite sure whether to use any JS to render tables - my personal opinion is that it would probably make life easier, but let's see. ;-)

We need tables with pagination and buttons as a minimum in my view.

I've found a nice JS library that can be super customised to be downloaded with the minim needed code, and it's under an MIT license: https://datatables.net/. Maybe the search can be implemented into it too. How it plays with htmx, I'm not quite sure, I think that's what we need to sort out.

Any opinions before I give it a go?

sneakers-the-rat commented 5 months ago

Lets think about this a little first bc it does impact how the API is designed a bit-

What do we need from tables?

Anything else? I feel like the within-item stuff you were thinking like being able to do advanced options on a given feed can be separated from that, within a table item we just do that with templates and forms. Searching is already done by the backend.

To use something like datatables we would change the endpoint so that it a) feeds all the data for all the pages b) as JSON rather than HTML. This is basically a trade between frontend and backend complexity.

The downsides to me are needing to ship jquery and basically rewrite what we have re: frontend logic, which isnt much but not none. One more thing is that we'll probably need to implement sort and pagination logic to a few endpoints generally so that might be something better done on the backend rather than putting it all in client js. Part of what im trying to avoid is having the frontend complexity balloon to the point where we are having to do a whole separate test suite and mock a webdriver and whatnot.

So im not categorically opposed but I feel like if mostly what we need is sorting (checkboxes are something htmx can handle relatively simply) then we should probably try and do that with what we have already. But! If you want to give it a shot and there is something compelling youre seeing about advanced tables im not seeing then it seems like a prototype wouldnt be that hard to try?

sneakers-the-rat commented 5 months ago

i was intending to be like "it's not how i'd do it but give it a shot" while also being like "we might have to do a bit of work to use that tool" but it came across more negatively than i intended - basically if you want to try that then hey by all means! I'm more interested in the backend, so if you're more interested in the frontend and we can keep this thing lightweight, deployable, and testable, then i'm all for letting you lead that part.

broader context - a lot of the fediverse hates javascript, and in particular the kind of javascript that is "just throw packages at it until it goes." i sort of see their point about how it makes the web extremely bloated, inaccessible, and hard to maintain, but I also think react is cool and can be done well, and a good tool is a useful tool (with minimal side effects). So htmx as a choice is sort of tactical in that it keeps us in the good graces of some wonderful webtech nerds that might be interested in this project, and it's also a sort of a joint 'badge of honor' and homage to the olde web to not ship any* javascript. I'm saying this so it doesn't seem like i'm just randomly ornery or picky about framework choice and withholding something - it's as much of an aesthetic/cultural thing as it is technical to me, but part of my aesthetic/cultural values in programming are not being a domineering prick as so much of programming world can be, hence my longwinded "go for it"

roaldarbol commented 5 months ago

Haha, no worries, it didn't come across negatively, but passionately! 😊 Great with some context, including the fedi - I'm learning loads about the hack culture, and I'm onboard with that. I just have to be realistic and say that I won't have the time to fully learn yet another language and implement novel logic (to be honest I don't really like computers, but I live with them, and might as well improve the experience whilst at it) 😉. I guess that's also why I tend to focus more on the frontend, as my rebelliousness (word?) is much more UX-oriented (of course in an effort to get away from mass surveillance - my view is that people will move away once the alternatives look and feel just as good, if not better). So yeah, I reckon that's my main focus, and we can just continue to chat about the best ways to make those two visions meet in the middle. 😊

Back to tables: Seems fine with the checkbox, and a button to add them - that's a UX choice I think works well too! I like the implementation in the example above!

The only thing I haven't figured out is whether pagination is possible with htmx. I've only found examples and questions where people try to integrate htmx with variuos js/django libraries. If we can find a way to do that, then I'm in. :-) As a temporary measure we could use click-to-load (https://htmx.org/examples/click-to-load/), but I think pagination will be needed down the road.