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
On Mon, Feb 4, 2019 at 9:31 PM Jason Johns <jjohns98...@gmail.com> wrote:
> 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.
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAFzonYbN9E3fQk0qCpAGd7aBSN97zAL4hXqLXhNoqAUraxYs4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
