Django and React/Redux Boilerplate Project

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).

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/

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.

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...

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.

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

?

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.

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/...

Anyone seen something similar for rails?