61–70 of 79 posts
Earlier quoted context omitted.
If you wrap the class in createFactory() then you break instanceof; how is this fine?
True. But I can't come up with an example where I'd use instanceof on react components, can you give me one?
How are bindings in React not two-way? Update an input field and it updates the underlying JS object. Update the object and it updates the input field. I thought that was the definition of two-way, regardless of what happens behind the scenes.
If you use an uncontrolled component (by giving it a defaultValue/defaultChecked prop) you have to pick up the new value using an event or directly via the DOM. If you do it this way, you can't update the displayed value by changing the props passed to it.
If you use a controlled component (by giving it a value/checked prop), its displayed value won't update unless you pick up the new value from an event and set it in whichever JS object you have holding its state for the next render. There's a helper for doing that, or it's easy enough to roll your own event handler which takes care of all your fields.
I ask this because the increasing move towards microservices seems to suggest that "joins" are going to start taking place on the client via waitFor.
For example, if I get model A and it depends on Models B, C and D. I don't want to have to wait for the client to fetch model A before it knows it needs to fetch models, B, C and D. Ideally, as model A passes through the server side store layer, it already starts fetching models B, C and D so it has those ready to serve to client, (or better yet it anticipates that the client is going to want B, C and D and eagerly sends that data to the client).
I'm disappointed that JSX is now so coupled to React. I was looking forward to JSX being used by many different JavaScript frameworks[1], but this change reveals the devs are not interested in moving that direction. [1] Example: https://github.com/mrsweaters/mithril-rails
I'm not sure if it's yet been updated to support createFactory, but even if it doesn't you could create a simple higher order function the partially applies the static unchanging DOM parts, returning a function that takes the same data type as the function returned by createFactory.
IMHO, with createFactory, there is no longer a good justification for JSX. JSX basically solves a problem that JSX created. The reason people like JSX is that it takes the unchanging DOM structure (basically the virtual DOM equivalent of HTML templating) and puts it in HTML like templates do. This gives it a sufficiently different syntax, that it's easy to visually discern the changing parts from the unchanging parts, especially with syntax highlighting support. However, with createFactory, you have a way to wrap up all the unchanging structure, such that you don't have to constantly have to mentally parse the unchanging structure from the virtual DOM that render() is actually going to update. This means you still have to deal with React.DOM, but if you use react-hyperscript, the syntax is sufficiently simplified that it's comparable to HTML.
The complexity of JSX simply isn't worth it. It breaks too many tools.
Earlier quoted context omitted.
We do actually want JSX to be flexible and usable for not just React, which is why we're trying to write a formal specification of the syntax with multiple parser implementations: http://facebook.github.io/jsx/ We intentionally don't specify semantics to give different transpilers the flexibility to compile the JSX into whatever's appropriate for the library you're using.
A specification is great, and I'm happy to see that. However, even though it's true that transpilers can compile JSX with arbitrary semantics, it still requires writing your own transpiler . JSX is a great syntax, and these changes mean nothing if you're a transpiler writer. What I was hoping for was the JSX transpiler that React uses would become flexible enough for any library to use, without the need to modify/rew…
JSX is a great syntax
I have a huge problem with this change explained here: https://gist.github.com/deadlyicon/da8c020662ea8e6002dc
Earlier quoted context omitted.
As the others have stated, react requires me to add this line: var MyComponent = React.createFactory(require('MyComponent')); It's not a huge deal, but I keep getting this sense that jsx is strongly tied to react and this reaffirms that they are going to keep it that way. I do trust the react team still, but it makes me weary of future releases.
(I'll re-link to sebmarkbage's answer here in case people see this post and get confused: https://news.ycombinator.com/item?id=8523876 ) In short, this is somewhat of a transition step for the (imo) even better way of specifying your render with pure vanilla js collections. This goes in the opposite direction of what you're worried about. You can view `createElement/Factory` as the stepping stone, with the _additiona…
As long as we can always do something like
div className: 'foo',
span className: 'bar'
Custom className: 'baz'
What options are there for syncing flux stores on the server and client? I ask this because the increasing move towards microservices seems to suggest that "joins" are going to start taking place on the client via waitFor. For example, if I get model A and it depends on Models B, C and D. I don't want to have to wait for the client to fetch model A before it knows it needs to fetch models, B, C and D. Ideally, as mod…