Pretty annoyed by the dramatic changes in different version of React Router. Have already updated my app like three times due to breaking API changes…
Still struggling to get Flux to work with ReactRouter. The only thing I found useful is this article.
Maybe the question is: do we need a router and a Flux store? It seems like we only need one of them.
Facebook’s official implementation:
After writing our in-house rich text editor (I know, it was a bad idea), I kept wondering whether there is a better way.
React.js opens some interesting possibilities, because now rending to DOM is so cheap. Additionally, the medium engineering team’s blog re-assured the difficulty of writing a contenteditable editor and shared similar visions with Polymer web components.
At a very high level, I think the approach could be similar to what Medium is doing right now:
- Apply a sequence of atomic operations on an in-memory text string to generate innerHTML, give the innerHTML to the virtual DOM, and let Reactjs update the actual DOM.
- Atomic operations could be bold / underline / h2 / h3 etc. They takes a text string and outputs HTML.
- In-memory text string is the raw text, typed by the author
- We also need a controller to coordinate atomic operations, meaning not only know how to apply one operation at a particular start-end position of the text string, but also knowing how to prioritize different operations.
This also reminds me of the fancy command logging, the idea of always starting with a base state, and generate current state by applying many many atomic operations.
Anyway, would love to write a rich text editor that doesn’t suck and generate consistent HTML markups in React.js, but it is a pretty big undertake… Maybe someday…
You can probably skip the first 7 minutes or so. Jing’s presentation starting at 10minutes on Flux is amazing!
React is the next big thing…
No I am just kidding…
It is a great idea and is way smaller than Angular. However, after sometime, I feel like it was designed to present data, not editing data. It is extremely painful to change a deeply nested component, and ask the root component to respond to it.
Here are some interesting ideas on how to solve the problem.
One is with event bus. Coming from Backbone, I almost don’t know what to do when I don’t have any event bus…
“This is exactly the problem we’ve been running into building a medium sized interactive app in React. The management of data flow and state changes through the component hierarchy with callbacks can get quite complex, and you end up writing lots of callback boilerplate. So we’ve ended up rolling an event system that sits alongside the React components, and a lot of our app’s interactivity is managed through the event system.” quoted from this url: https://news.ycombinator.com/item?id=7671848
The other is with callbacks from the child component to its parent. This might be the recommended way from the React team, but I don’t like it because you quickly accumulate so many boilerplate code …
“I think this is the most underdocumented part of React right now. The suggested way to communicate between components is to simply set props when communicating from parent to child and to pass callbacks through props when communicating from child to parent.” quoted from this url: http://stackoverflow.com/questions/20795323/editing-a-rich-data-structure-in-react-js
The third one is this thing called the flux system architecture , which I don’t quite understand. It seems to be the same as the event bus system, but I am not 100% sure.
“It works well with React because the objects are passed directly into React views for consumption, where they cannot be modified by the views themselves. When a view wants to change a piece of data, (perhaps based on user input), the view informs the store that something has changed, which will validate the input and then propagate the change out to the rest of the application. In this way, you never worry about incremental state mutation, or incremental updates, and every change that happens to the system (whether it comes from user input, an ajax response from the server, or anything else) goes through the exact same flow (which handles validation, batching, persisting, etc).
An example with flux can be found here: https://github.com/facebook/react/tree/master/examples/todomvc-flux