Extend FAQ with "How do I get Django and my JS framework to work together?"

[Maciek Olko]

I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS framework to work together?" or similar question and answer to it in FAQ in Django's docs.

Having very big popularity of JS frameworks now it is indeed very common question being asked or searched on the Internet. Such question for ReactJS has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend and produce API to be consumed by JS clients. Probably it would be good to link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,

Maciej

[1] https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together

[Kye Russell]

Say what you want about the arguably unnecessary proliferation of complex JavaScript applications / build pipelines upon the Internet over the past 5 or so years, but there’s no denying it’s becoming a necessary component in a large portion of complex web projects.

I also think that—if it hasn’t already been done so already—the Django documentation should at least contain a passing acknowledgement of this, as well as some guidance on how to accomplish this.

Compare this to the latest iteration of Rails (I’ve never done more than take a passing glance at the framework’s progress and am certainly no expert) which includes a full webpack JS / asset pipeline as standard. I’m aware of the philosophical differences between Django and Rails, and I’m not necessary saying that bolting on Webpack was the right decision, but it’s certainly speaks to how ‘back end’ framework development could lend a helping hand beginners with a project that lends itself to a JS / API-driven approach.

Kye

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Curtis Maloney]

On 2/5/19 11:52 AM, Maciek Olko wrote:
> I didn't find this topic being discussed before.
>

I guess it wouldn't take much to say "Just like any other server-side
framework that can parse and generate arbitrary content, Django can be
used to support any Javascript or Mobile app that talks HTTP(S)."

Since Django doesn't care what the client is, so long as it talks HTTP...

--
Curtis

[Cristiano Coelho]

Pointing to Django Rest Framework should be more than enough. Anyone starting a project with Django and a SPA/JS architecture, will pretty much end up with DRF. Correct me if I'm wrong.

[Jason Johns]

Tom Christie wrote this about what DRF brings to the table over plain Django:

Django REST framework isn't required, but it helps you get a lot of things right that will be time consuming and error prone if you're working from core Django.
• Serializers
The Django serializers are not really suitable for anything other than dumping and loading fixture data - they don't allow you to customize the representation in any substantial way.
Using Django Forms for validation isn't suitable either as they're intended for HTML only validation and can't eg handle nested validation.
REST frameworks serializers are designed for API usage and cover both JSON or form validation, as well as being able to represent as either HTML Forms or formats such as JSON. They also give you lots of scope for handling the representation of relationships, such as using hyperlinked relations.
• Authentication and permissions
REST framework's authentication will gracefully handle both session based and token based schemes at the same time, and get the CSRF behavior right. You'll find that really awkward to do if using plain Django. It also helps ensure you're issuing failure responses that are suitable for API clients (eg get 401 vs 403 responses right)
The auth, permissions and throttling are also more flexible because they're defined at a view level, rather than as middleware or a view decorator. This makes it easier to eg combine multiple schemes, or to apply different schemes to different parts of your application.
• Views
Django's generic class based views are suitable to HTML applications. REST framework's generic class based views are suitable for API services. Typicallly API views have slightly different behavior by convention. Eg create in an HTML application might typically redirect the user to the created item, whereas an API will respond with a 201 CREATED response.
There's stacks of other functionality and behavior that makes using Django REST framework simpler, quicker and likely more correct than if you start with plain Django. But those are some of the obvious differences to get started with.

https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1

Seems pretty concise and self explanatory to me. This could easily be adapted to be in the docs.

[Dan Davis]

I kind of disagree that saying it works with DRF is enough.  One issue that needs to be addressed is matching any possible path with re_path, so that an SPA that takes over the browser history API will work with bookmarks.

Django is opinionated.  The winning strategy for npm frameworks is to let the CSS/JS/assets come from the framework.  While many projects have used django-pipeline or django-compressor to good effect, if you use webpack+react or angular cli, then the output can be a couple of pre-cache busted bundles, and the solution is:

   (a) tell the javascript framework to put its output files in a particular directory,

   (b) tell Django to look there with STATICFILES_DIRS,

   (c) Write something to generate tags for the static assets, either a templatetag or a staticfiles finder/storage.

I think it would be good to include with Django some template tags that can find a cache-busting bundle by the bundle name, maybe using a manifest generated during create static.   My code isn't great, but it works like this:

