Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEP 84: Rejuvenate form media #84

Closed

Conversation

thibaudcolas
Copy link
Member

@thibaudcolas thibaudcolas commented Dec 19, 2023

Draft, not ready for review yet

Read the DEP as HTML

For context, see the forum thread: Rejuvenating vs deprecating Form.Media.

Copy link

@matthiask matthiask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think introducing the JS class from django-js-asset into Django would be worthwile; probably a few parts of the admin should be refactored to take advantage of this? It's very stable, nothing has changed since the beginning of 2022.

Comment on lines +31 to +42
- ES modules
- Import maps
- Dynamic module imports
- async, defer scripts
- CSPs via nonce attributes
- integrity attribute
- fetchpriority attribute
- nomodule attribute
- Arbitrary script attributes
- Preloading / speculative loading
- Resource ordering (see `capo.js <https://rviscomi.github.io/capo.js/>`_)
- Web Components
Copy link

@matthiask matthiask Jun 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a very complete list. As I already said on the forum thread, I think that the frontend tooling space is still moving so quickly that it's hard to know which tools may or may not be useful in a few years time. When I think about Django and it's stability I have a horizon of several years always, with frontend tooling that's just not the case. If we had more fellows and/or more people which are paid to work on Django it could be a good idea. Even though I'm actually a (p)react and web/rspack fan I think it's a good idea for Django to stay in the backend world.

So, I think there's a lot of value in trying to support CSP (that was one of the motivations for django-js-asset, see https://406.ch/writing/django-admin-apps-and-content-security-policy-compliance/ ), supporting additional arbitrary attributes on <script> tags etc. but that's it.

I'm not sure I understand the resource ordering thing. Django already supports relatively complex dependencies (at least since https://code.djangoproject.com/ticket/30153). Of course that doesn't do anything about the initial page loading performance, but then you're already in the area of bundlers again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my perspective everything on that list has already proven its usefulness quite clearly! Additional attributes on <script> would be really useful but that feels to me like a rejuvenation of the Media API to bring it to 2014 standards rather than 2024.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also be adding anything about Django providing polyfills?

As in


Opt in set of polyfills to support some/all of the above via pre-approved CDNs. Import maps, ESM, Web Components being the main ones. 

This is something the Rails approach did I believe, to allow for a 'simple' cross browser support approach where developers didn't have to think about what to include.

@claudep
Copy link
Member

claudep commented Jun 9, 2024

I think introducing the JS class from django-js-asset into Django would be worthwile; probably a few parts of the admin should be refactored to take advantage of this? It's very stable, nothing has changed since the beginning of 2022.

Big +1. When I pushed for django/django@4c76ffc2d6c77, it was my hope that at some point we could agree on some class-based JS/CSS objects (see the example in test_media.py).

@matthiask
Copy link

Hi @thibaudcolas

Is there anything I can do to move this forward?

@thibaudcolas
Copy link
Member Author

@matthiask would you be up for writing the "new attributes for <script> tags, and why we need them" side of the DEP? Then we can get things moving with this, and from my side I can focus on the research I want to do for other requirements for merging of form widgets’ dependencies.

@matthiask
Copy link

@thibaudcolas I have been thinking about this at least once every week. Sorry for not responding sooner. The part about why we need additional attributes for <script> tags is probably not needed for the DEP anymore because django/django#18782 exists and is in a good state. For the DEP we should be able to assume that we already have an understanding regarding this, at least I have a lot of hope for it.

I think it would be interesting talk about importmap merging and ES module loading; I created an issue here yesterday codingjoe/django-esm#38 , but maybe this DEP would be a better place for the discussion around that.

@thibaudcolas
Copy link
Member Author

Unfortunately I’ve decided I should stop working on this for now, so will close my draft :l @matthiask sorry for the start and stop! I still think this is very promising for Django, as a way to support (more) modern front-end development practices. But I’ve taken on new responsibilities as President of the DSF starting in December and I don’t see myself finding time in 2025 to work on substantive code contributions. I’m still happy to provide input occasionally but even for that I think I should focus on my commitments to Django’s accessibility team, so anything else will be "best effort" only.


With that said – yes please! I’d say import map merging is a great candidate for Django core’s Media. My rationale:

  1. They seem pretty important to load ES modules at predictable paths while still allowing Django’s static files storage backends to do their thing.
  2. Currently browsers only support one import map per page. Django’s current approach to leave UI / front-end to the packages ecosystem would work much better if it facilitates the merging, rather than having every package either teach its users how to manually merge, or create a thousand different APIs to do the merging.
  3. They greatly simplify reusing JS between UI components, which is a big part of what Media is about

I think points 1. and 2. are pretty good reasons even without 3., but I tried to find good examples of "reuse between UI components" anyway.

  • Rich text editors. In the case of Wagtail, there’s a built-in rich text editor, but a lot of people also want to use their own bespoke integration. It would be great if both flavors of the editor could load the same JS bundle rather than having it duplicated. The editor versions rarely change (6 releases in 6 years, only one with backwards-incompatible changes), so likelihood of compatibility between two integrations is high.
  • The Axe accessibility checker. Also in Wagtail, we have it integrated into our "userbar" widget loaded on all pages. I’d also like to push our users towards a more developer-focused integration as a custom django-debug-toolbar panel. It’s a big dependency so crucial to dynamically load, and ideally only once.

Other changes

In addition to the script attributes we already discussed, I think it’d also be good for Media to evolve by:

  • Making it not just about forms and their widgets. I would guess this is 90-99% a documentation-only change. I don’t see any reason why it has to be recommended for forms only – see the Axe example above. For Wagtail we’ve done this and a bit more with the laces library by my colleague @tbrlpld.
  • Supporting rel=modulepreload. This is a natural next step once people start to use dynamic loading.

Sorry again I have to leave this there! I hope others will be able to make further progress.

@matthiask
Copy link

Thanks for your thoughts and the support! I totally understand. If I find the time and energy I'll resurrect the DEP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants