Django and React/Redux Boilerplate Project(github.com)
github.com
Django and React/Redux Boilerplate Project
https://github.com/seedstars/django-react-redux-base
23 comments
Not saying it's the best/only approach but it made sense at the time. For example, Sentry does the same: https://github.com/getsentry/sentry/
Technically in Django you should put all the "static" into a static folder.
Technically in Django you should put all the "static" into a static folder.
Indeed, but what Django considers static assets are, with many modern frameworks, build results, not source itself. If you put all the UI bits inside static, you'll either service your JS source files, build config, node_modules and the like, or you'll need to muck around hiding those.
If instead you have a separate project diferctory for the UI bits and then just configure it to use the Django's static folder as the output dir (or alternatively, configure Django to to add the UI build folder in STATICFILES_DIRS), you avoid this pain.
If instead you have a separate project diferctory for the UI bits and then just configure it to use the Django's static folder as the output dir (or alternatively, configure Django to to add the UI build folder in STATICFILES_DIRS), you avoid this pain.
Honestly you should not use a React boilerplate of any kind as of today. We got pretty decent alternatives today in order to avoid using that kind of stuff:
- You're just getting started with React? Use CRA[1], it is enough for most of the use cases people will ever need use React with. You may also want to consider Next.js[2] if you are looking to do a more website-like app using React components but that's all...
- You know how to setup js tooling (webpack, babel, react-router, redux, ...)? You may still want to use CRA because it is way easier to use anyway. But this time you know you can either eject to more fine-grained tooling tuning or do your thing independently if you want.
If you use a boilerplate at that point, that's because you understand the tooling behind it and CRA won't answer to the precise need covered in this boilerplate. Also you should be able to maintain it and make it evolve later (the more dependencies, the harder it will be...). So in that case, if you master all of those tools (can't say I do) and integrate them often with django, then maybe, this boilerplate could be for you...
In conclusion, this covers a very special need and I don't understand how this got on top of HN... It actually makes the React community look kind of bad (assuming some people upvote when they see React stuff, which I don't think is the case) because this does not seem to solve any of the problems people outside of the community are complaining about. So, if you are looking for an easy way to use React (that won't prevent you from plugging it to your django backend btw), just use CRA!
[1]: https://github.com/facebookincubator/create-react-app [2]: https://github.com/zeit/next.js/
- You're just getting started with React? Use CRA[1], it is enough for most of the use cases people will ever need use React with. You may also want to consider Next.js[2] if you are looking to do a more website-like app using React components but that's all...
- You know how to setup js tooling (webpack, babel, react-router, redux, ...)? You may still want to use CRA because it is way easier to use anyway. But this time you know you can either eject to more fine-grained tooling tuning or do your thing independently if you want.
If you use a boilerplate at that point, that's because you understand the tooling behind it and CRA won't answer to the precise need covered in this boilerplate. Also you should be able to maintain it and make it evolve later (the more dependencies, the harder it will be...). So in that case, if you master all of those tools (can't say I do) and integrate them often with django, then maybe, this boilerplate could be for you...
In conclusion, this covers a very special need and I don't understand how this got on top of HN... It actually makes the React community look kind of bad (assuming some people upvote when they see React stuff, which I don't think is the case) because this does not seem to solve any of the problems people outside of the community are complaining about. So, if you are looking for an easy way to use React (that won't prevent you from plugging it to your django backend btw), just use CRA!
[1]: https://github.com/facebookincubator/create-react-app [2]: https://github.com/zeit/next.js/
Any danger of a paragraph or two explaining what makes this worthy of being on the top of HN? Or are we all just upvoting dime a dozen React boilerplates now because we just love React so much?
For the sake of some discussion, I think these boilerplates are a footgun for most developers. If you're a new React developer, your goal should be to learn how each dependency in a project fits together, and you should be starting your first few projects with literally zero depencies and growing them organically as you need (not want) new tooling.
If you're an experienced dev, you've already got your own boilerplate set up just how you like it.
So the only two use cases I can see for these boilerplates are: Rookie developers should use them as examples for how to implement a specific dependency in an existing project, and experienced developers should only really use them as a source of quick ideas for tooling they may have missed that would be useful to their existing projects.
Actually basing a project off somebody else's boilerplate is a huge mistake, in my experience.
For the sake of some discussion, I think these boilerplates are a footgun for most developers. If you're a new React developer, your goal should be to learn how each dependency in a project fits together, and you should be starting your first few projects with literally zero depencies and growing them organically as you need (not want) new tooling.
If you're an experienced dev, you've already got your own boilerplate set up just how you like it.
So the only two use cases I can see for these boilerplates are: Rookie developers should use them as examples for how to implement a specific dependency in an existing project, and experienced developers should only really use them as a source of quick ideas for tooling they may have missed that would be useful to their existing projects.
Actually basing a project off somebody else's boilerplate is a huge mistake, in my experience.
http://www.seedstarsacademy.com/
Seems like some kind of coding school. I bet they told their students to upvote this post en mass.
Seems like some kind of coding school. I bet they told their students to upvote this post en mass.
Actually these are quite nice as we're experienced developers that use these technology but need more opinions on how projects should be structured. I fully agree with not using it as a base, but also encourage review of these to see what you could do better :)
EDIT: I see my comment is redundant as you got the same idea.
EDIT: I see my comment is redundant as you got the same idea.
depends on the maturity of that boilerplate. there's no reason not to use industry proven CRA
Reminds me of another bloated boilerplate [1].
Please don't use those for real projects. It's really big pain to maintain and also the day after you start using it, it will be already deprecated.
Best approach, that won't make anyone else reading your code unhappy, would be to spend some time and create the base of your project yourself. It will result in a much smaller amount of dead code and you will learn a lot.
1: https://github.com/chentsulin/electron-react-boilerplate/blo...
Please don't use those for real projects. It's really big pain to maintain and also the day after you start using it, it will be already deprecated.
Best approach, that won't make anyone else reading your code unhappy, would be to spend some time and create the base of your project yourself. It will result in a much smaller amount of dead code and you will learn a lot.
1: https://github.com/chentsulin/electron-react-boilerplate/blo...
This boilerplate project is without doubt going to save people a lot of time, and is a great contribution to the community.
That said, boilerplate projects to get started with a technology or a group of technologies are a red flag that they are overly complex and not built sufficiently modularly (or at the very least people are going about learning them wrong/they're being cargo-culted). I think that boilerplate projects encourage non-essential complexity.
I do realize that software becomes complex because of the things it must do -- many of the tools listed in the boilerplate project are there precisely because they add robustness (this could also be called "essential complexity") that is necessary for a robust end product -- and they often solve problems that should not be solved more than once. I am, however, a firm believer that developers should come to find these tools themselves, after confronting and getting to know the problem intimately.
Just wanted to leave that thought here -- if you're seeing this and thinking "awesome, now I can get started on my first web app", please don't. You'll probably build more sturdy knowledge from getting started with Flask + jquery, and then graduating once you've tacked too many things onto flask, or written too much spaghetti with jquery and want more structure.
That said, boilerplate projects to get started with a technology or a group of technologies are a red flag that they are overly complex and not built sufficiently modularly (or at the very least people are going about learning them wrong/they're being cargo-culted). I think that boilerplate projects encourage non-essential complexity.
I do realize that software becomes complex because of the things it must do -- many of the tools listed in the boilerplate project are there precisely because they add robustness (this could also be called "essential complexity") that is necessary for a robust end product -- and they often solve problems that should not be solved more than once. I am, however, a firm believer that developers should come to find these tools themselves, after confronting and getting to know the problem intimately.
Just wanted to leave that thought here -- if you're seeing this and thinking "awesome, now I can get started on my first web app", please don't. You'll probably build more sturdy knowledge from getting started with Flask + jquery, and then graduating once you've tacked too many things onto flask, or written too much spaghetti with jquery and want more structure.
Seriously - do you really need all this stuff:
React
React Router Declarative routing for React
Babel for ES6 and ES7 magic
Webpack for bundling
Webpack Dev Middleware
Clean Webpack Plugin
Redux Predictable state container for JavaScript apps
Redux Dev Tools DevTools for Redux with hot reloading, action replay, and customizable UI. Watch Dan Abramov's talk
Redux Thunk Thunk middleware for Redux - used in async actions
React Router Redux Ruthlessly simple bindings to keep react-router and redux in sync
fetch A window.fetch JavaScript polyfill
tcomb form Forms library for react
style-loader, sass-loader and less-loader to allow import of stylesheets in plain css, sass and less,
font-awesome-webpack to customize FontAwesome
bootstrap-loader to customize Bootstrap
ESLint, Airbnb Javascript/React Styleguide, Airbnb CSS / Sass Styleguide to maintain a consistent code style and eslint-plugin-import to make sure all imports are correct
mocha to allow writing unit tests for the project
Enzyme JavaScript Testing utilities for React
redux-mock-store a mock store for your testing your redux async action creators and middleware
expect Write better assertions
Nock HTTP mocking and expectations library
istanbul to generate coverage when running mocha
?You really really don't. The fact that this kind of stuff gets so many votes is somewhat alarming, to say the least.
Creating a static website is some pretty hardcore stuff. Of course we need all of those, how else could we do it? /s
If you want to use React and build a SPA I'm afraid that's pretty minimal - by the end of writing your JS app you'll probably end up with another <EDITED: arbitrary large number> dependancies.
Actually looking at the package.json here:
https://github.com/Seedstars/django-react-redux-base/blob/ma...
Things are actually much worse than even the above - taking into account with all the dependancies resolved it's 930 packages :-/
Actually looking at the package.json here:
https://github.com/Seedstars/django-react-redux-base/blob/ma...
Things are actually much worse than even the above - taking into account with all the dependancies resolved it's 930 packages :-/
ReactDev: ... [fidgets] ... it's, uh ... [clears his throat] ... well, yeah... [fidgets some more] ...
For the most part, yes.
Welcome to the wonderfull world of react.
Most of these are dev libraries
I am afraid they are not:
"dependencies": {
"autoprefixer": "7.1.2",
"babel-core": "6.26.0",
"babel-loader": "7.1.2",
"babel-plugin-react-display-name": "2.0.0",
"babel-plugin-react-transform": "2.0.2",
"babel-plugin-transform-decorators-legacy": "1.3.4",
"babel-plugin-undeclared-variables-check": "6.22.0",
"babel-polyfill": "6.26.0",
"babel-preset-es2015": "6.24.1",
"babel-preset-es2015-loose": "8.0.0",
"babel-preset-react": "6.24.1",
"babel-preset-stage-1": "6.24.1",
"babel-runtime": "6.26.0",
"body-parser": "1.17.2",
"bootstrap-loader": "2.2.0",
"bootstrap-sass": "3.3.7",
"classnames": "2.2.5",
"clean-webpack-plugin": "0.1.16",
"css-loader": "0.28.5",
"errorhandler": "1.5.0",
"es6-promise": "4.1.1",
"exports-loader": "0.6.4",
"extract-text-webpack-plugin": "3.0.0",
"file-loader": "0.11.2",
"font-awesome": "4.7.0",
"font-awesome-webpack": "0.0.5-beta.2",
"history": "4.7.2",
"html-webpack-plugin": "2.30.1",
"imports-loader": "0.7.1",
"isomorphic-fetch": "2.2.1",
"jquery": "3.2.1",
"less": "2.7.2",
"less-loader": "4.0.5",
"node-sass": "4.5.3",
"postcss-import": "10.0.0",
"postcss-loader": "2.0.6",
"prop-types": "15.5.10",
"react": "15.6.1",
"react-dom": "15.6.1",
"react-mixin": "3.1.0",
"react-redux": "5.0.6",
"react-router": "4.2.0",
"react-router-dom": "4.2.2",
"react-router-redux": "5.0.0-alpha.6",
"redux": "3.7.2",
"redux-thunk": "2.2.0",
"resolve-url-loader": "2.1.0",
"sass-loader": "6.0.6",
"style-loader": "0.18.2",
"tcomb-form": "0.9.17",
"url-loader": "0.5.9",
"webpack": "3.5.5",
"webpack-merge": "4.1.0",
"whatwg-fetch": "2.0.3",
"yargs": "8.0.2"
},
I work on a large Django project that has migrated to Webpack + React + Redux for parts of the frontend (eventually all of the frontend).
There are many good things about this project, but the thing that struck me is that after reading through parts of it, I don't feel like I have any better understanding of getting Django and JS talking to each other well. I don't feel like this project makes any breakthroughs.
Things I'd like to see:
1. A nice way of integrating webpack-dev-server and Django's run server - it would be nice to run just one of them, but I think this still requires both.
2. A way to integrate Django's URL routing system with the frontend. In Django-land I can refer to a URL by name so that the actual URL can change - but this JS just has hard-coded URLs everywhere. It would be great to see a better alternative.
3. An advancement on the standard Django handling of static files. They way they've done it is the way I structured our project, but I always felt it was a bit hacky. I'd really like to see a nicer way.
There are many good things about this project, but the thing that struck me is that after reading through parts of it, I don't feel like I have any better understanding of getting Django and JS talking to each other well. I don't feel like this project makes any breakthroughs.
Things I'd like to see:
1. A nice way of integrating webpack-dev-server and Django's run server - it would be nice to run just one of them, but I think this still requires both.
2. A way to integrate Django's URL routing system with the frontend. In Django-land I can refer to a URL by name so that the actual URL can change - but this JS just has hard-coded URLs everywhere. It would be great to see a better alternative.
3. An advancement on the standard Django handling of static files. They way they've done it is the way I structured our project, but I always felt it was a bit hacky. I'd really like to see a nicer way.
Unfortunately, no server-side rendering here (I was looking for an example of such with Django/DRF+Node)
https://github.com/Seedstars/django-react-redux-base/issues/...
https://github.com/Seedstars/django-react-redux-base/issues/...
[deleted]
Anyone seen something similar for rails?
My preferred solutions for this is having a layer above, so the structure looks like:
This is cleaner (different parts nicely separated), instantly recognizable to anyone working on one part but totally unfamiliar with the other, and allows you to use whichever scaffolding techniquies you want (eg cookiecutter on the backend, cli tools for react/vue/angular/whatever).