I love React, but so far I've been a bit underwhelmed by the ecosystem of components that has sprung up. I hope that this site will help.
A lot of the components are stuff that aren't really UI elements, but rather add magic to other UI elements or even do something completely unrelated to the UI.
I mean, I've seen routers written as React components![1] Wtf? Why is it an advantage to express a route as XML-like JSX? Why put it in a virtual DOM? That's just waiting for unexpected side-effects to happen. I can imagine that a lean, to-the-point router is a good combination with React but components are for UI widgets, not for configuration.
I feel like this is the same mistake as the everything-in-XML hype of the early 21st century (Spring, anyone?), or the everything-as-a-DSL hype in early Scala (with clear, descriptive operators such as ~~=, $%% and of course &^), or the current hype in C#-o-world to package web assets into NuGet packages (jquery.dll - seriously?). Just because you can put it in a component, doesn't mean that you should.
Behavioral features for components (e.g. infinite-scrolling or tooltip triggers) are well distributed as a mixin. Stuff not directly related to UI widgets should just be vanilla JavaScript. Asset libraries should be asset libraries.
What I expect from open source components is UI elements. Color pickers, fancy dropdown selects, login widgets, form elements with pluggable validation maybe (but the validation logic shouldn't be components). Notably, I'd love an ecosystem of UI frameworks ala Bootstrap or Foundation to spring up around React, and it appears that this is happening.
(Sidenote, if there's one development we do need, then it's a clear React-authors-condoned way to couple (parameterized) CSS with React components, so that we can really distribute self-contained components including style. A development like that would also help focus the React component ecosystem on what it should be about: UI widgets.)
It doesn't generate any markup itself, but instead renders the component bound to the route. This is a perfectly valid way to communicate how routes are related to components.
I'm assuming the React core team liked the approach as well, considering they featured it in one of their community round-up blog posts:
We can agree to disagree right? I think using JSX and React components for configuration is a bad match, and plain JS is a much better and more flexible fit. I also suspect that it is a result of eagerness to use the newly-learned hammer for every nail out there, which is a rather common phenomenon when new technologies quickly rise in popularity.
You, on the other hand, think it's neat. That's fine.
I don't see how the router's source code is related to this discussion, though. I implied nowhere that that particular router did something bad with rendering markup or something, I'm not sure where you got that from. I'm talking about the API.
Just want to say I fully agree with you. react-router seems like a useful library, but I see utterly no reason why you should write your routes in JSX instead of as a simple JS object. Using JSX for anything other than DOM insertion or modification creates an impedance mismatch. The public API makes no real sense to me.
The point of JSX is to more easily build dynamic HTML (and perhaps other markup).
Your idea of "mocking" strikes me as rather sensitive. I criticized it. I feel like you're telling me that we're not allowed to criticize technical developments on HN and that bothers me.
It might just be a cultural divide though. I keep underestimating at how much flower dressing and icing on the cake Americans need in order to be able to deal with criticism. Conversely, you (I'm blatantly assuming you're American) probably think I'm unnecessarily rude.
It's not a case of "new hammer", it's being used there for the exact reason JSX was invented - "defining tree structures with attributes" in a standard way since "A generic but well defined syntax enables a community of independent parsers and syntax highlighters to conform to a single specification."
> The rationale for using JSX over plain JS is given here
Are you pulling my leg or did you simply not read any of the two comments I wrote?
My first comment even contained last decade's hype to do "everything in XML" as an example of a similar (bad) movement. Your response is to link to an article that describes JSX as an "XML-like syntax extension to JavaScript".
I say "don't do everything in JSX just because you can", and your response is "but it's like XML!". I can only deduct that you also like programming in XML. Good for you, I recommend you begin with porting XSLT to JSX.
No. You didn't say those words that you quoted. You're ranting and raving like a lunatic, so maybe you should just take a minute to think about that.
XML is not being used "because they can". First of all - they couldn't use XML inline, which is the reason they invented JSX. Then they could. So, they actually went out of their way to use XML.
I didn't link to the article so that you could get a description of JSX, you rude jerk. I linked so you could get the reasoning. Unfortunately, you're being a complete asshole so just like, never-mind I guess. Have a nice day! :)
(Oh and - You haven't given one valid reason why you think it's a bad idea. Just rubbish appeals to authority. Your rant contains no logic. What's your reasoning? You asked "Why is it an advantage to express a route as XML-like JSX?" and the answer is in the rationale given on the JSX spec page. There are 1,000 ways to put together a JS object. There is one way to put together XML. It's a better, simpler standard that lends itself to better tooling and simpler parsers that don't need to parse the entire JS language.)
Your response is way ruder then the OP's, way to escalate the situation ...
I don't see how it's hard to understand how using a syntax that was designed for rendering UI components for routing might be a bad idea. It's just screams ugly hack all over the place and I could easily see how it would be confusing and overly verbose.
I'm completely favor of non-UI components but that's not how a client-side router should work. What I mean is tying a particular route to a particular UI component is the wrong way to go. Instead the route should be tied to the application state itself, and application state should be what drives UI.
Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).
As someone who is using react-router, there are some good reasons for it: it provides a nice way for the current state of the router (eg. the active route and the state that represents) to fit into React's re-rendering on updates. Existing off-the-shelf routers don't tend to cover this case (re-rendering from state without re-executing the route), so I wrote a layer on top of Backbone.Router to integrate the two, but react-router means one less thing to maintain, and it also has handy transition hooks (modelled on Ember.Router).
As for the use of JSX specifically, it's handy because it allows expressing ordered associative data, for which in javascript the other choices are both kind of messy: either an array of objects (verbose) or an object (not guaranteed to be ordered).
This is true as per the ECMAScript spec, but realistically you can count on it (unless your keys are stringified numbers). On the server side of things, this is explicitly depended on in a number of places - the most visible that I know of is Mongo's REPL and its node.js drivers (specifying complex sorting/indexing depends on the objects being ordered).
I'm not really a front-end person, but when I first saw React it was the first thing I wanted, so I did a bit of work on the idea. A big group of people have now almost finished it.
Like something we're forced to use, but in all honesty I don't completely see where you're getting at.
Note, I now regret singling out react-router. I'm still learning that on places like HN, it's best to avoid giving examples when discussing software design in abstract terms, because you're needlessly singling out some good people (in this case, you), plus half the discussion becomes a nitpick about the example instead of a discussion about design principles.
I do actually believe that react-router is a bad fit for JSX, let alone React components, but I also think that others are allowed to disagree. The best I can do is try and encourage careful thought when considering JSX, which is what I wrote my comment for, but if people disagree with me on exactly where to draw the line, then that's not really a problem is it?
I hardly have any open source to show for, so you're already way ahead of me, and in the few things I do have on Github, I bet that you'd disagree with some design decisions I made as well.
Sorry for dragging you into this. Open source is unrewarding work and I surely didn't help.
Interesting... Actually last week I stumbled upon react-bootstrap. After all I wasn't enthusiastic to use it yet, because I wonder whether it interfers with the regular bootstrap. (Right now the app I work on is only partially implemented in React.)
Does somebody has a link to a working react-bootstrap code example? I tried to get react-bootstrap working last week but somehow it did not recognized its own tags like for the navbar :(
in the next few days I hope to add more constraints. My main concern about react-bootstrap is the massive use of `transferPropsTo`, from what I understand is a deprecated method
Something still in the early stages we've been kicking around for component demos is this: http://cmpnt.vistarmedia.com - you can see how the documentation and demos for each component is generated in the source tabs.
Does React really need something like this? This seems to just be following the "plugin" tradition set forth by jQuery. I've written a lot of React and haven't found myself needing things like this. It's just JavaScript and markup people, you should be able to do it yourself rather easily.
Building really good complex form widgets is hard work. You have to handle ARIA/accessibility, ensure you have support for focus and tabbing, handle lots of keyboard shortcuts as appropriate, etc.
Solid implementations of autosuggest inputs, token input fields, or fast scrolling tables can run into the thousands of lines. Having reusable versions of them would be very helpful for the React ecosystem.
It's really easy to make reusable React components though, the boundaries are well defined (props) and the state is confined to the child. Pretty much what Web Components aspires to be, but it already works and you can leverage today.
I have a couple components I can extract from a running project and publish there without any changes (Google Maps, Google Autocomplete, Tagging input, ...) and it will just work.
It doesn't need it, but I don't see how it is possibly a bad thing? Do you want a textarea that adjusts size based on the content? Sure, you could write that yourself, or you could just `npm install react-textarea-autosize`.
Want to render a sparkline of some data? Sure, you could mess around with existing libs and see if you can get them to work nice with React, or you could just pull in something you can expect actually works, like react-sparkline.
Guys, can someone enlight me on how to create a react component that encapsulates an Odometer[1] the React Way? Since it does a lot of direct DOM manipulation, I'm not sure of how to do it.
Typically you would render a single root element and then use the 'after' lifecycle methods (componentDidMount, componentDidUpdate) to grab the root element (with getDOMNode) and make your changes (eg. call a jQuery plugin method on the dom node)
Review the link below for a simple example of a Radial Gauge component. This is just the basic 'wrapping' of an existing UI component so more can be done:
Very nice! I think it would be great if the clickable component names on the right could have some kind of tooltip that contained a brief description of the component.
E.g.: For the react-messages it could be "React component for showing error, warning, info messages."
I started work on similar component last week where you pass in a Backbone Collection or Backbone Paginator collection and it would generate components like a pager, a table, a paginated table with search and sorting [1].
I think for people building complex applications that have a ton of reusable ui elements react components start to be really enticing because you know you pass this piece of information in and the ui will be consistent throughout assuming there are tests written.
I was thinking how useful something like this would be recently. My concern was that we'd end up with yet another package management system to deliver it, so I'm glad NPM is being used. Great stuff!
I love React, but so far I've been a bit underwhelmed by the ecosystem of components that has sprung up. I hope that this site will help.
A lot of the components are stuff that aren't really UI elements, but rather add magic to other UI elements or even do something completely unrelated to the UI.
I mean, I've seen routers written as React components![1] Wtf? Why is it an advantage to express a route as XML-like JSX? Why put it in a virtual DOM? That's just waiting for unexpected side-effects to happen. I can imagine that a lean, to-the-point router is a good combination with React but components are for UI widgets, not for configuration.
I feel like this is the same mistake as the everything-in-XML hype of the early 21st century (Spring, anyone?), or the everything-as-a-DSL hype in early Scala (with clear, descriptive operators such as ~~=, $%% and of course &^), or the current hype in C#-o-world to package web assets into NuGet packages (jquery.dll - seriously?). Just because you can put it in a component, doesn't mean that you should.
Behavioral features for components (e.g. infinite-scrolling or tooltip triggers) are well distributed as a mixin. Stuff not directly related to UI widgets should just be vanilla JavaScript. Asset libraries should be asset libraries.
What I expect from open source components is UI elements. Color pickers, fancy dropdown selects, login widgets, form elements with pluggable validation maybe (but the validation logic shouldn't be components). Notably, I'd love an ecosystem of UI frameworks ala Bootstrap or Foundation to spring up around React, and it appears that this is happening.
(Sidenote, if there's one development we do need, then it's a clear React-authors-condoned way to couple (parameterized) CSS with React components, so that we can really distribute self-contained components including style. A development like that would also help focus the React component ecosystem on what it should be about: UI widgets.)
[1] Random example: https://github.com/rackt/react-router#whats-it-look-like - seriously, what were they thinking?