Live data from Hacker News

Django React/Redux Base Project

github.com

51–60 of 79 posts

Re: Django React/Redux Base Project

#51
post #46

So for people who think they need Redux, first read "You Might Not Need Redux" [0] by Dan Abramov himself, creator of Redux. Then also I would recommend MobX [1] over Redux, it's easier to get started and in my opinion easier and better in general. [0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] https://github.com/mobxjs/mobx

I'm 3 months into my first React/Redux project and wouldn't adopt Redux again if I were starting over. Don't get me wrong, it's not horrible, but it's not great either. Compared with the extreme elegance and simplicity of React itself, Redux is verbose, boilerplatery and the way it integrates with React never feels natural. I've taken a look at Mobx and had that aha moment of "yes, this is what the solution should lo…

> the way it integrates with React never feels natural

Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.

Re: Django React/Redux Base Project

#53
post #37

Earlier quoted context omitted.

Doesn't avoid the node dependency, but try https://github.com/airbnb/hypernova Honestly the node dep isn't so bad. Just think of it as a template render running on another process.

On a $5/mo 512mb/20gb DO VPS, a single django application deployed with nginx, gunicorn, postgres and redis on the same box started to OOM me (nothing in application logs!) when doing something like generating a thumbnail. Deployed some swap and once thumbnail caches are warm we're fine, but, adding node as an additional dependency just seems overkill. python-react seems like a good fit.[0] [0] https://github.com/mar…

[deleted]

Re: Django React/Redux Base Project

#54

Django + React is an awesome combination that I recommend taking a look at. This repo is a good starting point but you can probably get rid of half of the dependencies if you aren't working on a team of developers. I am currently using Django + React on a personal project and took a slightly different route, no pun intended. Rather than using react router, as I never really liked client side routing, I use Django vie…

Hi I'm not much of a frontend guy as I concentrate on the backend, but my team is working on a new React UI and I'm thinking of something similar, possibly. Hopefully you can detail your plan a little more. The reason our old Angular front-end was complex was because it was firing off dozens of small rest calls to grab every bit of state - drop downs, business logic, props, etc. - every time the route changed. It was…

Yeah you are correct.

Re: Django React/Redux Base Project

#55
post #51
post #46

Earlier quoted context omitted.

I'm 3 months into my first React/Redux project and wouldn't adopt Redux again if I were starting over. Don't get me wrong, it's not horrible, but it's not great either. Compared with the extreme elegance and simplicity of React itself, Redux is verbose, boilerplatery and the way it integrates with React never feels natural. I've taken a look at Mobx and had that aha moment of "yes, this is what the solution should lo…

> the way it integrates with React never feels natural Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.

Not the parent, but when I was trying to learn R+R I kept getting confused by what they meant by 'state'. React state belongs to some component (whichever can mutate it) and is passed to children via props, and generally seems to include a mixture of view state and data/model state, with view-state originating somewhere in the component hierarchy while model state comes from the root. Redux's tutorial implied to me that it expected all mutable state to originate from the root, which clashed with what I had come to expect from React. Since I am fairly new to front-end JS, I just found myself confused at which way was really wiser.

Re: Django React/Redux Base Project

#56

Django and React do not share the same mantera. Django goes better with Ember. If you insist on using React/Redux, you are better off with something like Go for the backend.

How come you compare Django - a full-blown web development framework with Go - just a language? You should mention some Go frameworks which go well with React, I'm really curious to hear those.

Re: Django React/Redux Base Project

#58
post #51
post #46

Earlier quoted context omitted.

I'm 3 months into my first React/Redux project and wouldn't adopt Redux again if I were starting over. Don't get me wrong, it's not horrible, but it's not great either. Compared with the extreme elegance and simplicity of React itself, Redux is verbose, boilerplatery and the way it integrates with React never feels natural. I've taken a look at Mobx and had that aha moment of "yes, this is what the solution should lo…

> the way it integrates with React never feels natural Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.

> Redux reinforces that the majority of your app should effectively be (props) => JSX

Sure, Redux strongly recommends that practise - and it's a good one - but nothing about it is specific to redux. You can factor your components in the same way with mobx, or with plain React for that matter.

The point of redux and alternatives is to remove state management from inside the components to a dedicated store. Redux doesn't feel natural to me because it does it in a round-about way, introducing more concepts than necessary for the job at hand. Then the responsibility for managing the store is scattered around the reducers, the actions and for anything not completely trivial, some middleware magic for good measure. The glue code between Redux and the components is slightly awkward as well.

Mobx just goes: a store is just a class with properties and methods. Done. Glue code? Wrap the component with a one-line decorator. Done.

Re: Django React/Redux Base Project

#59
post #56

Django and React do not share the same mantera. Django goes better with Ember. If you insist on using React/Redux, you are better off with something like Go for the backend.

How come you compare Django - a full-blown web development framework with Go - just a language? You should mention some Go frameworks which go well with React, I'm really curious to hear those.

I don't. Go is mostly used without a framework and you've to collect your libraries. React is just a view library and you've to collect your libraries.

Django, on the other hand, is monolithic just like Ember.

I'd pick Django/Ember any day if it weren't for React Native platforms and the ability to share things between the web and mobile versions.

Re: Django React/Redux Base Project

#60
post #55
post #51

Earlier quoted context omitted.

> the way it integrates with React never feels natural Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.

Not the parent, but when I was trying to learn R+R I kept getting confused by what they meant by 'state'. React state belongs to some component (whichever can mutate it) and is passed to children via props, and generally seems to include a mixture of view state and data/model state, with view-state originating somewhere in the component hierarchy while model state comes from the root. Redux's tutorial implied to me t…

This comes up fairly frequently. The honest answer is that it's up to you and the requirements of your app where state gets stored. Unfortunately, state is everywhere: server/database state, local storage/cookie state, redux store state, react state, DOM state, etc. And that's if you have a fairly standard setup. Sometimes you want info from redux store state also stored in local storage and pulled on page reload, sometimes you want to get state from the server before continuing, sometimes an external library insists on DOM state, etc.

Generally, the problem redux is trying to solve is sharing state between components and saving client state globally. If there is information in a component for which you don't want to do either of those things, like UI details such as if a menu is or isn't collapsed, better to have that in the component react state.

Though this can be murky also. Showing the error modal I put in the redux store because I want it to supersede all other modals and to work globally.

This has been my experience anyway, as usual YMMV.

Post reply on HN