Live data from Hacker News

Django React/Redux Base Project

github.com

71–79 of 79 posts

Re: Django React/Redux Base Project

#71
post #34

Earlier quoted context omitted.

Token based auth is stateless, so your first assumption stands true -- no need to join them at the hip. I've tried working with tools like Djangular and whatnot, and no matter how many times I've tried working within that ecosystem, I've always had better results, cleaner and simpler code by keeping the UI and Backend completely separate.

Token based auth doesn't need to be stateless. In fact in our current implementation it is not. If you use stateless like JWT (we had this before) you end up having a huge problem: imagine a user wants to logout all the open accounts in different browsers. How would you handle that? You would need to wait for the expiration of the token, a solution that is not that secure.

One solution is to store the token in localStorage, which supports events.

You can listen for localStorage changes in all your tabs. When it changes, force a page reload or similar.

Edit: typos

Re: Django React/Redux Base Project

#72
post #55

Earlier quoted context omitted.

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…

React allows you to keep state in components, but that doesn't mean that you should. When you're using React + Redux, keeping ANY state in components is an antipattern. Keeping all state in the "root" (the redux store) allows you to observe the your app's complete state in one place, all previous states, and the exact sequence of events that triggered all past state transitions. This discipline enables features like…

Two responses to my comment, opposite recommendations. I'm inclined to agree with you in general, but the contradicting opinions can't be good for newcomers.

Re: Django React/Redux Base Project

#74
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…

So if Redux sux now...how bad was Reflux and Flux?

Re: Django React/Redux Base Project

#75
post #71

Earlier quoted context omitted.

Token based auth doesn't need to be stateless. In fact in our current implementation it is not. If you use stateless like JWT (we had this before) you end up having a huge problem: imagine a user wants to logout all the open accounts in different browsers. How would you handle that? You would need to wait for the expiration of the token, a solution that is not that secure.

One solution is to store the token in localStorage, which supports events. You can listen for localStorage changes in all your tabs. When it changes, force a page reload or similar. Edit: typos

I think you didn't understand the issue. Imagine you want to implement a "logout from all my sessions" like Facebook or Google have (sessions in different devices)

Re: Django React/Redux Base Project

#76

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

It's been less than 6 months I first heard about Redux. Looking at its issues, it seems to be a little more than 1 year old. Now everyone is talking about MobX. Why not improving Redux in first place? If it's verbose, why not writing more abstractions on top of it to make it easier to use? IMHO we should think more about those questions before writing another framework-of-the-day.

The strategy of MobX is different. It's not easily possible to make Redux work like how MobX does it.

Re: Django React/Redux Base Project

#77
post #72

Earlier quoted context omitted.

React allows you to keep state in components, but that doesn't mean that you should. When you're using React + Redux, keeping ANY state in components is an antipattern. Keeping all state in the "root" (the redux store) allows you to observe the your app's complete state in one place, all previous states, and the exact sequence of events that triggered all past state transitions. This discipline enables features like…

Two responses to my comment, opposite recommendations. I'm inclined to agree with you in general, but the contradicting opinions can't be good for newcomers.

A number of people in the community seem to have latched on to this "you MUST put EVERYTHING into Redux" idea, but it's definitely _not_ anything that's pushed by the Redux team. trex654 is correct here - it's entirely up to you to decide what state should live where.

The Redux FAQ addresses this at http://redux.js.org/docs/faq/OrganizingState.html#organizing... . Note that a number of the linked comments regarding whether or not to use Redux come straight from Dan Abramov himself.

Also, I have a number of articles on React state management practices as part of my React/Redux links list, at https://github.com/markerikson/react-redux-links/blob/master... , which may help clarify some of the ideas as well.

Re: Django React/Redux Base Project

#78

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

It's been less than 6 months I first heard about Redux. Looking at its issues, it seems to be a little more than 1 year old. Now everyone is talking about MobX. Why not improving Redux in first place? If it's verbose, why not writing more abstractions on top of it to make it easier to use? IMHO we should think more about those questions before writing another framework-of-the-day.

There's definitely a lot of abstractions being written on top of Redux. Some of them stay with Redux's conventions, others try to take it in a very different philosophical direction. My Redux addons catalog lists just about everything out there: https://github.com/markerikson/redux-ecosystem-links .

Re: Django React/Redux Base Project

#79
post #55

Earlier quoted context omitted.

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…

React allows you to keep state in components, but that doesn't mean that you should. When you're using React + Redux, keeping ANY state in components is an antipattern. Keeping all state in the "root" (the redux store) allows you to observe the your app's complete state in one place, all previous states, and the exact sequence of events that triggered all past state transitions. This discipline enables features like…

Trouble with this is, if you have a lot of drop-down menus that is a tremendous amount of additional code, actions have to be added, or added with abstractions, this new thing has to be managed in the global store etc. the end result being that your app is just slower because all this info has to pass through the dispatcher :/. Also can't see how rewinding simple isolated UI effects could help in debugging.

I've noticed that when programmers are introduced to a new technique there is a tendency to apply it everywhere. I had this experience when first learning recursion, it was all I used for a while, until I realized that was silly and now only use it where appropriate. This is true for OOP, functional programming, strictly adhering to even esoteric details of REST, etc.

I've found programming to be a lot like cooking. I really liked garlic, so when I first started cooking I would routinely add a couple extra cloves, until I discovered there very much was the possibility of too much garlic. This is true for each ingredient, you try stuff out and as your experience as a chef grows, you start to be able to suss out the right amount of each ingredient added at the right time.

Programmers are essentially virtual craftsmen, you have a set of tools and you try to build something effective with the tools you have. If you adhere to a principle so fiercely, the pieces of the puzzle often don't quite fit. You end up with a circle or square where something more acorn shaped would be most appropriate.

Anyhoo, don't take my word for it: "A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson or "Only a Sith deals in absolutes" - Obi-wan.

Post reply on HN