Admin webcomponents

[1337 Shadow Hacker]

Hello everybody,

Currently, the admin site provides various form fields, and formsets, that depend on JS scripts.

These are loaded by form media.

Nowadays, webcomponents have made it into standard HTML, all browsers now support:

- Custom Elements: https://w3c.github.io/webcomponents/spec/custom/

- Shadow DOM: https://w3c.github.io/webcomponents/spec/shadow/

- ES Modules: https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-module-system

- Template elements: https://html.spec.whatwg.org/multipage/scripting.html#the-template-element/

Proposal: upgrade the admin JS from Form.Media to webcomponents.

When/If this gets done, we will have the maturity to start extracting webcomponent code from the admin site into main Django, as such, I see this proposal as the required first step before trying to deprecate form media in future releases.

Needless to say, webcomponent support would be really good to have for Django 4.

Thank you in advance for your feedback

Have a beautiful day

[Jacob Rief]

I'm very much in favor of this. Getting rid of jQuery is a very important step to make Django future-prove.

In my other (non-legacy) projects, I currently replaced all JavaScript against webcomponents. I actually made good

experience with the StencilJS compiler. Compared to Svelte, I really appreciate the clean syntax and the readability

of the generated code of those components.

The big advantage of webcomponents is, that they play well together with all existing JavaScript frameworks

out there, hence embracing all developers using one of those. I recently found this article on Hackernews which

boils it down quite well.

Many years ago, I wrote a Django app to integrate client-side form validation with Django's server side logic.

See here  https://django-angular.awesto.com/combined_validation/

At that time it was based on AngularJS. The idea however remains the same and could well be applied to an

approach using webcomponents.

I'm very much interested in this topic, because I already implemented parts of this in AngularJS, although this now is

an obsolete technology.

– Jacob

[1337 Shadow Hacker]

I cannot state how excited I am to see such as seasoned Django hacker as Jacob being up for the task. I believe I'm not the only one who have had, for a long time now, a vision for Django where the effort in the django.contrib.admin becomes usable outside the admin and end up beating Rails on generic views and stuff.

As much as I have a fantastic experience with StencilJS as an avid TDD and Unit Testing fan myself, I don't see jQuery going anywhere in any kind of future. While you don't need it so much anymore for basic things, but for some advanced usages it does provide a friendlier API than the DOM. And if you're going to pull it for a reason or another, why would you want to write document.querySelectorAll instead of $() ...

Also, keeping jQuery in the first iteration will force figuring out dependency management, how Django wants to leverage the browser import calls. So, as long as we have something else to tackle this, then removing jQuery would be fine. But keep in mind a lot of stuff uses it, such as select2, however, we might also decide to use other autocomplete webcomponents.

> Many years ago, I wrote a Django app to integrate client-side form validation with Django's server side logic.

Well that looks really good, we're also undergoing efforts in the ryzom library, and also had another interesting pattern proven in a library called facond, both of which might be worth to take a look at if you also get your kicks from this kind of stuff.

https://facond.readthedocs.io/en/master/index.html

https://yourlabs.io/oss/ryzom

> I'm very much interested in this topic, because I already implemented parts of this in AngularJS, although this now is

> an obsolete technology.

Well the fast deprecation of JS frameworks has been a problem for Django for years, and for a good reason.

This is why I believe we can see salvation in the webcomponents standards, living since 2017 and now available in every browser engine, the time has come for Django to keep up with the W3C standards.

[Carlton Gibson]

Hi Both.

Jon Dufresne (mainly just him) had been doing a super job removing the jQuery dependencies in the admin, and modernising the JS whilst he's at it. It's approaching just "vanilla" JavaScript, all nice and modern, and linted.

The blocker here will be Select2 -- we're not going to rewrite that ourselves. (Anyone know if they´re rewriting without jQuery?)

Leaving Select2 aside though, what are the advantages to components that the JavaScript we have doesn't satisfy? The Admin JS is not THAT complex... what more do we need?

This (obviously) needs someone to step forward to write the code. I'd guess a prototype mini-project demonstrating one bit would be good to see. Then we could compare the code and see what the gains are.

I recall seeing various articles complaining about web component accessibility. I presume this would be addressable, but it's something to bear in mind.

Kind regards,

Carlton

[1337 Shadow Hacker]

Hi all,

We got a working PoC here: https://github.com/yourlabs/djwc

Advantages:

- no more nodejs

- no more webpack

- no more form.media

- as such, much more reusable

- no more manual asset management in templates

- works with components of any framework that can build them as webcomponents

- no more need for a script to depend on a specific HTML structure, which makes the HTML elements portables outside the admin easily (in theory!)

Disadvantages:

- Does some regexps response.content

- Custom elements requires aria attributes to keep accessibility features

- Adds a step prior to collectstatic

Keep in mind it's a PoC, I want to use this to replace MaterializeCSS by Polymer in CRUDLFA+ though, so hopefully I'll take the time to thoroughly test and optimize it and confront it to a complete CRUD situation.

As such, unless anybody wants to discuss it more, I will maintain it in the separate repo for a couple of years before I come back to push it forward.

Have a great day

[1337 Shadow Hacker]

Another advantage that I figured while finishing the DAL 4.0 PoC offering the AutocompleteLight WebComponent support in addition to Select2:

- easy to template with <slot>

Example:

    def render(self, name, value, attrs=None, renderer=None):

        choice = self.field.queryset.filter(pk=value).first()

        deck = self.field.render_choice(choice) if choice else ''

        return mark_safe(f'''

            <autocomplete-select>

                {super().render(name, value, dict(slot="select"))}

                <div slot="deck" class="deck">{deck}</div>

                <autocomplete-light slot="input" url="{self.url}">

                  <input slot="input" type="text" />

                </autocomplete-light>

            </autocomplete-select>

        ''')

[Jacob Rief]

In the past month, I have written a webcomponent, which encapsulates most of the functionality the Django admin's change view implements.

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 Form

as usual, warp it inside that component <django-formset>...</django-formset> and use a slightly modified Django View.

Here is a list of additional 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 proceeds 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