from django.templatetags.static import static

from ng_loader.utils import BundleMap

logger = logging.getLogger(__name__)

if not settings.DEBUG:

    _map = BundleMap(settings.STATIC_ROOT)

register = template.Library()

@register.simple_tag

def ng_load_cssbundle(name):

    if settings.DEBUG:

        fname = '{}.bundle.css'.format(name)

    else:

        fname = _map.get_bundle('css', name)

    logger.debug('Serving css bundle {} from {}'.format(name, fname))

    return mark_safe('<link rel="stylesheet" href="{}"/>'.format(static(fname)))

@register.simple_tag

def ng_load_jsbundle(name):

    if settings.DEBUG:

        fname = '{}.bundle.js'.format(name)

    else:

        fname = _map.get_bundle('js', name)

    logger.debug('Serving js bundle {} from {}'.format(name, fname))

    return mark_safe('<script src="{}"></script>'.format(static(fname)))

With the bundle map being created like this:

import os

import re

class BundleMap(object):

    def __init__(self, rootpath):

        self.rootpath = rootpath

        self.rebuild()

    def rebuild(self):

        self.map = { 'css': {}, 'js': {} }

        for name in os.listdir(self.rootpath):

            m = re.match(r'([a-z]+)\.[a-z0-9]+\.bundle.(js|css)', name)

            if m is not None:

                bname = m.group(1)

                btype = m.group(2)

                if btype in self.map:

                    self.map[btype][bname] = name

    def get_bundle(self, btype, name):

        return self.map[btype][name] if name in self.map[btype] else None

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/af24d69f-1d16-40db-9558-11745fce2399%40googlegroups.com.

[Curtis Maloney]

On 2/5/19 1:09 PM, Cristiano Coelho wrote:
> Pointing to Django Rest Framework should be more than enough. Anyone
> starting a project with Django and a SPA/JS architecture, will pretty
> much end up with DRF. Correct me if I'm wrong.

It's likely they'd end up with DRF, however there are alternatives.

However, by explicitly listing DRF, it might give the impression it's
the "blessed" solution by Django...

--
Curtis

[ludovic coues]

My current job is working on the django backend of a SPA/JS. Truth is, our django does not serve any JS file. The whole SPA is a bunch of static files, served by nginx. Every and only request with a path starting with /api are routed to Django.

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net.

[Carlton Gibson]

I think this topic is very interesting. 

Two sides of it: 

* Static files handling

* APIs

Curtis is right, there are other options but, Django REST Framework is (whilst not perfect) pretty solid on the API front. I think Django has a good story here. 

It's pretty hard not to find DRF if you follow any guide, or any searching at all. 

The static files story is a little different. It seems to me we don't tell the best story there. 

Rails has two things which we could be envious of, even if we didn't want to copy exactly:

* The frontend framework integration that's already been mentioned. 

* The very easy "Ajax your form", with controllers (i.e. for us "generic views") automatically handling ajax form submissions. 

Both these features get users further quicker in these aspects than we are able to offer. 

We struggle to think of areas for improvements (re GSoC for example) but maybe here is an area. 

This ties into Claude's proposal here: https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion

My own story is, I've had lots of success with, and still use, Django Compressor.  

• At it's simplest you just map a content type to a shell command to run and then include your Sass/Less/React/Elm/whatever files in your HTML (with script or link tags, almost in the old-school way). 
• In development these are processed (& cached) per request. 
• For deployment you just run an offline compression task (management command) and then upload the files. 
• That's it. 

It's not a coverall approach — a frontend engineer will come along and totally replace Compressor with whatever is this week's Top Javascript Build System™ BUT it is a good 80:20: it lets me do something (that approximates) respectable, without knowing hardly anything about the latest frontend hotness. (GNU Make FTW! 🙂) 

I think if we were to offer something out-of-the-box that got as far as Compressor, or further, we'd:

• satisfy most of our users, 
• allow yet more to get off the mark quickly, 
• and... well... those that need the full frontend toolchain would still be free to use it. 
  

I worry we'd never get anything like this into core... but I think it would be good. (As I say, I think it's one area where we are lacking/behind the competition.)

Kind Regards,

Carlton

[Jamesie Pic]

