7 ms·

The biggest challenge to using Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this de

The biggest challenge to using Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. Most parts of the site I want server-rendered, while in stateful parts I want React. So, let's say I have a site with 20 different React "apps" (i.e. stateful components) that I want to distribute amongst my various Django sections (Django "Apps" within the same project). And I want to do that with one webpackconfig. How do I tell my webpack where to put all those react bundles? The answer I've found is django-webpack-loader[1], however as you can see in the Issues section, one of the biggest limitations here is the inability to chunk React (and other issues). Does anyone have a solution they like for this kind of isomporphic Django problem? 1. https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader

Demiurge 6y ago
What do you mean by "inability to chunk React"? I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries. You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
- syndacks 6y ago
  Sorry, "chunking" is code-splitting. https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html
bredren 6y ago
Yes. I have large portions of a server-rendered, django web application that uses react largely as you've described. I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar) Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls. My goal was to minimize customization while retaining the "spirit" of both Django and react. I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling. It also makes it more likely the react app can be migrated to new versions of CRA. The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*. Key aspects of my implementation are: - Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django. - Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path. - Customization of HtmlWebpackPlugin to modify CRA's: - Out-of-box behavior of webpack bodyTags and headTags. - webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file. Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2] I have not released my solution but I have stubbed out the problem and solution description [3]. If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4. All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app. Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA. Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend. [1] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [2] https://github.com/gsoft-inc/craco/pull/203 https://github.com/gsoft-inc/craco/pull/203 [3] https://github.com/banagale/create-react-app-django https://github.com/banagale/create-react-app-django
scrollaway 6y ago
I've worked with Django for 12 years and I don't know why you would want to use their awful templating language. It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload. And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).
- bredren 6y ago
  I don't think django tempating is as bad as you've described but one reason is that a project is long-standing and dev resources are already familiar with it. A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well. The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
  - scrollaway 6y ago
    Absolutes never exist :)
- aiisahik 6y ago
  Totally agree with your assessment of Django in terms of its templating and SSR abilities. It's horrible and should be avoided at all costs. However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
  - scrollaway 6y ago
    Yes I agree with you. My favourite stack right now is Django with DRF+Admin for backend, Typescript+NextJS (React) for frontend. I front the backend with Caddy, have django live on both admin.example.com and api.example.com with a couple of rewrites, and put cloudflare access in front of admin.example.com. Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup). The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
aiisahik 6y ago
I've spent many years working on django including production setups for 3 different companies. My strong advice is to only use Django for API calls (DRF) and the built in admin UI. Do not use Django for ANY client facing static site rendering. 1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy. 2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved. 3. Use https://github.com/ctrlplusb/react-async-component https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis. Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.
- bredren 6y ago
  That's a nice idea for new projects but how would you handle a company with large existing Django sites that want to bring in one or two react-based SPAs?
  - deleted 6y ago
    [deleted]
  - nickserv 6y ago
    We did this with Vue.js, not sure if it applies to React (I haven't used React). The way we did it was to start with a few parts of the page that really benefited from having Vue.js, using a simple `script src=`. So no components or anything fancy. For this we just put the JS stuff using Django's template system. Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN. In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON. In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
- 6y ago
silviogutierrez 6y ago
That's exactly what https://github.com/silviogutierrez/reactivated https://github.com/silviogutierrez/reactivated does. It's a work in progress and docs are coming. But it's the best of both worlds: Django SSR using statically typed JSX. See for example my blog or business sites (on profile). Both SSRed by Django using React templates. Then when the client loads, it gracefully "attaches" for dynamic interactive behavior as needed. By far the biggest pain point is having to run node and python on the server. So I'm working on the best way to do that.
shinryuu 6y ago
> Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. What we want from something like react after all is reactivity, and it's possible to get that if you were to use something like https://github.com/jonathan-s/django-sockpuppet https://github.com/jonathan-s/django-sockpuppet So if you've got an open mind and want to test it's there for the taking.
krzepah 6y ago
"I don't want to go full SPA with Django as this defeats the purpose of Django IMO" -> What is this "purpose" ? Django is here to help me model my database, handle few permissions and bring few API up online, I see no problem with having a PWA in front of it. Are you trying to get all of your website server rendered ? In which case you could do that without having to worry about integrating it with Django... TBH after 5 years of react and 8 of Django, i'm just not mixxing them up except for the front-end calling a query on the back-end (which both can be served at the same domain using nginx) ;
czue 6y ago
When you say "tell webpack where to put the files" what do you mean exactly? I recommend just making one bundle per "app" (can be configured as different entry points in your webpack config), and then using the outputs as standard Django static files. I found django-webpack-loader to be a little to magical for my taste and solving a problem that didn't really exist for me (the need for refreshless hot reloading). More details on this approach here: https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/integrating-javascript-pipeline/ https://www.saaspegasus.com/guides/modern-javascript-for-dja...

Demiurge 6y ago

What do you mean by "inability to chunk React"? I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries. You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.

syndacks 6y ago
Sorry, "chunking" is code-splitting. https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html

bredren 6y ago

Yes. I have large portions of a server-rendered, django web application that uses react largely as you've described. I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar) Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls. My goal was to minimize customization while retaining the "spirit" of both Django and react. I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling. It also makes it more likely the react app can be migrated to new versions of CRA. The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*. Key aspects of my implementation are: - Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django. - Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path. - Customization of HtmlWebpackPlugin to modify CRA's: - Out-of-box behavior of webpack bodyTags and headTags. - webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file. Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2] I have not released my solution but I have stubbed out the problem and solution description [3]. If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4. All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app. Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA. Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend. [1] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [2] https://github.com/gsoft-inc/craco/pull/203 https://github.com/gsoft-inc/craco/pull/203 [3] https://github.com/banagale/create-react-app-django https://github.com/banagale/create-react-app-django

