Developing an SPA version of Django admin

[Warren Havemann]

Hi everyone,

I've been contemplating the development of an SPA version of admin either in Angular, React, Vue or even Flutter... preferably in Angular due to it's data binding approach.

The idea is to serve the SPA from Django, dynamically generating it so that the great model based apps that one can create with the current admin site can be dynamically generated in a similar way, but as an SPA.  Why SPA.. just to enable a better, more powerful user experience without the round trips and page reloads.  

Hoping it will in the same way form a RAD tool for SPA development with a Django back-end.

If we get really smart, we may be able to make it theme-able.

I have messaged the django dev group as I have had a look at the work that may be involved and I believe that if we we're to succeed in making this a standard addition to django as an admin alternative, we make have to accommodate it in the code a bit... there may be a bit of refactoring of the admin code.

Just wondering if anyone would be up for joining me in creating something like this?... or if you know of an existing project trying to do this?

Thanks

Warren

[Vasanth Mohan]

Hi Warren,

An SPA sound interesting but should be based on React or other SPA frameworks? While I’ve not looked into it very much Webcomponents are part of the Spec since 2012. Vanilla JS can be leveraged to create the admin and the project developers can choose to extend it with the framework of their choice.

I’m relatively a inexperienced  developer but I’d very interested in contributing with a project like this.

[quest...@gmail.com]

I have project similar to Django admin, implemented with Knockout.js:

https://github.com/Dmitri-Sintsov/django-jinja-knockout

Today probably it would be preferable to use "vanilla ES6" or Svelte, because these options would minimize the dependence on third party libraries and bundlers, it would produce the cleanest package.

[Christian González]

Hello,

my 2 cents here. I've searched for years to find "the right" frontend for Django. Tried, React, Angular, Vue, Svelte, and many others, even developed GDAPS, a Django plugin system with flexible optional frontend integration optionally (Vue only ATM - but the frontend integration is stuck, read below why), and almost got crazy. I ended up in forgetting all the frontend frameworks altogether as they all are completely un-pythonic and un-djangoish, get into your way and force you to re-write everything you already had working.You have to write all the logic of views again in your frontend of choice, and well, do the validation *again* in the backend. So everything gets more complex, with the "benefit" of getting a few milliseconds and fewer round trips. It's just "cooler".

Oh, and yes, forget Django's template language. In the best case the frontend barks at it and you have to define own variable delimiters (Vue) if mixed into the templates, or it isn't even possible to use it without getting into big trouble. You'll end up defining a separate project, and using REST or GraphQL for communication with Django. Additionally you have to throw webpack, rollup, parcel, or any other bundler of your choice into the mix. Which then won't like your non-admin-frontend.

What I ended with, and that has none of those disadvantages, is HTMX. Keep your views, keep your templates, keep your validations/validators, render everything serverside, just salt the html templates with some HTMX attrs where needed. Works almost perfectly, and even could be added incrementally.

If I would develop a better Django admin, I'd go for HTMX. (and I tried Sockpuppet, Unicorn, and many others too.)
If it was for me, I even would add a neat HTMX integration to Django core.

Cheers, Christian

Am 15.10.21 um 08:52 schrieb Warren Havemann:

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c29b745c-21d5-46c8-ab51-312b1a73114dn%40googlegroups.com.

-- 
Dr. Christian González
https://nerdocs.at

[Asif Saif Uddin]

Hi guys,

the django admin still need to dogfood many new django features. we can start with that. for reference you can check django-admin2.

thanks,

Asif

[Jacob Rief]

I really would like to see the django-admin being more SPA-like. I therefore wrote a library which implements all the features of the admin's change view

and much more. It is very Pythonic/Djangonic in the sense, that it does not require to write any JavaScript, nor HTML. You can just use your Django Forms

as usual in a slightly modified Django View.

Here is a list of features:

• Before submitting, our Form is prevalidated by the browser, using the constraints we defined for each Django Field.
• The Form's data is send by an Ajax request, preventing a full page reload. This gives a much better user experience.
• Server side validation errors are sent back to the browser, and rendered near the offending Form Field.
• Non-field validation errors are renderer together with the form.
• CSRF-tokens are handled through a Cookie, hence there is no need to add that token to each form.
• Forms can be rendered for different CSS frameworks using their specific style-guides for arranging HTML. Currently django-formset includes renderers for Bootstrap, Bulma, Foundation, Tailwind 1 and UIKit.
• Support for all standard widgets Django currently offers. This also includes radio buttons and multiple checkboxes with options.
• File uploads are handled asynchronously. This means that the user opens the file dialog or drags a file to the form. This file then is uploaded immediately to a temporary folder, returning a unique handle together with a thumbnail of it. On form submission, this handle then is used to access that file and proceed as usual.
• Select boxes with too many entries, can be filtered by the server using a search query. No extra endpoint is required for this feature.
• Radio buttons and multiple checkboxes with only a few fields can be rendered inlined rather than beneath each other.
• The Submit buttons can be configured as a chain of actions. It for instance is possible to change the CSS depending on success or failure, add delays and specify the further proceedings. This for instance allows to specify the success page in HTML rather than in the Django View.
• A Formset can group multiple Forms into a collection. On submission, this collection then is sent to the server as a group a separate entities. After all Forms have been validated, the submitted data is provided as a nested Python dictionary.
• Such a Form-Collection can be declared to have many Form entities of the same kind. This allows to create siblings of Forms, similar the Django's Admin Inline Forms. However, each of these siblings can contain other Form-Collections, which themselves can also be declared as siblings. This list of siblings can be extended or reduced using one "Add" and multiple "Remove" buttons.
• By using the special attributes show-if="condition", hide-if="condition" or disable-if="condition" on input fields or fieldsets, one can hide or disable these marked fields. This condition can evaluate all field values of the current Formset by a Boolean expression.
• The client part, has no dependencies to any JavaScript-framework. It is written in pure TypeScript and compiles to a single, portable JS-file.

That library only runs with Django>=4 and will be announced together when Django-4.0 will be released. A working prototype can be found here:

https://github.com/jrief/django-formset

– Jacob