Throwing in some food for thought that may be worth mentioning and that we like to play with:

- django-webpack-loader merged code chunking recently

- transcrypt allows coding ie with react in Python, transcrypt also supports webpack

- chp is a project that aims to replace templates as we know them by functions, it's a minimal port of react, it relies on transcrypt for isomorphic support

From my pov it seems webpack is establishing as a standard worth supporting, but code chunking is really nice to have for a better loading experience.

In pure Django we used to chunk by extending a script block in non-base templates.

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com.

[Dmitriy Sintsov]

Speaking of Rails AJAX forms. It's quite trivial to submit Django ModelForm in Javascript AJAX request. It's a bit harder to have the customizable success action and to display the field validation errors via AJAX response.

I implemented AJAX viewmodels for that:

https://django-jinja-knockout.readthedocs.io/en/latest/viewmodels.html#ajax-actions

However it's the mixed traditional forms + AJAX approach, not the pure SPA. In pure SPA Django becomes the "data supplier" where most of the templates, forms, presentation is performed by Javascript framework.

So, the question is, whether the features of Django such as inline formsets and custom widgets are required, or should Django become the data store only.

[Dan Davis]

The problem with ModelForm is translating validation to something front-end, like jquery Validator.   Here, DRF does better, because swagger spec includes something like jsonschema (neither are a standard as I used to know them, in the WSDL/SOAP days), and so you can use jsonschema validation to validate on the front-end.   I think what is needed is some way to map validate-only to the back-end, and do a sort of 2-phase commit - validate before the user presses OK, and then save (PATCH) when the user presses save/apply/OK.

--

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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0cafc96d-bc4f-4316-9022-28e5134a1bcd%40googlegroups.com.

[Jamesie Pic]

Well, there's also Graphene. It's at least REST or GraphQL.

--

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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87fb9a35-b274-4d62-b17c-602114719ad5%40googlegroups.com.

[Aymeric Augustin]

Hello,

I wrote a three-part essay on this question last year:

1. https://fractalideas.com/blog/making-react-and-django-play-well-together/

2. https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/

3. https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/

Even though I took a narrower view — I only considered React — I found enough decisions factors to write over 2000 words in the first post, which is too long for a FAQ :-)

On one hand, I'm not sure the Django docs should go into this level of detail and provide specific information about a particular JS framework. On the other hand, it's rather useless to talk about integrating Django with a JS frontend without discussing authentication and it's hard to discuss authentication in less than 2000 words — which were just for justifying my favorite solution, not for investigating every option!

I think we need a how-to guide rather than a FAQ entry. I would find it nice:

A. To describe the Singe Page App model — where Django only serves the API

We need to explain CORS and CSRF in the clearest terms possible. Many devs end up shotgun-debugging CORS or CSRF errors, which always results in insecure deployments.

My consulting experience suggests that we have a problem there: I never did an audit where the client got that right, even though they're all smart people trying to get things right.

Perhaps a condensed version of my third post could do the job?

Some may disagree with my recommendation against JWT, which may too opinionated for the Django docs. Again, in my experience, people tend to get security more wrong with JWT, which is why I prefer discouraging it and letting those who know what they're doing ignore my advice.

B. To say something about integrating a modern JS framework with django.contrib.staticfiles 

It's perfectly doable and provides all the benefits of django.contrib.staticfiles. However, it requires a bit of duct tape, as shown in my second post.

I'm a huge fan of this technique for simple website but I'm afraid I'm biased by my experience with Django. This is unlikely to be a popular option for those who are more familiar with a modern frontend framework than with django.contrib.staticfiles.

The docs should at least give the general idea of "compile your frontend to somewhere Django can find the files, then run collectstatic".

If someone starts writing documentation about this, I'm interested in reviewing it.

Best regards,

-- 

Aymeric.

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com.

[Dmitriy Sintsov]

Very nice tuturials! Although there is web components standard gradually being adapted by major browsers, which should bring custom tags / components not having to use the third party Javascript libraries like Vue or React. So, while in Python world the leadership of Django is quite stable and obvious one, in Javascript world it's not so easy to say whether Vue and React would dominate in a long run. Maybe Marko or Stencil.js are closer to the future vision of Javascript.

You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/KVAZkRCq9KU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CBFA85F9-3EE1-4B74-B121-F178F551D9CD%40polytechnique.org.

