React Components | Hacker News Reader

React Components

react-components.com

191 pointstipex63 comments

(Marginally related rant)

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?

Maybe take a look at the source code for the router component you're so offended by.

https://github.com/rackt/react-router/blob/master/modules/co...

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:

http://facebook.github.io/react/blog/2014/08/03/community-ro...

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.

The rationale for using JSX over plain JS is given here - http://facebook.github.io/jsx/

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.

That sounds like a delicious practical joke.

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.

XML syntax was not invented for rendering UI components.

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).

Then use them as JavaScript functions, because that's what they are :)

The point of JSX is to express attributes and hierarchy, which matches with our route configs perfectly.

If you read the overview you may understand our opinion that "application state" is precisely which views to render.

https://github.com/rackt/react-router/blob/master/docs/guide...

We're almost done with serializing the application data as well. Both pieces are important.

> We can agree to disagree right?

It's not really agreeing to disagree when you're openly mocking the idea across multiple paragraphs.

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.

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.).

We've almost tied all the knots we need to meet this requirement of a router.

Every application has UI nesting at the core of its state, though.

The UI is a reflection of the state. UI nesting is not part of the state itself. The route is just a serialized representation of the state.

If it isn't generating markup then why is it a React component at all?

What about http://react-bootstrap.github.io/ ?

The router and some other components are not only plain react ui components, they try to implement a Flux-Architecture with real components. Flux: http://facebook.github.io/react/docs/flux-overview.html

A better approach (IMHO) is Fluxxor http://fluxxor.com/

And the benefit of the react router is, that you don't have to concern about the render / re-render.

With express you have to do everything by your own.

I think we must difference between Browser - Application Routing and Application - Component - Routing.

Have you checked out react-bootstrap? http://react-bootstrap.github.io/ . Here's a little write-up I've suggested to explain the project: https://syllog1sm.github.io/introduction.html

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.

Your second link does not work. Would be interesting.

Damn. Thanks.

https://syllog1sm.github.io/react-bootstrap/introduction.htm...

Can't seem to edit my comment...

Thanks!

Thanks for starting this. It's currently making my life much easier.

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).

> 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 one of the authors of react router.

How do you feel about <script/> tags, or <link/> or <meta/> or <base/>?

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 :(

This looks pretty cool:

http://gcanti.github.io/resources/tcomb-react-bootstrap/play...

Thank you! author here :)

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

Maybe I'm missing something, but the few components I clicked on didn't have immediately obvious demos available.

This would be pretty useful, especially if it isn't a wrapped version of a well-known existing library.

This is a slightly difficult problem to solve, but we are working on a proposal for how this could work. See https://github.com/vaffel/react-components/issues/7

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.

I also maintain a component list http://dvemac.github.io/react-component-list/ Maybe you could use the source data in some way, as the UI I quickly knocked up is poor at best! Its on github here https://github.com/DveMac/react-component-list/blob/master/l...

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.

I'm also afraid of the jQuery effect.

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.

Please do publish them! A great react-google-maps I'd definitely use.

I'll publish soon. You might want to follow on Github: http://github.com/hcarvalhoalves

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.

[1] https://github.com/HubSpot/odometer

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:

    http://ifandelse.com/using-reactjs-and-kendoui-together/

The JSFiddle example is here:

    http://jsfiddle.net/ifandelse/U5P32/light/

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)

Here's a jsfiddle for the specific lib you're talking about (Odometer): http://jsfiddle.net/p1h7rn3q/

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."

Good suggestion - will see if we can integrate something similar for desktop clients soon

Like https://nodejsmodules.org/

a short description under a package is easier to read.

A structured Category-List will also be helpfull, sometimes i don't know exactly what i search for and then i browse the category (tags).

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.

[1] https://github.com/securingsincity/backbone-react-ui - still very much a work in progress

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!

React community seems to be pretty intent on using NPM, I don't think I've ever seen a package for it delivered any other way

It'd be nice if it shows which ones are popular, which ones are the most useful to me, etc.

Most popular should be easy to make (based on downloads/github stars) - most useful is a bit trickier. How would that work?

Most useful for me: Tested Compability with IE (starting with IE8) and FF, Safari etc.

Agreed, a display of stars for projects hosted on github would be amazing. Tells me the projects I need to know about.

I was just about to set up something very much like this for React, and even use NPM.

Nice job, looks good!

I did something similar ... No integration with NPM though... http://www.reactjsx.com/

Great page! How do I show all components?

You can go straight to npm and browse the keyword which is used to generate this site.

https://www.npmjs.org/browse/keyword/react-component

Not possible at the moment, but will be the next feature out the door (I'm the lead developer)

Reply on news.ycombinator.com