Django React/Redux Base Project(github.com) |
Django React/Redux Base Project(github.com) |
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...
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 look like!" Of course there's a big caveat here: not having really used it I don't know what its problems are yet. I'm comparing the real world warts of Redux with the platonic ideal of Mobx, but still it's definitely what I would try if I were starting a React project now.
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.
Disclaimer: Cx is a commercial framework and I'm the author.
Things like this (from the docs) make me nervous:
const TodoView = observer(({todo}) =>
<li>
<input
type="checkbox"
checked={todo.finished}
onClick={() => todo.finished = !todo.finished}
/>{todo.title}
</li>
)
const TodoView = ({title, isFinished, onClick}) => (
<li>
<input
type="checkbox"
checked={isFinished}
onClick={onClick}
/>{title}
</li>
)
const TodoViewContainer = observer({todo} => (
<TodoView
title={todo.title}
isFinished={todo.finished}
onClick={() => todo.finished = !todo.finished}
/>
))
Mobx allows you to be as pragmatic or dogmatic as you choose to be
Also MobX + TypeScript is just beyond awesome! You don't want to do MobX without TypeScript if you have the chance.
Mobx on the otherhand is "batteries included" and doesn't require much extra code to get started. We're using Mobx in production and only packages we needed to install were `mobx` and `mobx-react` along with some babel extensions. Very simple and increases developer efficiency by a mile not to mention onboarding time...
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 views to hydrate all the necessary props for the page and have a base template that loads the React component with the props. Since each page / component is fairly self-contained I also decided against using any Redux / Flux implementations. Furthermore, it only takes a few hours of work to get server side rendering up and running thanks to react + node.
The nice thing about react router and client side routing is you can have a very clean separation from your backend data model and your actual UI/website.
I would agree that react router is like a 1000 pound javascript routing gorilla.
Page load times are about .5 seconds for me, with lots of graphics. Also, I'm pretty sure it's faster than React.
Is this something people want to use that I should package up into its own product? It's a little bit of code but mostly methodology discipline.
I'm currently using .Net/Java/C++ (yeah...) and am wanting to get away from that and switch to Python full time. So, I have been looking at as much Python code as I can lately.
The JS code is still being changed around.
The key here to maintain state consistency between front-end and back-end is that I transfer state from client to server via "data-model" HTML attributes. These attributes also guides the router.
(would be interesting to compare the performance of this vs static site generator output on a really fast CDN - my hunch would be that this would probably win unless you were at a geographic disadvantage)
Note that I don't use the Django Templating system at all, and generate pages in Python instead.
I already went through a viral moment that caused our site to go down for a day after our last issue (we're a print magazine), and so the site is being designed to work around that.
So installation instructions become: 1. git clone 2. cd 3. make [init]
After thinking about it for a second this could be because I've been looking at universal/isomorphic projects but I'd imagine you should be able to do rendering in Node and still have a completely separate API project.
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.
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.
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.
> apt-get install -y build-essential libssl-dev libffi-dev libpq-dev python3-dev python-dev
I've been using Django for a long time, and I love it. And now, I've just started learning React/Redux. After some research I think that Django+React is the perfect combination.
This project is excatly what I needed to help me get started!
if you want to see it in action look here:
And me thinking it was a peaceful software project, without any soldering or soldiering...
I'm not a fan of React license
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 a large SPA.
I'm proposing to do something different - break up the SPA into 6 or 7 MVC pages and push as much of the state into the html / JS that is returned, then use React only to update dynamic pieces of the front-end without having to regenerate the whole page.
Is this what you're describing or am I mistaken?
Check out hasgluten.com for an example, code here (pretty old version of react though): https://github.com/hasgluten/hasgluten
Honestly the node dep isn't so bad. Just think of it as a template render running on another process.
Yes, because in my mind that's the litmus test that your app is properly data-agnostic. And a key thing about Redux is it stays that way -- it's actually difficult to leak your data store to child components. Even if I adopt the above approach with MobX it'd be incredibly easy for some other developer to start passing around stores everywhere.
My gut feeling is that MobX would be great for a personal project but doesn't scale that well.
You can listen for localStorage changes in all your tabs. When it changes, force a page reload or similar.
Edit: typos
The case I was interested in is where you'd like to have Django server-side-render the first request based on url, and then have react handle the rest via react-router and apis ala django-rest-framework.
As a backend dev who got by with jquery soup and 0 frontend build tools before (use django bundling tools), even starting to approach the React ecosystem is a little daunting.
I work in Java / Scala world, but have been pulled into more front-end / UI work the last few years. It seems a lot of (younger) developers use the backend only as a Restful bridge to the DB.
After seeing what is Node, Angular npm, bower, grunt, etc. and now React and friends, I'm pushing my team back to the server for all business logic and using the front-end only for dynamic forms, animations, etc.
The JS tooling is just not as good as static backend frameworks, nor are the libraries. Trying to debug dozens of async calls using Chrome Dev Tools takes 10x as long as doing it on the backend, even with multiple threads.
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/markfinger/python-react
edit: s/React-python/python-react/g
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.
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.
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.
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.