
Django and React/Redux Boilerplate Project - fgarci03
https://github.com/seedstars/django-react-redux-base
======
senko
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).

~~~
lfrodrigues
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/](https://github.com/getsentry/sentry/)

Technically in Django you should put all the "static" into a static folder.

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

------
robinricard
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](https://github.com/facebookincubator/create-react-app) [2]:
[https://github.com/zeit/next.js/](https://github.com/zeit/next.js/)

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

~~~
hasenj
[http://www.seedstarsacademy.com/](http://www.seedstarsacademy.com/)

Seems like some kind of coding school. I bet they told their students to
upvote this post en mass.

------
drinchev
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...](https://github.com/chentsulin/electron-react-
boilerplate/blob/master/package.json)

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

------
chvid
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
    
    ?

~~~
zeta_
Most of these are dev libraries

~~~
chvid
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"
        },
    

(from package.json).

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

------
drdaeman
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/7)

------
gt2
Anyone seen something similar for rails?

