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>
)
TodoView is a dumb component that operates simple data passed via props, but now it needs to know that it's an observer and presumably rely on some facet of MobX to work? 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}
/>
))
But how often are you changing your app's data layer? Is the tradeoff _always_ worth it?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.
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.
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