[Josh Smeaton]

For the vast majority of users, right now, Vue or React are the only real options. Let's not try predicting the future, and just focus on what the trends currently are. Users going for newer targets are likely more advanced, and can figure out the necessary changes.

Aymerics articles are fantastic, and our team has gotten a lot of value out of them for our newer projects. Especially the customisations to static files which removes the re-hashing of static content. I would be very keen for Django to provide a first class integration method with Webpack, in particular, but most popular bundler frameworks if the necessary interfaces exist.

- "Importing" static content that has already been bundled and hashed

- Automatic reloading of static content as it is being changed

- Visual debugging in editors

I think the idea of a how-to that considers authentication and communication between frontend and backend is also what we need.

So while I don't think Django needs to bless a particular frontend framework, I think we have to provide a really nice integration story so that the most popular JS frameworks do not have to jump through a lot of hoops, including copy and pasting large sections of code, to get their existing tooling working with Django. I no longer think it's enough to require 3rd party django libraries to make the frontend integration possible.

[Jani Tiainen]

Hi,

As we are heavy ExtJS and DojoToolkit users we've encountered quite a much problems since both frameworks do have their own toolchain and it doesn't seem to fit to webpack or rollup or anything like that.

So if such a feature is planned for core I really hope that non mainstream tools are left out, at least without possibility to make them work easily.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b36c1ba6-0473-47d3-87e5-6b2c5c9ecbf9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

[Jamesie Pic]

Also in Django maybe try to change things like:

class Textarea(Widget):

    template_name = 'django/forms/widgets/textarea.html'

With

component = dict(
    template_name='django/forms/widgets/textarea.html',
    script='your/textarea.js',
    style='your/style.css'
)

Or something component='your.favorite.TextArea', then you could also hack django.forms.widgets.component to change the default rendering at the project level. Maybe then distribute more exciting component objects that accepts this dict interface in pip packages that could work with any python framework.

Anyway, keep on pursuing your dream stack, always happy to read some exciting discussions on this matter ;)

Have a great day

[Jamesie Pic]

On Mon, Feb 25, 2019 at 10:39 PM Jamesie Pic <jp...@yourlabs.org> wrote:
> component = dict(
> template_name='django/forms/widgets/textarea.html',
> script='your/textarea.js',
> style='your/style.css'
> )

Actually do NOT try this, for static i think the more efficient
refactor would be to enable widgets and things to touch
request.static.scripts and request.static.styles, so that scripts that
you load in your parent template would not be re-added by the widgets.
At the same time, programing perimeter for widget statics would
increase since this would no more reduce it to a declarative
structure.

And maybe you want to try to change from templates to python rendering
functions, if not for transpiling or performance, performance, maybe
just for easier reuse across python code in general. But then you
would use a python library that

FTR GDAPS is also having research on this as we speak :
https://gitlab.com/nerdocs/gdaps/issues/2

Have fun

--
∞

[Jamesie Pic]

FTR I published my own writeup here:
https://blog.yourlabs.org/post/183077442308/django-js-research-report

[Maciek Olko]

Thank you all for all your responses!

It's been a long time (sorry!), but:

* I've added a Django ticket considering topic discussed here. [1]

(* I updated a bit AJAX Django wiki page. [2])

Aymeric, in terms of copyright ownership, would you agree on rephrasing fragments of your articles to put it into Django docs?

Regards,

Maciej

[1] https://code.djangoproject.com/ticket/30296

[2] https://code.djangoproject.com/wiki/AJAX

śr., 27 lut 2019 o 15:37 użytkownik Jamesie Pic <jp...@yourlabs.org> napisał:

FTR I published my own writeup here:
https://blog.yourlabs.org/post/183077442308/django-js-research-report

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.com.

[Nathan Gaberel]

Hi everyone,

I've been working on this for a while too (for React & Webpack
specifically) and will be sharing my current setup at DjangoCon Europe
next week.
For those of you attending, please come and talk to me, I'd love to
get your feedback and maybe we can exchange ideas. :)

Best,
Nathan

> You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/KVAZkRCq9KU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG80eYMHMqis10UpxsehTdQRObxKP5c7c%2Bfr9TF6fLdxTwA%40mail.gmail.com.