This article kind of comes at a perfect time for me. I just recently started working on a project with a code editor and I've been battling for a while how to communicate changes through react.
I plan to use ace, and require the ability to get and apply patches as the user types into the ace editor, get code when they need to compile, as well as be able to modify other properties of the editor.
At the most complex level, I need to keep two ace editors in-sync, doing this with cure javascript and ace is simple, as you just need to apply a patch from one editor to the other.
Building large and complex applications has always been the big problem for me with React, and the author states it right up front
we ran into issues finding examples of how React could
apply to an application as complex as ours, given that
most tutorials focus on the specifics of toy-sized demo
apps as opposed to more general discussions of the
problems specific to larger applications.
This is just something that is going to take time though.
This is why they gave the presentation on Flux, which is architecturally how Facebook solves this problem.
Basically the first principal you must learn is to find the lowest common ancestor to store state. (http://facebook.github.io/react/blog/2013/11/05/thinking-in-...) After realizing this the immediate thing people do is pass call backs through children so grandchildren's actions can communicate with where the state is. This leaks through all the components however, which is why Flux separates actions out into something that all the components have access to.
I've included minimal starter template for React.js and React.js (with addons) as well as transparent jsx transformation. I'm open to more complete starter examples if anyone better at React.js wants to contribute them!
As a matter of fact, I created a really simple react yeoman generator[0]. All other generators are pretty bloated with lots of stuff. Maybe that's ok for new applications, but I was just trying to learn react and they all were heavily bloated.
Just started looking into React yesterday. What I've read thus far doesn't discuss your server-side at all. Is it agnostic to what's running on your server ... any JSON-based RESTful back-end will do, or are there benefits to using a specific stack for your back-end?
React is indeed agnostic to your server-side stack. Only thing is you'll need a node.js server if you want server-side rendering. (Codecademy runs ours separately from the rails app so we can do server side rendering.)
I plan to use ace, and require the ability to get and apply patches as the user types into the ace editor, get code when they need to compile, as well as be able to modify other properties of the editor.
At the most complex level, I need to keep two ace editors in-sync, doing this with cure javascript and ace is simple, as you just need to apply a patch from one editor to the other.
Building large and complex applications has always been the big problem for me with React, and the author states it right up front
This is just something that is going to take time though.