Project structure organization such as these always struck me as fitting a square peg into a round hole. Django and React/Redux (and other JS frameworks) have different way of organizing the project structure, and if you fit one inside the other (like here django project inside the redux project, or having a django app that holds the entire ui) makes things messy.
My preferred solutions for this is having a layer above, so the structure looks like:
* "backend" (contains typical django project structure, whatever you like)
* "ui" (contains typical frontned project structure, fire-away your webpack templates, it won't affect/care about the backend bits)
* "ansible" / "docker" / ... whatever devops or other stuff may be needed
* "README.md" explaining this and pointing the user to backend or frontend READMEs for more info.
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).
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.
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!
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.
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.
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.
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.
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
?
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.
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.
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).