scrollaway 6y ago

I've worked with Django for 12 years and I don't know why you would want to use their awful templating language. It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload. And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).

bredren 6y ago
I don't think django tempating is as bad as you've described but one reason is that a project is long-standing and dev resources are already familiar with it. A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well. The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
- scrollaway 6y ago
  Absolutes never exist :)
aiisahik 6y ago
Totally agree with your assessment of Django in terms of its templating and SSR abilities. It's horrible and should be avoided at all costs. However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
- scrollaway 6y ago
  Yes I agree with you. My favourite stack right now is Django with DRF+Admin for backend, Typescript+NextJS (React) for frontend. I front the backend with Caddy, have django live on both admin.example.com and api.example.com with a couple of rewrites, and put cloudflare access in front of admin.example.com. Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup). The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…

aiisahik 6y ago

I've spent many years working on django including production setups for 3 different companies. My strong advice is to only use Django for API calls (DRF) and the built in admin UI. Do not use Django for ANY client facing static site rendering. 1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy. 2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved. 3. Use https://github.com/ctrlplusb/react-async-component https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis. Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.

bredren 6y ago
That's a nice idea for new projects but how would you handle a company with large existing Django sites that want to bring in one or two react-based SPAs?
- deleted 6y ago
  [deleted]
- nickserv 6y ago
  We did this with Vue.js, not sure if it applies to React (I haven't used React). The way we did it was to start with a few parts of the page that really benefited from having Vue.js, using a simple `script src=`. So no components or anything fancy. For this we just put the JS stuff using Django's template system. Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN. In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON. In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
6y ago

silviogutierrez 6y ago

That's exactly what https://github.com/silviogutierrez/reactivated https://github.com/silviogutierrez/reactivated does. It's a work in progress and docs are coming. But it's the best of both worlds: Django SSR using statically typed JSX. See for example my blog or business sites (on profile). Both SSRed by Django using React templates. Then when the client loads, it gracefully "attaches" for dynamic interactive behavior as needed. By far the biggest pain point is having to run node and python on the server. So I'm working on the best way to do that.

shinryuu 6y ago

> Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. What we want from something like react after all is reactivity, and it's possible to get that if you were to use something like https://github.com/jonathan-s/django-sockpuppet https://github.com/jonathan-s/django-sockpuppet So if you've got an open mind and want to test it's there for the taking.

krzepah 6y ago

"I don't want to go full SPA with Django as this defeats the purpose of Django IMO" -> What is this "purpose" ? Django is here to help me model my database, handle few permissions and bring few API up online, I see no problem with having a PWA in front of it. Are you trying to get all of your website server rendered ? In which case you could do that without having to worry about integrating it with Django... TBH after 5 years of react and 8 of Django, i'm just not mixxing them up except for the front-end calling a query on the back-end (which both can be served at the same domain using nginx) ;

czue 6y ago

When you say "tell webpack where to put the files" what do you mean exactly? I recommend just making one bundle per "app" (can be configured as different entry points in your webpack config), and then using the outputs as standard Django static files. I found django-webpack-loader to be a little to magical for my taste and solving a problem that didn't really exist for me (the need for refreshless hot reloading). More details on this approach here: https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/integrating-javascript-pipeline/ https://www.saaspegasus.com/guides/modern-javascript-for-dja...